ISO/IEC/IEEE 42010 (following the philosophy of its predecessor, IEEE 1471:2000) is deliberately process- and method-neutral. The Standard does not specify any specific process or architecture method, nor does it place any explicit requirements on a process or method. Essentially, the standard covers the output of an architecting process, without providing any help on how to construct such a process.
This page sketches one way to apply IEEE 1471 as part of an architecting process. By no means is this the only way, and the best thing is to take the thoughts in here and integrate them with your existing systems/software development practices. This builds on the approach documented in "Experiences applying a practical architecture method", by David Emery, Rich Hilliard and Tim Rice from way back in 1995. The goal of this process was to come up with an architecture description (AD) that meets both the formal requirements and the underlying intent of IEEE 1471.
We refer to the architect as implying one or more individuals responsible for the definition of the architecture, and more formally for the production of the Architecture Description. The term document used here implies an artifact that can be distributed and reviewed, including the ability to view appropriate data from an architecture repository.
To place architecting in context, we view it as an activity that runs roughly in parallel with systems analysis and requirements definition activities. In a perfect waterfall, systems analysis would produce perfect requirements and these would (serially) feed an architecture process that implements those requirements. However, in practice, architecting is best done concurrently with systems analysis and requirements definition activities, resulting in a set of requirements and an architecture that meets those requirements, and allowing for feedback between analysis activities, specification activities, and architecture activites. In short, a good architecting process should facilitate the discussions about what is feasible, hard, costly, etc, early in the overall development process. But that's all we will say here about where architecting would fit into a larger system/software engineering life-cycle.
Formally, the inputs to this architecting process are:
The outputs from this process are:
This process has four steps:
Steps 1 and 2 include a recommendation for a review as part of that step. Step 4 concludes with a formal review of the architecture.
IEEE 1471 formally requires that an AD document its Stakeholders and their Concerns (clause 5.2). In practice, this activity has often been overlooked, but there is substantial value in architecting to make this an explicit process step, including a review.
As described in IEEE 1471 (see clauses 1.3 and 4.2), the architecture for a system has many stakeholders, some of which traditionally have not been considered as part of design processes. For example, the people paying for the architecture, and paying for the system, have a stake that the architecture and the system it describes be affordable. People who will sustain the system after it has been delivered need to understand how the system's architecture supports their activities. Every stakeholder for the architecture should have at least one concern (otherwise, they wouldn't be a stakeholder!).
The architect starts by listing all the potential stakeholders for the system and for the architcture of the system. For each stakeholder, s/he lists the concerns that the stakeholder has on the architecture or on the system. This is a classic brainstorming activity. Concerns are often phrased as questions that the stakeholder might ask of the architecture, such as, How much will this cost? or Will this run in our existing computer environment, or do we need to buy more/different computers? or What are the major components that we need to build, and how big is each component?
The architect refines this list, looking for overlaps and gaps, to produce a document listing the recommended stakeholders and concerns. S/He then takes this list back to the stakeholders, to validate the set of concerns. [TBD: Link to Reviewing ADs.] One way to validate the list of stakeholders and concerns is via a relatively formal review meeting, assembling the stakeholders, walking them through the set of concerns, and obtaining their buy-in: If the architecture addresses these concerns, it will meet your expectations. Where the set of stakeholders and concerns is too large (e.g. We don't have time/budget to consider everything on this list.), this meeting gains stakeholder buy-in on the prioritization of the concerns. One approach to conducting this review is to apply the SEI's Quality Attribute Workshop, where the quality attributes are explicitly linked to stakeholder concerns.
Now that the Architect know the questions which must be answered (listed as stakeholder concerns), the next step is to figure out how to best answer them. There are two parts to this: what the answers are and how they can be captured. Within IEEE 1471, there is an explicit separation of view (what the answers are) and viewpoint (how they are captured). This allows for the development of reusable viewpoints separate from any specific architecture project.
One good approach is to start with the list of stakeholder concerns, and a list of existing viewpoints you are familiar with. (The "4+1" viewpoints identified by P. Kruchten are a good example of a set of widely used viewpoints [4+1].) Your organization may require a given set of viewpoints, or you might have a set of existing templates (even in PowerPoint) that you have used previously.
Working with your starting set of viewpoints, walk down the list of concerns, and tag each concern with the viewpoint or viewpoints, that might be used to frame those concerns. Viewpoints make it possible for the resulting view to address the concern. Next, consider those concerns that do not have any associated viewpoint. Are there ways you can add information to an existing viewpoint to address that concern? If not, then sketch out a new viewpoint to address that concern.
When you have a set of candidate viewpoints that covers the set of concerns, you should then look at this set to see if you can consolidate/minimize the number of viewpoints. (This follows from the AD as a set of views, where each view implements a given viewpoint; minimizing the number of viewpoints minimizes the number of views, and hopefully reduces the cost and effort for completing the set of views.) There is no hard-and-fast set of rules for how many viewpoints are enough or too many, although experience has shown that 7±2 viewpoints has been typical for many systems.
Next examine each viewpoint in detail. Does the viewpoint definition clearly identify what information needs to be captured in the viewpoint? Does it specify how that information is to be represented (i.e. what are the architectural models to be used, in IEEE 1471 terms.) Does the viewpoint provide adequate guidance to the architect about how to tell when a corresponding view is complete, i.e. to determine, How much is enough?
Now consider the set of viewpoints as a whole. What connections should be made about information in viewpoints? For example: If one viewpoint says "list the software components" (e.g., Kruchten's logical viewpoint) and another viewpoint says "list the computers" (e.g., Kruchten's deployment viewpoint), presumably there should be a rule that says every software component in the architecture should be associated with at least one computer.
Another consideration in viewpoint development is to make sure that the viewpoints are consistent with organizational tools and repositories. This should be a two-way street, in that the organizational tools should clearly support the needs of the architecture. Where architectural data is captured in an integrated repository, a viewpoint may be defined as a "projection" of the contents of that repository, including the ability to represent the consistency rules. Still, the needs of the architects should drive the tools, and not the other way around. A well-defined set of viewpoints can form the basis for obtaining the right tools, to get the tools in place before work starts on populating the views for this architecture.
Finally, it is important to get a review of these viewpoints by at least some of your stakeholders, particularly the developers who will use the architecture description, and any independent assessors or QA people who will evalute both the architecture and the system's conformance to the architecture. This ensures that everyone understands what will be in the view, before you invest the time and money to start creating it. (Experience has shown that it is easy to avoid this step and spend a lot of time/money developing a view, only to find out that the representation or contents of that view really don't match expectations. Best to get agreement on the viewpoints before starting work on the views.)
With this step complete, you are ready to start the main event, creating the views that actually describe your architecture. Additionally, having a well-defined set of views facilitates planning and costing subsequent architecture development efforts.
This is where the "heavy lifting" occurs during architecting. A well-defined set of viewpoints should make it easier for the architect/architect team to capture architectural decisions.
What happens here is basically dependent on what is required by each viewpoint. As the architect develops the view, it is important to capture rationale for the key decisions, and include that in the AD (see clause 5.6).
Every AD should undergo some sort of evaluation of the architecture being described, against stakeholder concerns and related considerations (e.g. Quality Attributes for the architecture, as in the SEI's ATAM).
This step gathers up views from Step 3 (which might have been constructed by multiple team members working somewhat independently.)
One key consideration in an architecting process concerns view consistency. IEEE 1471 requires that each view be consistent (and the interpretation of this requirement should be that each view is consistent at time of delivery—clearly this is not intended to apply throughout the production of the view.) But IEEE 1471 allows a conforming AD to have two views, each of which is complete, to be inconsistent with each other. (Using the previous example, this would allow the existence of some software components in a logical view that are not allocated to a hardware component in a deployment view.) Clearly cross-view consistency is a goal, but it was the perspective of the authors and reviewers of IEEE 1471 this is often too difficult to achieve in practice, given limited resources for executing an architcture. Instead, the requirement in IEEE 1471 (clause 5.5) is to record known inconsistencies and provide an analysis of same.
As part of the integration of the architecture, the architect should re-look each viewpoint and in particular any rules about cross-view consistency. She should verify that each view correctly implements the viewpoint, and that the contents of each view fully covers the system as a whole from the perspective of that view.
There should be at least one formal review of an AD and the architecture it documents, and that review is the primary output of this step. To start this review, there needs to be a way to capture and baseline the AD as a review artifact. (When handling paper documents, this is pretty easy. When the data for various views is contained in one or more data repositories, it becomes more difficult to establish a baseline across repositories and tools that may have no mechanisms for versioning or configuration management.)
SARA [pdf] and the SEI's ATAM are two documented methods for reviewing an architecture. Architectural reviews depend on having good descriptions, so the architect should perform substantial "pre-flight" checks and inspections to make sure that his/her AD accurately and completely captures the architecture.
Resources for the ISO/IEC/IEEE 42010 website provided by Olimpia.com. Comments, corrections, suggestions on this site to: Webmaster.This note was written by David Emery; it is is a work-in-progress: please send comments to webmaster.