Architecture as a Set of Design Decisions

If architecture is the set of design decisions, then documenting the architecture boils down to documenting the set of design decisions. This is usually not done, though. We can usually get at the result of the design decisions, the solutions chosen, but not at the reasoning behind them. Much of the rationale behind the solutions is usually lost forever, or resides only in the heads of the few people associated with them, if they are still around. So the reasoning behind a design decision is explicitly captured. This is tacit knowledge, essential for the solution chosen, but not documented. At a later stage, it then becomes difficult to trace the reasons of certain design decisions. In particular, during evolution one may stumble upon these design decisions, try to undo them or work around them, and get into trouble when this turns out to be costly if not impossible. There are different types of undocumented design decisions:

The design decision is implicit: the architect is unaware of the decision, or it concerns of course knowledge. Examples include earlier experience, implicit company policies to use certain approaches, standards and the like.

The descign decision is explicit but undocumented: the architect takes a decision for a very specific reason (e.g. the decision to use a certain user-interface policy because of time constraints). The reasoning is not documented, and thus is likely to vaporize over time.

The design decision is explicit, and explicitly undocumented: the reasoning is hidden. There may be tactical company reasons to do so, or the architect may have personal reasons (e.g. to protect his position).

It is an illusion to want to document all design decisions. There are far too many of them, and not all of them are that important. And documenting design decisions takes time and effort from the architect, a very busy person. But we may try to document the really important ones. A design decision addresses one or more issues that are relevant for the problem at hand. There may be more than one way to resolve these issues, so that the decision is a choice from amongst a number of alternatives. The particular alternative selected preferably is chosen because it has some favorable characteristics. That is, there is a rationale for our particular choice. Finally, the particular choice made may have implications for subsequent decision making. Table 1 gives a template for the type of information that is important to capture for each design decision.

Table 1 - Elements of a design decision. Element Issues Decision Status Assumptions Alternatives Rationale Implications Notes Description Design issues being addressed by this decision. The decision taken. The status of the decision, e.g. pending, approved. The underlying assumptions about the environment in which the decision is taken. Alternatives considered for this decision. An explanation of why the decision was chosen. Implications of this decision, such as the need for further decisions or requirements. Any additional information one might want to capture.

Table 2 gives an example of a design decision for our library application. It concerns the choice for a 3-tier architecture, consisting of a presentation layer, a business logic layer, and a data management layer.

