Microsoft .NET: Architecting Applications for the Enterprise ... - BattleIT

Chapter 1 Architects and Architecture Today 5
We think that software professionals should agree on a more detailed explanation that
breaks down that defi nition into smaller pieces and puts them into context.
Defi ning the Architecture from a Standard Viewpoint
Many seem to forget that a standard defi nition for software architecture exists. More
precisely, it is in ANSI/IEEE standard 1471, “Recommended Practice for Architectural
Description of Software-intensive Systems.” The document was originally developed by
IEEE and approved as a recommended practice in September 2000.
The document focuses on practices to describe the architecture of software-intensive
systems. Using the defi nition in the standard, a software-intensive system is any system in
which software is essential to implementation and deployment.
Stakeholders are defi ned as all parties interested or concerned about the building of the
system. The list includes the builders of the system (architects, developers, testers) as well as
the acquirer, end users, analysts, auditors, and chief information offi cers (CIOs).
In 2007, the ANSI/IEEE document was also recognized as a standard through ISO/IEC document
42010. Those interested in reading the full standard can navigate their browser to the following
URL: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=45991.
Examining Key Architecture-Related Points in ANSI/IEEE 1471
The key takeaway from the ANSI/IEEE standard for software architecture is that a software
system exists to meet the expectations of its stakeholders. Expectations are expressed as
functional and nonfunctional requirements. Processed by the architect, requirements are
then communicated to the development team and fi nally implemented. All the steps occur
and exist to ensure the quality of the software. Skipping any step introduces the possibility
for less software quality and the potential to not meet the stakeholders’ expectations.
To design a software system that achieves its goals, you need to devise it using an
architectural metaphor. Accepting an architectural metaphor means that you recognize the
principle that some important decisions regarding the system might be made quite early
in the development process; just like key decisions are made very early in the development
of civil architecture projects. For example, you wouldn’t build a skyscraper when a bridge
was required. Similarly, requirements might steer you to a Web-oriented architecture
rather than a desktop application. Decisions this major must be made very early.
A software architecture, therefore, is concerned with the organization of a system and lays
out the foundations of the system. The system, then, has to be designed—which entails
making some hard decisions up front—and described—which entails providing multiple
views of the system, with each view covering a given set of system responsibilities.