How to get ready for an ATAM

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.

What are those business goals?

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.

From the Trenches – Software by Numbers

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 Dec 17: Linda Northrop on ultra-large-scale systems

SEI Webinar Series: The Impact of Scale by Linda Northrop

Thursday, December 17, 2009 1:00-2:00 PM EST

Abstract

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.