Software Architecture: Some Insights

Systems are built to satisfy an organization's requirements (or assumed requirements in the case of shrink-wrapped products), and these requirements determine the extent to which a system must meet performance targets, be highly available, interoperate with other systems, or be designed for long lifetimes. These properties of a system are constrained by the system's software architecture; or, to put it anther way, the desire to achieve these properties influences the design choices made by a software architect.

A software architecture is the development product that gives the highest return on investment with respect to quality, schedule, and cost. This is because an architecture appears early in a product's lifetime. Getting it right sets the stage for everything to come in the system's life: development, integration, testing, and modification. Getting it wrong means that the fabric of the system is wrong, and it cannot be fixed by weaving in a few new threads or pulling out a few existing ones, which often causes the entire fabric to unravel. Also, analyzing architectures is inexpensive, compared with other development activities. Thus, architectures give a high return on investment partially because decisions made for the architecture have substantial downstream consequences and because checking and fixing an architecture is relatively inexpensive.

The architectural view of a system is an abstract view that distills away details of implementation, algorithm, and data representation and concentrates on the behavior and interaction of "black-box" components. A software architecture is developed as the first step toward designing a system that has a collection of desired properties.

The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.

"Externally visible" properties refers to those assumptions other components can make of a component, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. The architecture must abstract away some information from the system (otherwise there is no point looking at the architecture; we are simply viewing the entire system) and yet provide enough information to be a basiss for analysis, decision making, and hence risk reduction.

The architecture embodies information about how the components interact with each other. This means that architecture specifically omits certain information about components that does not pertain to their interaction. Thus, an architecture is foremost an abstraction of a system that suppresses details of components that do not affect how they use, are used by relate to, or interact with other components.

The software architecture of a system is the earliest artifact that enables the priorities among competing concerns to be analyzed, and it is the artifact that manifests the concerns as the system qualities. The trade-offs between performance and security, between maintainability and reliability, and between the cost of the current development effort and the cost of future developments are all manifested in the architecture.

Almost never are the properties required by the business and enterprise goals consciously understood, let alone fully articulated. Indeed, even customer requirements are seldom documented completely. However, it is important for architects to know and understand the kinds of constraints on the project as early as possible. Therefore, architects must identify and actively engage the stakeholders to solicit their needs and expectations. Without such active engagement, the stakeholders will, at some point, engage the architects to explain why each proposed architecture is unacceptable, thus delaying the project and idling workers. Early engagement allows the architects to understand the constraints of the task, to manage expectations, and to negotiate priorities. It is important that the architects understand the nature, source, and priority of these constraints. This places the architects in a better position to make trade-offs when conflicts among competing constraints arise, as they inevitably will. It should be apparent that the architects need more than just technical skills. Continual explanations to one stakeholder or another will be required to explain the chosen priorities of different properties and why particular stakeholders are not having all of their expectations satisfied. Thus, for an effective architect, diplomacy, negotiation, and communication skills are essential.

ARCHITECTURE-BASED PROCESS STEPS

The activities involved in creating a software architecture, using that architecture to realize a design, and then implementing or managing the evolution of a target system or application:

• Creating the business case for the system
• Understanding the requirements
• Creating or selecting the architecture
• Representing and communicating the architecture
• Analyzing or evaluating the architecture
• Implementing the system based on the architecture
• Ensuring that the implementation conforms to the architecture

There is no such thing as an inherently good or bad architecture. Architectures are either more or less fit for some stated purpose. Architectures can in fact be evaluated, but only in the context of specific goals.

Structural Recommendations

• The architecture should feature well-defined modules whose functional responsibilities are allocated on the principles of information hiding and separation of concerns. Each module should have a well-defined interface that encapsulates or "hides" changeable aspects (such as implementation strategies and data-structure choices) from other software that uses its facilities.
• The modules should reflect a separation of concerns that allows their respective development teams to work largely independently of each other.
• The information-hiding modules should included those that encapsulate idiosyncrasies of the computing infrastructure, thus insulating the bulk of the software from change should the platform change.
• The architecture should never depend upon a particular version of a commercial product or tool. If it depends upon a particular commercial product, it should be structured such that changing to a different product is straightforward and inexpensive.
• Modules that produce data should be separate from modules that consume data. This tends to increase modifiability because changes are often confined to either the production or consumption side of data. If new data are added, both sides will have to change, but the separation allows for a stages (incremental) upgrade.
• For parallel-processing systems, the architecture should feature well-defined processes or tasks that do not necessarily mirror the module structure. That is, processes may thread through more than one module; a module may include procedures that are invoked as part of more than one process.
• Every task or process should be written so that its assignment to a specific processor can be easily changed, perhaps even at runtime.
• The architecture should feature a small number of simple interaction patterns. That is, the system should do that same things in the same way throughout. This will aid in the understandability, reduce development time, increase reliability, and enhance modifiability. It will also show conceptual integrity in the architecture, which wile not measurable, leads to smooth development.

