Maybe you have been wondering what you have to do as an architect of a software-reliant system to get ready for an SEI Architecture Tradeoff Analysis Method (ATAM) architecture evaluation. Maybe, like me, you hate to be taken by surprise and want to know the outcome of the ATAM upfront. Hmmmm … so, you too are thinking about a strategy on how to “game the system,” right? Well, here is how I do it.
First of all, let us accept the fact that nobody can build an architecture without weaknesses. We just don’t get enough time, money, or the right technology to do a perfect job. And of course, the ATAM will uncover all those weaknesses. If you get a well-trained ATAM team you can be assured that they will find most of those weaknesses. You cannot hide anything from them. So, don’t even try.
Posted in Architecture-Centric Engineering, Architecture-Centric Practices
Tagged architecture design, architecture evaluation, architecture review, Architecture Tradeoff Analysis Method, ATAM, non-functional requirements, SEI, software architecture, software architecture evaluation, software architecture requirements, software architecture review, software development, Software Engineering Institute, system architecture
A truism in the software development business is that systems exist to support business goals. Any system design decisions that does not support business goals should not be made, and system design decisions that do support the business goals should be prioritized based on the particular goals.
The assumptions made in the above statement are that the business goals for a system are explicit and agreed upon by all stakeholders. Unfortunately, these assumptions are rarely true. More frequently, different stakeholders have different business goals for a particular system (often conflicting), some business goals are implicit and unstated, and still other business goals are not realizable.
This is another post in the “From the Trenches” series about our research project on communicating the value of architecting within Agile development. I meant to post this earlier, but I’ve been in the trenches digging.
As Ipek Ozkaya discussed in our From the Trenches kickoff post, we are approaching our research on the value of architecture from the perspective of release planning. I am excited about this perspective because it moves the discussion of architecture’s value out of the realm of philosophy and into the realm of action and choice. As practitioners, we may talk to management and marketing and other decision makers about how valuable architecture is, and they may, in principle, agree. However, the real test of whether we’ve made the sale about architecture’s value is when the time comes to make investment choices, and that’s where release planning comes into play.
SEI Webinar Series: The Impact of Scale by Linda Northrop
Thursday, December 17, 2009 1:00-2:00 PM EST
Many systems of the future will be of ultra-large size on one or many dimensions – number of lines of code; number of people employing the system for different purposes; amount of data stored, accessed, manipulated, and refined; number of connections and interdependencies among software components; and the number of hardware elements to which they interface. They will be ultra-large-scale (ULS) systems.