Firebrand Architect®

Human Aspects of Software Architecture - views from the trenches.

Wednesday, April 23, 2008

Software Architecture Assessment

Assessment of software architecture is necessary to judge its utility and applicability to the goals a system aims to achieve. Every architecture design should be assessed by a non-partisan resource, but this practice has been adopted only at organizations with a very mature software engineering processes. There are no industry wide accepted methods for evaluating software architecture, but the Architecture Tradeoff Analysis Method (ATAM), developed by the SEI, is a well structured & rational approach for conducting architecture assessments.

Benefits of a structured tradeoff analysis method

The principal benefit of the Architecture Tradeoff Analysis is an ability to see if a proposed overall software structure will live up to the user expectations. The tradeoff analysis helps one understand the strengths and weaknesses of a system. The ATAM method not only helps evaluate the current system architecture, but also helps with the design of architecture for a new system. This methodology helps designers to ask the right questions and solve critical issues early on in the project. Additionally, selecting the right degree of quality for a specific system fully utilizes the money spent by the customer, as the money spent in any one particular area of the system will be justified.

The ATAM process helps developers discover tradeoffs and sensitivity points

The tradeoff points are defined as the dependencies between attributes. The sensitivity points are the areas of the system that will be significantly impacted if system architecture is changed. The tradeoff points are the breeding ground for the sensitivity points, because when architecture changes the connections between different attributes changes as well.

One of the more obvious tradeoffs is the relationship between performance and security quality. Often the security quality is achieved by compromising performance; this is not a surprising statement as it’s general knowledge that making something secure requires a special effort. Even outside of the architectural context, securing a door in a house requires a purchase and installation of a lock – and that’s only the initial costs. The effort required to lock and unlock the door each time it’s open/closed is an additional cost/effort element. In this out of context example performance of the door can be increased by not installing a door lock. With no lock there is little security, as anyone can open the door with no trouble. The tradeoff points in this example are the presence of lock(s) and the speed at which a door may be opened (perhaps for security reasons it can only be opened at 1 foot per hour).

Key sensitive points are like the gauges that must be monitored by an architect each time a change to a software system is considered on an architectural level.

Do you evaluate your software architecture?

At the end of the day a systemic architecture evaluation method is up to the architect to decide. What matters is that an architect has a way to judge whether architecture is the right fit for a business problem at hand. Other evaluation methods exist and serve various purposes: SAAM, ALMA, FAAM, CBAM. Some even use this assessment form.

Post a comment if you evaluate software architecture. How do you do it?

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Labels: , , ,

Saturday, January 19, 2008

Edward Hopper - Communicating the Essence




It’s the architect’s job to decide and communicate which quality attributes need to be emphasized in order to achieve the overarching mission of a solution. Similarly the iconic American artist Edward Hopper, in his paintings, captured the essence of a scene while abstracting the negligent elements of the situation.

In painting Haskell’s House you clearly see that the artist chose to omit the wires from the electrical poles. The busy harbor behind the house is not depicted in the painting: the core emphasis is on the house. Also notice how the sun rays draw your attention on the house and you can almost forget about the mundane details of trees, landscaping, and electrical poles. A software architect has a similar job: capture the big picture (e.g. security, environment constraints, composition of services), but note the critical solution qualities (e.g. usability, performance).

In the infamous painting, Nighthawks, Edward Hopper uses light and shadows to concentrate viewer’s attention on the situation in a dinner. Notice lack of pedestrians, cars, or any other artifacts that would detract from the developing situation inside of a dinner. The viewer may dully acknowledge the presence of outside, but all the attention is concentrated on what is happening on the inside. Similarly an application architect that works in a mature design environment simply needs to acknowledge the presence of certain assumptions, but concentrate his work on the essence of a solution.

The 1940 painting Gas shows a lonely attendant at a gas station. There are no cars fueling or on the road. The obvious, cars, is not commuicated.

If you ever have a chance to see a collection of Edward Hopper’s paintings do not miss that chance. A closer look at the paintings can be found here.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Labels: , , ,

Friday, September 07, 2007

Microsoft's Reference Architecture

A software architect must have a comprehensive understanding of the technical environment in which a software solution will reside. Mature and usually large organizations usually have volumes of Enterprise Architecture (EA) that contain guidance and identification of the as-is state of the enterprise and the future evolution. The volumes of EA usually represent different levels of abstraction, but have a common theme centered on a business domain. Parts of the EA are meant to be used as reference architecture to guide a software architect in design of a solution so that it fits snuggly into the existing enterprise and so that a solution can evolve graciously.

Microsoft has developed a comprehensive reference architecture that for its Windows Server platform. It’s a “detailed reference architecture, tested and proven in labs, that yields valuable implementation guidance for meeting the requirements of an enterprise.” Even non-Windows enterprise architects will benefit from the recommendations in the Microsoft’s reference architecture documentation.

For each type of service reference architecture contains an introduction, a blueprint, a planning guide, a build guide, and an operations guide. Out of many services covered some notable are network devices, storage devices, firewall, certificate, backup, network, directory, file, data, web application, middleware, and messaging.

Microsoft’s reference architecture is well organized, easy to use, and very comprehensive for both Microsoft and non-Microsoft centric architects.

Home page | Comprehensive download MS Word documents in installer

Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Labels: ,

Saturday, November 25, 2006

Information sharing / architecture documentation sharing

In a survey taken by SoftwareArchitectures.com in the spring of 2006 over 65% of the visitors were most interested in seeing practical examples of software architectures. The architecture of the real world enterprise grade software systems is proprietary as it represents the competitive advantage of an organization. Therefore it is difficult to obtain software architecture documents of such caliber, which consequently hinders information sharing between software architecture professionals.

But it is still possible to share the essence of software / system architecture without compromising organizational secrets. To achieve this, first, complete anonymity of the submitter must be assured. Second, the proprietary information must be rewritten or removed (e.g. IP addresses, company name, product name, interface systems, etc.). Third, the business problem solved by a system must be generalized. Fourth, implementation specific information must be removed to a level that does not give away owner’s identity.

Who will invest their free time into doing this? Only those who want to obtain feedback on the architecture from the greater software architecture community. Caveat: constructive feedback is not likely as long as the architect and the reviewers are not utilizing the same architectural paradigm while discussing the document.

SoftwareArchitectures.com has a library of usable, complete, and well-documented software architecture design documents available for free. See the Case Studies link on the main page.

- Firebrand Architect on duty: JP

Labels: , ,