Illustrative Example of Architecting Process

This section illustrates the core architecting process by using a concrete but simplified example to demonstrate the essential steps. A more detailed version of this example is also provided in the Appendix, Section A5.

The illustrative system is called a Severe Climates Anemometry System (SCAS) [9.10], and it contains the six major functions, and a set of subfunc-tions, as listed below:

1. Atmospheric Sensing

1.1 Wind speed

1.2 Wind direction

1.3 Barometric pressure

2. Mechanical Service

2.1 Instrument housing

2.2 Instrument orientation

3. Environmental Service 3.1 Ice control

4. Power Service

4.1 Main supply

4.2 Regulation/conditioning

4.3 Backup power

5. Indoor/Outdoor Transmission

5.1 Power

5.2 Signal

5.3 Physical linkages

6. Data Handling

6.1 Collection

6.2 Processing/storage

6.3 Reporting, distribution, and display

As a next step, we are specifically interested in the fact that there are alternative design choices that we can make in order to implement each of the functions and subfunctions. We array our design choices in a tabulation that follows from Table 9.1, and in this case, becomes Table 9.3.

We note that we are building three architectures, one each for a low-cost system, a high-effectiveness system, and a baseline system. The latter is our attempt at trying to find the ''knee-of-the-curve'' system, as illustrated in Figure 7.5. The three architectures are constructed, in this case, at the sub-functional level. For the first subfunction of wind speed sensing (subfunction 1.1), the architect selected a commercial-off-the-shelf (COTS) pitot tube. In moving to the other two architectures, the architect added a hard-wired transducer, and then a radio transducer. This was the choice of the architect (or the architecture team) in order to add capability (effectiveness) in moving from left to right on the table.

For the case of wind speed direction (subfunction 1.2), the architect decided that all three alternatives should be based upon a simple shaft drive design choice. Further, the same three design choices for subfunction 1.1 were used in subfunction 1.3. Moving to subfunction 2.1, the architect went from an aluminum solution to a molded composite solution, to composites that are more compact and weigh less. Three different choices were made as well for the orientation/position subfunction 2.2. The process of selecting design choices for each subfunction continued until all functions and subfunctions were considered.

The important point is that this core architecting process goes beyond the mere articulation of system functions and subfunctions. It focuses upon the design (synthesis) process whereby alternative design choices are made at the subfunction level. Further, this is structured so as to produce only three alternatives, but ones that have a cost-effectiveness basis for ultimately choosing which of the three will turn out to be the preferred architecture.

In most cases, the architect thought that each architecture should have a different set of design choices. In two, the same design choice was selected across the board (i.e., for subfunctions 1.2 and 4.1) The selected choices were based upon the expertise of the architect and his or her subject knowledge in this particular domain. If a team is utilized to carry out this process, it is likely that better solutions will be forthcoming, since a team is able to draw upon the expertise of many instead of just one or two. In its very compact form, Table 9.3 can be thought of as the ''synthesis'' step in the top-level architecting of a system. Each subfunction is addressed, moving from left to right across the three alternative systems. Once the entire chart has been filled in with alternative design choices, the architecting team must scan each al-

TABLE 9.3 Alternative System Architectures for Anemometry System



Low Cost


High Effectiveness


Atmospheric Sensing


Wind speed sensing

COTS pitot tube

COTS pitot with

Add radio tranducer



Wind direction sensing

Simple shaft drive

Simple shaft drive

Simple shaft drive


Pressure sensing

COTS pitot tube

COTS pitot with

Add radio transducer



Mechanical Service


Instrument housing

Machined aluminum

Add molded

Less weight/compact




Wind-vaned COTS

Less tail boom length

High-precision bear/




Environmental Service


Ice control

Analog feedback

Add digitized control

Add process & heat

temperature control



Power Service


Main power supply

Commercial 220/110 V

Commercial 220/110

Commercial 220/110 V




