Non Funky Stuff – What’s Good for Business even if Business does not Know it

Non Funky Stuff – What’s Good for Business even if Business does not Know it

Biography

Nobody really likes non-functional aspects of IT-systems. Yet they are crucial. How to make the requirements explicit and map them to solution design, infrastructure configuration and operational monitoring and management? Agile, DevOps, Cloud, Automation have pushed the non-funky stuff to the fore. The non-functional characteristics of your IT systems can make or break them. Failing security, inability to scale, poor availability, excessive costs, dismal performance, operational mismanagement. We tend to spend too little time a little too late on non-functional aspects. Because they are not funky. Or not entirely understood by the business. Or not completely grasped by the application development team. We simply cannot afford that. In this session we will use a structured approach to identifying and recording these non-functional requirements and designing our solutions accordingly, with future change in mind. Learn how to never leave the non-funky stuff out of our collective sights. Non functionals always have been important. The elasticity of the cloud (and the associated bill), the automation of many operational processes, the required agility of applications, increasing focus on security and the expanding responsibility of development teams into DevOps are all reasons by non-functional aspects of applications are rapidly becoming more prominent. We need to find a structure way to discuss non-functional aspects - as DevOps team as well as with the product owner and business stakeholders. How to incorporate requirements into solution designs, how to test for non-functionals and monitor current state of affairs to react and predict in order to pro-act. In this session I will discuss the non-funky diagrams I have created to visualize the non-functional requirements from a business level and mapped them all the way down to infrastructure. To find bottlenecks in scale, cost, performance and availability, to identify attack surfaces, and spot decoupling opportunities. These diagrams are a useful tool to bring various types of specialists together and discuss design options and the impact of choices. Outline: the project: overran the budget by 200%, double the time and the system is still unstable and way too slow. Technology: Java on Azure - how to find the causes of brittleness? - how to find the performance bottlenecks? - how to find the availability undermining factors? Introducing a way to visualize the non functional characteristics of systems across multiple tiers (from functional end-to-end chains to bare infrastructure components) How to plot requirements? How to find the waterbed effect? How to design (meaningful) redundancy & fail over? Applying this non-funky visualization style to the doomed project - and getting a handle on it.

Papers

No items found