Table 2 - Example of a design decision. Element Issues Decision Status Assumptions Description The system has to be structured so that it is maintainable, reusable, and robust. A three-tier architecture, consisting of a presentation layer, a business logic layer, and a data management layer. Pending or Approved The system has no hard real-time requirements. A service oriented architecture (SOA) or a different type of X-tier architecture (e.g. one with a fat client inlcuding both presentation and business logic, adn a data management tier. Maintenance is supported and extensions are easy to realize because of the loose coupling between layers. Both the presentation layer and the data management layer can be reused in other applications. Robustness is supported because the different layers can easily be split over different media and well-defined layer interfaces allow for smoother

Alternatives

Rationale

testing. Implications Notes Performance is hampered since all layers have to be gone through for most user action. None.

Design decisions are often related. A given design decision may constrain further decisions, exclude or enable them, and the like. These relationships between design decisions resemble the kind of relationships that may exist between requirements. And, likewise, the notations and tools used to capture this information are very similar as well. A simple way to structure design decisions hierarchially is in the form of a decision tree. An example of this is given in Figure 3.

Figure 3 - Tree of Design Decisions

Architectual Views
A software architecture serves as a vehicle for communication among stakeholders. Example stakeholders are: end users of the anticipated system, security experts, representativies from the maintenance department, owners of other systems that this system has to interface with, software developers, and of course the architect himself. These stakeholders have a stake, but the stakes may differ. End users will be interested to see that the system will provide them with the functionality asked for. Software developers will be interested to know where to implement this functionality. Maintainers want to assure themselves that components are as independent as possible. In some cases, it may be possible to devise one single architecture representation that serves all these stakeholders. In general, this will not work, though. A specific stakeholder is best served

by a representation of the software architecture that highlights his concerns. Another stakeholder is likely to be better served by another representation. Just think of civil engineering, where one representative may highlight the outer appearance, while another highlights construction aspects. IEEE standard 1471 gives a general structure for software architecture representations. The main elements from this standard are:

Stakeholder: An individual, team, or organization (or classes hereof) with interests in, or concerns relative to, a system.

View: A representation of a whole system from the perspective of a related set of concerns.

Viewpoint: A viewpoint establishes the purposes and audience for a view and the techniques or methods employed in constructing a view.

So the stakeholder concerns determine which representations, called views, are appropriate for a specific software architecture. Each view has a corresponding viewpoint which gives the syntax of the view, much like a construction drawing has an accompanying description telling what the the glyphs in the drawing mean. IEEE 1471 does not tell you which viewpoints to use. In essence, it suggests we develop an appropriate set of viewpoints for each separate software architecture. It does have the notion of a library viewpoint, though, a viewpoint that might be useful across different software architectures. A collection of viewpoints that is useful across a wide variety of software architectures fall into three classes: 1. Module Viewpoints give a static view of the system. They are usually depicted in the from of box and line diagrams where the boxes denote system components and the lines denote some relation between those components. Table 3 describes typical module viewpoints.

Table 3 - Module Viewpoints. Viewpoint Description Elements of the decomposition viewpoint are related by the is a submodule of relation. Larger elements are composed of smaller ones. It is the result of a top-down refinement process. The decomposition viewpoint often forms the basis for the

Decomposition

project organization and the system's documentation. It is the viewpoint we are most use to in software design. The relation between elements is uses (A calls B, A passes information to B, etc.). The uses relation is important when we want to assess modifiability: if an element is changed, all elements it is used by potentially have to be changed as well. It is also useful to determine incremental subsets of a system: if an elements is in a given subset, all elements it uses most also be in that subset. This is a special case of the uses viewpoint. It is useful if we want to view the system as a series of layers, where elements from layer n can only use elements from layers < n. Layers can often be interpreted as virtual machines. Elements are described as a generalization of other elements. The relation between elements is inherits from. It is obviously most applicable for object-oriented systems.

Uses

Layered

Class

2. Component and connector viewpoints give a dynamic view of the system, i.e., they describe the system in execution. Again, they are usually depicted as box and line diagrams. Table 4 describes typical component and connector viewpoints.

Table 4 - Componenent and connector viewpoints.

Viewpoint Description The system is described as a series of processes, connected by communication or synchronization links. It is useful if we want to reason about the performance or the availability ofthe system. To determine opportunities for parallelism, a sequence of computations that can be allocated to a separate physical thread later in the design process is collected in a logical thread. It is used to manage issues related to concurrent execution. Describes how persistent data is produced, stored, and consumed. It is particularly useful if the system centers around the manipulation of large amounts of data. It can be used to assess qualities such as performance and data integrity. Describes a system that consists of cooperating clients and servers. The connectors are the protocols and messages that clients and servers exchange. This viewpoint expresses

Process

Concurrency

Shared Data

Client-Server

separation of concerns and physical ditribution of processing elements.

3. Allocation viewpoints give a relation between the system and environment, such as who is responsible for which part of the system. Table 5 gives typical allocation viewpoints.

Table 5 - Allocation Viewpoints.

Viewpoint Description Shows how software is assigned to hardware elements and which communication paths are used. It allows one to reason about performance, security and availability. Indicates how software is mapped onto file structures. It is used in the management of development activities and for build processes. Shows who is doing what and helps to determine which knowledge is needed where. For instance, one may decide to assign functional commonality to a single team.

Deployment

Implementation

Work Assignment

Of course, you do not have to use all these viewpoints for a single software architecture. Usually, one from each category will suffice. You may, for instance, choose the decomposition, deployment and work-assignment viewpoints. It is also possible to combine viewpoints. In Figure 4 we have combined the decomposition viewpoint and the client-server viewpoint to create a view of our library system. In specific cases, additional architectural views may be helpful or needed. In systems for which the user interface is of critical importance, a separate user-interface view may be developed; in electronic commerce applications, a view highlighting security aspects may come in handy; and so on.

Figure 4 - Three Tier Architecture

Many organizations have developed their own set of library viewpoints. A well-known set of library viewpoints is known as the 4+1 model. It consists of the following viewponints:

a conceptual, or logical viewpoint that describes the system in terms of major design elements and their interactions.

an implementation viewpoint that gives a view of the system in terms of modules or packages and layers.

a process viewpoint that describes the dynamic structure of the system in terms of tasks, processes, their communication, and the allocation of functionality to run-time elements; this view is only needed if the system has a significant degree of concurrency.

a deployment viewpoint that contains the allocation of tasks to physical nodes; this view is only needed if the system is distributed.

The +1 viewpoint is a set of important use cases. This set of use cases drives the architectural design and serves as glue to connect the other four viewpoints. The 4+1 model is part of the Rational Unified Process development methodology.

The above viewpoints are technical in nature. Often, it is also useful to construct one or more viewpoints which emphasize business concerns. Figure 5 gives a business oriented view of our library system. It addresses three aspects of the architecture: 1. Communication 2. Storage 3. Layers For each of the three aspects, several alternatives are given, and, for each alternative, the risk, time to market, and cost are indicated. One alternative for each aspect is chosen. These alternatives are connected by curved lines. In this way, a quick overview is obtained. The view is also easy to grasp for non-technical stakeholders.

Figure 5 - A Business View

Uses of swe design architecture:

-Designing software architectures that maximize reuse and flexibility. -Leveraging software architectures across product lines and families. -- Includes detailed, real-world case studies. Sophisticated development organizations worldwide are discovering the advantages of software architectures in building systems that deliver higher quality, lower development and maintenance costs, and shorter time to market. In this book, one of the field's leading experts addresses the two most important factors in making software architectures work: effective design, and leveraging architectures across product lines. Jan Bosch begins by outlining the rationale for software architectures, and reviewing the limits of traditional approaches to software reuse. Next, Bosch introduces a comprehensive approach to software architecture design that includes explicit quality goals, is carefully optimized up front, and still accounts for the inevitability of change. In Part II, Bosch presents today's best practices for defining architectures that can be reused across entire "lines" or "families" of software. Bosch covers each phase of the software product line lifecycle, including development, usage, and evolution of software assets, showing how to manage interdependencies, and cope with new requirements that were not part of the original design. The book includes several running case studies from real companies that have achieved competitive advantage through software architecture.

Benefits of s/w design archietecture:

In general terms, software architecting is a key factor in reducing cost, improving quality, timely delivery against schedule, and delivery against requirements. In this article I will focus on specific benefits that contribute to meeting these objectives. It is also worth noting that, as an architect, we sometimes have to justify our existence. This section provides some useful ammunition for treating architecting as a critical part of the software development process. Architecting addresses system qualities The functionality of the system is supported by the architecture, through the interactions that occur between the various elements that comprise the architecture. However, one of the key characteristics of architecting is that it is the vehicle by which system qualities are achieved. Qualities such as performance, security, and maintainability cannot be achieved in the absence of a unifying architectural vision, since these qualities are not confined to a single architectural element but rather permeate the entire architecture. For example, in order to address performance requirements, it may be necessary to consider the time required for each component in the architecture to execute, and also the time spent in inter-component communication. Similarly, in order to address security requirements, it may be necessary to consider the nature of the communication between components, and introduce specific "security-aware" components where

necessary. All of these concerns are architectural and, in these examples, concern themselves with the individual components and the connections between them. A related benefit of architecting is that it is possible to assess such qualities early on in the project lifecycle. Architectural prototypes are often created in order to specifically ensure that such qualities are addressed. This is important since, no matter how good an architecture looks on paper, executable software is the only true measure of whether the architecture has achieved such qualities. Architecting drives consensus The process of architecting drives consensus between the various stakeholders, since it provides a vehicle for enabling debate about the system solution. In order to support such debate, the process of architecting needs to ensure that the architecture is clearly communicated and understood. An architecture that is effectively communicated allows decisions and tradeoffs to be debated, reviews facilitated, and agreement reached. Conversely, an architecture that is poorly communicated will not allow such debate to occur. Without such input, the resulting architecture is likely to be of lower quality. On a related note, the architecture can drive consensus between the architect (and his vision) and new or existing members, as part of training. Again, the architecture must be effectively communicated for this benefit to be achieved. Development teams with a clear vision of what they are implementing have a better chance of implementing the product as desired. To this end, it's important to document the architecture appropriately, and this is a primary responsibility of the architect. Similarly, the creation of an architectural proof-of-concept is an excellent way of demonstrating that the architecture either does, or does not, meet the stated requirements. Architecting supports the planning process The process of architecting supports a number of disciplines. Clearly, it supports the design and implementation activities, since the architecture is a direct input to these activities. However, in terms of the benefits that the process of architecting brings, arguably the major benefits are those related to the support provided to project planning, and project management activities in general: specifically, scheduling, work allocation, cost analysis, risk management, and skills development. The process of architecting can support all of these concerns, which is one of the main reasons why the architect and the project manager should have such a close relationship. Much of this support is derived from the fact that the architecture identifies the significant components in the system and the relationships between them. Consider the UML component diagram in Figure 1, which has been kept deliberately simple for the purposes of this discussion. This figure shows four components with dependencies between them.

Figure 1: UML component diagram showing architecturally significant elements In terms of scheduling, the dependencies imply an order in which each of these elements can be considered. From an implementation perspective, for example, the dependencies tell us that the Error Log component must be implemented before anything else, since all of the other components use this component. Next, the Customer Management and Fulfillment components can be implemented in parallel since they do not depend upon one another. Finally, once these two components have been implemented, then the Account Management component can be implemented. From this information, we can derive the Gantt chart (one of the key planning tools of a project manager) shown in Figure 2. The duration of each of the tasks shown does require some thought, but can be partially derived from the complexity of each of the architectural elements.

Figure 2: Gantt chart based on dependencies between architecturally significant elements Clearly, this is a gross simplification for a number of reasons. For example, all of these elements are unlikely to be implemented as a single component, since they're much too complicated for this to be the case. Also, it is possible to create "stubbed" or partial implementations so that implementation of each of the elements can occur in parallel. I use this example to simply demonstrate the principle. In terms of work allocation, the architecture can again help us identify areas that require particular skills and therefore particular resources (people) to which work can be allocated. The architect can also assist in the cost estimation for the project. The costs associated with a project come from many areas. Clearly, the duration of the tasks and the resources allocated to each will allow the cost of labor to be determined. The architecture can also help determine costs

related to the use of third-party components that will be used in the delivered system, and also the cost of any tools that are required to support the development effort, since one of the activities that the architect is involved in is the selection of an appropriate development environment that will allow the designers, implementers and other team members to work together in an effective manner. Another focus of the architect is to identify and manage technical risks associated with the project. The management of technical risk involves the prioritization of each risk, and the identification of an appropriate risk mitigation strategy. The priorities and risk mitigation strategies are provided as input to the project manager. Finally, the architecture identifies discrete components of the solution that can provide input in terms of the skills required on the project. If sufficient resources are not available within the project or within the organization, then this clearly helps identify areas where skills acquisition is required. This may be achieved through developing existing personnel, through outsourcing, or through new hires.

Back to top Architecting drives architectural integrity One of the primary objectives of the process of architecting is to make sure that the architecture provides a solid framework for the work undertaken by the designers and implementers. Clearly, this is more than simply conveying an architectural vision. In order to ensure the integrity of the resulting architecture, the architect must clearly define the architecture itself, which identifies the architecturally significant elements, such as the components of the system, their interfaces, and their interactions. The architect must also define the appropriate practices, standards, and guidelines that will guide the designers and implementers in their work. One of the objectives of architecting is to eliminate unnecessary creativity on the part of the designers and implementers, which is achieved by imposing the necessary constraints on what they can do and making it clear that deviation from the constraints can break the architecture. For this reason, the adoption of appropriate review and assessment activities helps ensure architectural integrity. A focus of these activities is to consider the work of the designers and implementers, and determine the degree of adherence to the architectural standards and guidelines that have been put in place. Architecting helps manage complexity Systems today are more complex than ever, and this complexity needs to be managed. Since an architecture focuses on only those elements that are significant, it provides an abstraction of the system and therefore provides a means of managing complexity. Also, the process of architecting considers the recursive decomposition of components. This is clearly a good way of taking a large problem and breaking it down into a series of smaller ones.

Managing complexity is further enabled by techniques that allow abstractions of the architecture to be communicated. The adoption of industry standards that allow expressing such abstractions, such as UML, is therefore commonplace in the industry today for documenting software systems. Architecting provides a basis for reuse The process of architecting can support both the use and creation of reusable assets. Reusable assets are beneficial to an organization, since they can reduce the overall cost of a system and also improve its quality, given that a reusable asset has already been proven (since it has already been used). The creation of an architecture supports the identification of possible reuse opportunities. For example, the identification of the architecturally significant components and their associated interfaces and qualities supports the selection of off-the-shelf components, existing systems, packaged applications, and so on, that may be used to implement these components. The architecture itself may also prove to be reusable as a reference architecture for subsequent systems. Even components within the architecture may be deemed potentially reusable in other contexts. Although the process of architecting can identify reuse opportunities within the current project, there is a much greater impact when reuse is considered across projects and across the enterprise. Any discussion of reuse should be tempered with a word of caution. Very few reuse programs have been successful to date, for a variety of reasons, some technical and some not. From a technical perspective, a reuse program needs to ensure that appropriate standards, processes, and tools are in place. Fortunately, some foundation elements are starting to be addressed. A good example is the standardization of the Object Management Group's Reusable Asset Specification (RAS),1 which defines a standard for describing reusable assets, packaging reusable assets, and for interfacing to a RAS repository service. From a non-technical perspective, there are organizational considerations that must be kept in mind when implementing a reuse strategy. For example, who is responsible for creating a reusable asset given that it will be used in many contexts? Who maintains the asset once it has been created (and the team that created the asset disbanded)? What incentives are in place for the creation and use of reusable assets? How is the cost of creating a reusable asset, which is almost always more costly than creating one that is not, justified? Architecting reduces maintenance costs The process of architecting can help reduce maintenance costs in a number of ways. First and foremost, the process of architecting should always ensure that the maintainer of the system is a key stakeholder and that their needs are addressed as a primary concern, not as an afterthought. The result should not only be an architecture that is appropriately documented in order to ease the maintainability of the system; the architect will also ensure that appropriate mechanisms for

maintaining the system are incorporated, and will consider the adaptability and extensibility of the system when creating the architecture. The architect should also consider those areas of the system most likely to require change and work to isolate them. This can be fairly straightforward if the change impacts a single component, or a small number of components. However, it should be acknowledged that some changes, such as those relating to system qualities such as performance or reliability, cannot be isolated in this way. This is why the architect must ensure that, when architecting the current system, they consider any likely future requirements, since scaling up a system to support thousands of users rather than tens of users, for example, is not normally possible without changing the architecture in fundamental ways. Architecting supports impact analysis An important benefit of architecting is that it allows us to reason about the impact of making a change before it is undertaken. An architecture identifies the major components and their interactions, the dependencies between components, and traceability from these components to the requirements that they realize. Given this information, a change to a requirement, for example, can be analyzed in terms of the impact on the components that collaborate to realize this requirement. Similarly, the impact of changing a component can be analyzed in terms of the other components that depend upon it. Such analyses can greatly assist in determining the cost of a change, the impact that a change has on the system, and the risk associated with making the change. This information is then used when prioritizing changes and negotiating those changes that are absolutely necessary.