Power regulation/


Add ground fault

Add lightning arrester




Backup power


Gas generator with

High-reliability diesel


with switch


Indoor/Outdoor Transmission


Power transmission

Stranded wire harness

Stranded wire harness

Custom slip rings


Signal transmission

Foil-shielded wire

Coaxial with slip

2-way radio, no wiring




Physical linkages

Shaft/conduit, pressure

Add shielded

Minimum shaft-physical





Data Handling


Data collection

Potential and indoor

Magnetic position

Optical position sensor

Pneumatic cell



Data processing/

Manual database entry

Automatic computer

Automatic computer





Reporting, distribution,

Physical meters manual

GUI + modem access

DBMS + packet network

and display

ternative from top to bottom in order to confirm that the selections, within a system, are compatible and interoperable. If they are not, then changes have to be made to assure harmonious intrasystem operation, that is, that the selected design choices within a system will ''play together.'' If the team has formulated more than three design choices for one or more subfunctions, it may then be appropriate to expand the number of alternative architectures to be considered.

The next step in the architecting process is to formally evaluate the three alternatives in terms of their costs and effectiveness. This step is the ''analysis'' part of the process, and it is clearly a critical one. Although the architect has attempted to construct low-cost, high-effectiveness, and ''knee-of-the-curve'' architectures, it is only by analyzing the three alternatives that we are able to see what the cost-effectiveness profiles turn out to be.

A simplified analysis procedure is illustrated in Table 9.4, following the construction suggested previously in Table 9.2. Five specific criteria are developed, namely:


Human factors




Weights are developed for these criteria, and the three alternative architectures are evaluated on a scoring system of from 1 to 10. Each score is multiplied by the corresponding weight, and the resulting products are summed to obtain a total score for each of the alternatives. At the same time, the costs for these alternatives are determined. In this example, the results are:

Alternative Score Costs

Low-cost system 6.8 200K

Baseline system 8.1 250K

High-effectiveness system 8.4 400K

The question at this point becomes: which of the above three alternative architectures does the architect wish to put forth as the preferred architecture? If we treat cost as an independent variable (CAIV), we can plot the above scores (as a measure of effectiveness) against the costs to obtain the points shown in Figure 9.4. This graph illustrates the pattern shown in Figure 7.5. The low-cost system is verified to have both the lowest cost ($200K) and the lowest effectiveness. The high-effectiveness system has the highest cost ($400K), and also the highest effectiveness. The baseline system is in the middle, showing a significant effectiveness improvement over the low-cost

TABLE 9.4 Evaluation Framework for Architecting Illustrative System

Low Cost Baseline High Effectiveness

TABLE 9.4 Evaluation Framework for Architecting Illustrative System

Low Cost Baseline High Effectiveness

¿valuation Criteria



Weight X Score


Weight X Score


Weight X Score









Human factors





































Costs of alternatives




Effectiveness score

High effectiveness

High effectiveness

Effectiveness score

Baseline t •




^ Low cost

Cost, thousands Figure 9.4. Cost-effectiveness view of system.

100 200 300 400

Cost, thousands Figure 9.4. Cost-effectiveness view of system.

system, but without a major increase in cost. Indeed, for this example, the baseline system ''looks like'' the knee-of-the-curve solution. The graph of Figure 9.4 is the third element in the architecting process, since it provides an important ''view'' of the cost-effectiveness results of the first two steps (i.e., synthesis and analysis). The alternative that the architect puts forth as the preferred architecture now depends upon what the customer is ultimately looking for as well as the constraints under which he may be operating. Indeed, if you, the reader, imagine that you are the customer, you will be able to construct a case for any of the three as preferred, based upon the scenario that you envision (see Question/Exercise number 9.8).

