3. The Benefits of ATAM Evaluations

 

The following are the benefits of Architecture Tradeoff Analysis Methodology (ATAM) -

· Clarified QARs

· Improved Architecture documentation

· Documented basis for architectural decisions

· Identify risks early in the life cycle

· Increased communication among stakeholder

· The results are dramatically improved software architectures.

2. ATAM Conceptual Model

The ATAM process if a facilitated interaction between stakeholders leading to the identification of risks, non-risks, sensitivities and trade-offs.

Sensitivity Points – a property of one or more components that is critical for achieving a particular quality attribute response. Example – queue depth is a sensitivity point. Changing this can help scalability or/and throughput.

Trade off – is a property that affects more than one attribute. E.g. Having a queue that is persistent or non-persistent impacts durability, availability and throughput. This is a trade-off.

The following model shows Business Drivers to Scenarios decoupled from Architectural Plan to Architectural Decisions.

See Conceptual Model here: http://www.sei.cmu.edu/architecture/tools/evaluate/atam.cfm

In practice, Architectural Approaches is where QARs tagged to distinct approaches are derived from the plan. So you take the plan/presentation à Architectural Approaches à Quality Attributes à Architectural Decisions is probably more accurate.

Advice: Never do Phase 1 and Phase 2 in the same week. Give yourself 1-2 weeks in between.

Understanding Architectures with Pictures

 

“Pictures speak a 1024 words.” – this is a quote I used a lot for the past 10 years or so. Why? Well this is because architectures need to be visualized. Bredemeyer Consulting’s Visual Architecting Process, SEI’s SAPP, RUP’s UML, Zachman, TOGAF etc. all dwell on visualizing abstractions. But how do you translate that to real projects, and especially those that claim to be agile and misunderstand that to mean no design and no plans? As one of the many signatories of the agile manifesto it is clear to me that those projects that do not know what the architecture is can not deliver software in a timely manner with good quality attributes.

Software Architecture should be represented by a set of views that support its analysis. Usually the following views are most often used:

Advice: At least 3-views recommended by SEI:

1. Module View

2. Component View

3. Deployment View

Plus a sequence diagram can be added as the forth.

Multiple views of a software architecture allow it to be understandable without any confusion by the entire team and its stakeholders.

Architect with security in mind as a first thought

So if you’re doing a solution architecture review, make sure you first look at the security design of the system including authentication, digital signatures, secret key cryptography, public key cryptography, authorization, and non-repudiation from the perspective of a digital firm. Authentication and authorization are the founding stones of security which needs to be understood and deployed across the enterprise.

The use of digital signatures has seen tremendous growth in recent years and with the onset of new technologies, in particular Web-services, promises to be the dominant area in security. Corporate espionage is on the rise, and security can not be overlooked.
Ensure your system vulnerabilities are checked - Cross Site Scripting seems to be the worst offender in modern systems. Make sure your internet-facing applications are hosted on supported and patched platforms. Approach it with an outside-in, basic-first strategy for your IT department instead of focussing on obtuse things like bit-encryption levels first, ensure you can prioritize defenses against the most probably threat vectors first.

Software Architectures need to be evaluated.

What constitutes an architecture?

“You employ stone, wood and concrete, and with these materials you build houses and palaces. That is construction. Ingenuity is at work.

But suddenly you touch my heart, you do me good, I am happy and I say ‘This is beautiful’. That is Architecture.”

- Le Corbusier, 1923

- Quoted in Architecture: From Prehistory to Post-modernism

Well, then what is software architecture?

There is no universal agreed upon formal definition of software architecture, however, the Software Engineering Institute (SEI) has defined it as follows:

“The software architecture of a system is the structure of structures of the system, which comprise software components, the externally visible properties of those components and the relationships among them.” - SEI’s definition of Software Architecture.

- It is a vehicle for communication among stakeholders.

- It is the manifestation of the earliest design decisions.

- It is a reusable, transferable abstraction.

Software elements – modules, components etc. Externally visible properties – does provide for internal flexibility. E.g. a contract is externally visible.

All designs involve tradeoffs. Architecture is the earliest life-cycle artifact that embodies significant design decisions: choices and tradeoffs.

Predict a system’s quality attributes by studying its architecture. We can analyze architecture for achievement of quality attributes – it determines risk not a “grade”.

Bottom line: an evaluation should result in architectural “Risks Themes”. See SEI’s web-site for details.

Evaluation of Software Architecture is essential to determine Risks

I love change for positive growth and innovation because it makes me excited and feel like I am making a difference to the people using the product that was once in my head and now in their hands.

Sometimes I encounter software architectures just “evolved” out of need. At times teams “end up” with architectures that just happened to them, other times projects are proposed and designs sketched up to deliver the software. Evaluation of software is essential in all cases.

Look at this structure, to me this looks really ugly, however to the contractor it may be the most lucrative structure to the people living inside it doesn’t matter. Risks, Non-Risks, Tradeoffs and Sensitivity points are great ways to highlight risk themes so that a design decision can be made once they are understood.

The point is : no architecture is good or bad, there are simply risk themes which when elaborated gives the person information to personally judge it based on their needs.