• The architecture should be the product of a single architect or a small group of architects with an identified leader.
• The architect (or architecture team) should have the technical requirements for the system and an articulated, prioritized list of qualitative properties (such as portability) that the architecture is expected to satisfy.
• The architecture should be well documented, using an agreed-on notation that all stakeholders can understand with a minimum of effort.
• The architecture should be circulated to the system's stakeholders, who should be actively involved in review.
• The architecture should be analyzed for applicable quantitative measures (such as maximum throughput) and formally reviewed for qualitative properties (such as modifiability) before it is too late to make changes to it.
• The architecture should lend itself to implementation via the creation of a "skeletal" system in which the communication paths are exercised but which at first has minimal functionality. This skeletal system can then be used to "grow" the system incrementally, easing the integration and testing efforts.
• The architecture should result in a specific (and small) set of resource contention areas, the resolution of which re clearly specified, circulated, and maintained. For example, if network utilization is an area of concern, the architects should produce (and enforce) for each team guidelines that will result in a minimum of network traffic. If performance is a concern, the architects should produce (and enforce) time budgets for the major threads.

There are two broad categories of quality attributes against which a system can be measured (and, in particular, can be measured at the architectural level):

• Observable via execution: How well does the system, during execution, satisfy its behavioral requirements? Does it provide the required results? Does it provide them in a timely enough manner? Are the results correct or within specified accuracy and stability tolerances? Does the system function as desired when connected to other systems?
• Non observable via execution: How easy is the system to integrate, test, and modify? How expensive was it to develop? What was its time to market?

Quality must be considered at all phases of design, implementation, and deployment, but different qualities manifest themselves differently during these phases. For example, many aspects of the quality of Usability are not architectural; making the user interface clear and easy to use is primarily a matter of getting the details correct. Should you provide a radio button or a check box? What screen layout is most intuitive? What typeface is most clear? Although these details matter tremendously to the end user and influence Usability, they are not architectural because they are almost always encapsulated within a single component. This localization affects Modifiability but not Usability.

System Quality Attribute	Architectural in Nature?	Architectural Issues
Performance	Yes	Intercomponent communication; dividing functionality so as to exploit parallelism
Security	Yes	Specialized components, such as secure kernels or authentication servers
Availability	Yes	Fault tolerance with decundant components, controlling component interaction
Functionality	No	Interaction with other quality attributes
Usability	Yes (No)	Modifiability helps to achieve; achievingproper information flow; efficiency related to performance
Modifiability	Yes	Modularized, encapsulating components
Portability	Yes	Portability layer
Reusability	Yes	Loose coupling amount components
Integrability	Yes	Compatible interconnection mechanisms; consistent component interfaces; uses relation allows incremental builds
Testability	Yes	Modularized, encapsulating components; uses relation allows incremental builds

The message is:

• Architecture is critical to the realization of many of the qualities of interest in a system, and these qualities should be designed in and evaluated at the architectural level.
• Some qualities are not architecturally sensitive, and attempting to achieve these qualities or analyze for them through architectural means is not fruitful.

There are there classes of quality attributes:

• Those that can be discerned by observing the system execute (performance, security, availability, functionality, usability) and system qualities that are not discernible at runtime (modifiability, portability, reusability, integrability, testability).
• Business qualities (time to market, cost, projected lifetime of the system).
• Qualities about the architecture itself (conceptual integrity, correctness and completeness, buildability).

"I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvement, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas."

"I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvement, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas."

When developers ask, "What architecture shall I choose?" they are seeking the answer to the following questions:

• What structure shall I employ to assign workers, to derive my work breakdown structure, to exploit already-packaged components, and to plan for modification?
• What structure shall I employ so that the system, at runtime, fulfills its behavioral and quality attribute requirements?