The example described here is a ''boiled down'' version of the one in the Appendix, with some modifications in the interest of simplifying the presentation. By referring to the Appendix, one will see that there are actually a set of subcriteria for each of the five major criteria, as listed below in Table 9.5. Other variations on these themes, as for example in the scoring system, may be employed by the architecting team to explore sensitivities, as suggested earlier. Also, as the team is able to spend the time required for a true and objective set of measurements of effectiveness, confidence in the architectural

TABLE 9.5 Top-Level and Subordinate Evaluation Criteria for Anemometry System [9.10]

• Evaluation Criterion 1—Performance

1.1 Vaning function/stability

1.2 Average power consumption

1.3 Impact resistance/robustness

1.4 Speed of data processing

1.5 Data availability

1.6 System availability

1.7 System reliability

1.8 Useful life

• Evaluation Criterion 2—Human Factors

2.1 Ease of use

2.2 Operator safety

2.3 Bystander safety

• Evaluation Criterion 3—Maintainability

3.1 Frequency of scheduled maintenance

3.2 Ease of maintenance

3.3 Complexity of assembly

• Evaluation Criterion 4—Risk

4.1 Cost risk

4.2 Schedule risk

4.3 Performance risk

4.4 Technological risk

• Evaluation Criterion 5—Other

5.1 Manufacturability

5.2 Market potential/demand

5.3 Appearance /aesthetic quality

5.4 Expandability /upgradability solution will grow, in most cases. If not, a change in the alternatives may be called for.

Having explored in this chapter a variety of ways to look at the matter of architecting a system, we are now in a position to formulate the following recommended short-form definitions of an architecture, a preferred architecture, as well as architecting:

Architecture. An organized top-down selection and description of design choices for all the important system functions and subfunctions, placed in a context to assure interoperability and the satisfaction of system requirements

Preferred Architecture. A choice among several architectures that is balanced, cost-effective, and most congruent with the stated requirements and what the customer is seeking, as tempered by program and/or system constraints

Architecting. A process with the following simplified steps: (1) functional decomposition of the system, (2) construction of design choices for all important functions and subfunctions (synthesis), (3) evalution of the resultant interoperable system alternatives (analysis), and (4) display of the results so as to facilitate the selection of a preferred, cost-effective architecture from among the constructed alternatives.


All alternative architectures referred to before are designed to satisfy all stated system requirements. That is, the low-cost, high-performance, and baseline architectures are developed such that all requirements are met. A ''95% solution'' is a term, coined by this author, to refer to a system architecture that, instead of satisfying all of the system requirements, is designed to meet only 95% of the requirements. The number 95, in this context, is more heuristic than it is precise. The notion flows from Rechtin's observation [9.1] that extreme requirements work against the balance necessary in architecting systems, ''creating unexpected misfits and deficient performance.'' Indeed, Rechtin makes his point very strongly: ''[E]xtreme requirements should remain under challenge throughout system design, implementation and operation.''

On this basis, as well as trade-off statements made in various standards, another conceptual alternative architecture to the low-cost, high-performance, and baseline alternatives has been added, namely, the 95% solution, which satisfies 95% of the stated requirements. To achieve satisfaction of the additional 5%, extreme prices may have to be paid in terms of schedule and cost. Put another way, if the system developer can build a system that satisfies 95% of the requirements, and at the same time reduce both schedules and costs by significant amounts, then it is an obligation of the developer to make that alternative known to the customer. In such a situation, the 95% alternative would be added to the evaluation framework shown in Table 9.2 and that alternative would be compared to the other three alternatives in terms of the set of evaluation criteria. Special notations would have to be added to make it clear as to the precise requirements that have not been met as well as the level of performance that is achieved by the 95% solution in relation to these requirements. With the 95% solution, the developer is basically saying to the customer: If I had the freedom to back off from the stated requirements, here is the system architecture that I would recommend that would represent the best balance among requirements, performance, cost, and schedule. Although this approach flies in the face of many current system procurement practices, it also implicitly suggests that perhaps a reformation of some of these practices is in order.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment