Chapter 2

Stakeholders and Their Business Goals

2.1 Introduction

Systems are created for a given purpose; therefore, it is critical to understand why we are building a given system. No matter how technically elegant, it is no good if a system’s purpose is not clear and it fails to meet its intended objectives. These intended objectives are typically found in the strategic vision that prompted an organization to undertake the development of a system of interest.

Consider a company that sells building automation devices along with software applications that manage these devices. Software helps with the sale of these hardware devices but does not make any money. Over the years, the marketing and sales divisions have come to realize that the hardware is being commoditized and their profit margins on the sale of the hardware devices are shrinking. To sustain their business long term, the vice president (VP) of product development in consultation with the chief technology officer (CTO), decides to create a new building automation system that will be profitable. They wish to accomplish this by doing two things: reducing internal development costs and expanding the market. Internal development costs can be reduced by replacing several of the existing applications with a single building automation system. Market expansion can be achieved by entering new and emerging geographic markets and opening new sales channels in the form of value-added resellers (VARs). VARs sell the new building automation system under their own brand to support building automation hardware devices of many different manufacturers.

What are the intended objectives of the new building automation system? Do you think these objectives will significantly influence the architecture of the system of interest? Who are the stakeholders for these objectives?

2.2 Influence of Business Goals on the Architecture

The development of the new building automation system is prompted by the following business goals:

• Reduction in internal development costs
• Expansion of the product market
• Partnering with VARs

Market expansion requires taking language, culture, and regulatory concerns of different markets into account. Partnering with VARs requires the new building automation system to work with hardware devices from many different manufacturers. Reduction in development costs may be achieved through consolidation of development and maintenance efforts for disparate software applications.

Certain business goals (such as market expansion and partnering with VARs) can give rise to requirements that can have a significant impact on the architecture of a system of interest; others (such as reduction in cost) may not (Sangwan and Neill, 2007). Depending on the context, there can be many such influential goals. Although in the case of a building automation system they were fairly explicitly stated, on other projects there may be a need for engaging stakeholders to elicit these goals. To help with this process, Table 2.1 lists typical categories of business goals that apply to projects undertaken by corporations.

There is some overlap within these categories, but the intent is not for them to be mutually exclusive. They are simply there to serve as a vehicle for facilitating the elicitation of business goals from the stakeholders of a system under design.

When eliciting these objectives, care must be undertaken to engage all stakeholders from the organizations involved in development, acquisition and operation of a system that can include any group or individual affected by or in some way accountable for the outcome of an undertaking. Because arriving at an agreed-to set of these objectives can be a long and arduous process, it is important also to know who the primary stakeholders are that exert a greater degree of influence on a project and have the authority to help resolve conflicts when they arise (National Aeronautics and Space Administration [NASA], 2007).

2.3 Representing Business Goals

A business goal scenario is a six-part structure that makes a business goal concrete and actionable (Clements and Bass, 2010):

• Goal subject (GS): the stakeholder who owns the goal
• Goal object (GO): the entity to which the goal applies
• Environment (E): the context for the goal
• Goal (G): the goal itself
• Goal measure (GM): the success criteria for a goal
• Pedigree (P): background that includes identification of the person or artifact providing the goal statement, how much confidence there is in the goal, the goal’s expected volatility over time, and the goal’s value

We show the business goals for the building automation system in Table 2.2. Initially, the business goals may be captured informally as shown in the middle column and later expressed as detailed scenarios shown in the leftmost column in Table 2.2.

2.4 Refining Business Goals

One observation to make is that business goals can be fairly broad, such as a company’s desire to be profitable, and may need refining. As also pointed out previously, we must carefully examine the business goals and see if they give rise to requirements that have an influence on the architecture of the system under development. For example, profitability may be achieved by making changes to the business processes of a company and therefore may not have anything to do with the architecture of the system to be developed.

Table 2.3 shows the business goals and their relevance to the building automation system introduced in the previous section. Business goals are synonymous with mission objectives, a term typically used by the Department of Defense (DoD) and NASA when creating architectures of weapon and space systems (NASA, 2007). Just like business goals are refined to determine how they apply to the system under development, mission objectives are refined into operational objectives, some of which would be relevant to the product being engineered. The relevant operational objectives are sometimes called engineering objectives.

Notice that the reduction in internal development costs can be achieved by aggregating the development and maintenance functions of several small applications into one project for the building automation system. It has more to do with changes to the organizational structure than the architecture of the system to be developed and therefore is not included in Table 2.3.

2.5 Translating Engineering Objectives into Architectural Requirements

Another important observation to make is that business goals relevant to a system correspond to quality attributes the end system must exhibit. These quality attributes become the basis for translating the business goals and their associated engineering objectives into architectural requirements. For instance, a business goal to maintain market reputation can correspond to creating products that are highly usable and reliable and perform well. Can you think of some of the quality attributes that correspond to the business goals of the aforementioned building automation system?

To support a multitude of hardware devices and consider different languages and cultures, the building automation system must be able to accommodate these changes easily (a modifiability requirement). To support different regulations in different geographic markets, the system must respond to life-threatening events in a timely manner (a performance requirement). It is critical that the business goals and their implied quality concerns be fully understood because they are the very reason a system is created. They will play a significant role in the creation of architecture for a given system. If ignored or not fully understood, you risk creating a system that may not be fit for its intended purpose. We list some predominant quality attributes (Bass et al., 2013) and their description in Table 2.4.

Table 2.5 lists the business goals, their refinement (showing relevance to the system under consideration), and their corresponding quality attributes.

Quality attribute requirements must provide sufficient detail to be truly useful. As an illustration, imagine you are the architect for the building automation system and suppose you have a requirement that the building automation system must be modifiable with respect to the hardware devices it must support from different manufacturers. Do you think the requirement is sufficient in its given form?

It may not be sufficient to say that a system must be modifiable. Any system is modifiable with respect to something, and a system can be modified with respect to any aspect given enough time and money. The question relates to its modifiability with respect to what, when, and the amount of effort needed to do so. The given requirement for the building automation system clearly states the what, but not when and how much effort. It may be more useful to state the requirement as follows:

A field engineer is able to integrate a new field device into the system at runtime, and the system continues to operate with no downtime or side effects.

Now, it is clear that a new field device (what) has to be added at runtime (when) by a nonprogrammer (how much effort).

This form of expressing a requirement is called a quality attribute scenario (Bass et al., 2003). Stated this way, the quality attribute requirement is more concrete. Architectural design decisions can be made to satisfy the requirement, and the system can be tested to see if it meets this requirement.

A quality attribute scenario is a requirement with six parts: a stimulus, the source of stimulus, an environment, an artifact, a response, and a response measure. These six parts for the scenario just described are as follows:

Stimulus—integrate a new field device

Source of stimulus—field engineer

Environment—runtime

Artifact—the system

Response—system continues to operate

Response measure—with no downtime or side effects

So, the stimulus is something that incites a system, the source of stimulus is something that generates the stimulus, the environment is the condition under which the stimulus is generated, the artifact is the part of the system that is affected by the system, response is the reaction of the system to the stimulus, and response measure is a way for measuring the system’s reaction.

2.6 Prioritizing Architectural Requirements

Because they are the drivers for the architectural decisions, the first task is to determine the important quality attribute requirements for a given system. You may have observed one important aspect of quality attribute requirements is that they typically conflict with each other. For instance, trying to increase the security within a system through the use of encryption may have a negative impact on its response time. For any given system, therefore, you can only have a handful of such requirements; otherwise, they can create conditions that make conflicts challenging to resolve.

How might you go about discovering this set of most important quality attribute requirements for a system under consideration?

One approach may be to consider a standard taxonomy of quality attributes such as International Organization for Standardization (ISO) 9126. You may examine each quality attribute in this taxonomy and see how it applies to your system. As you go down the list, it will be hard to find any quality attribute that does not apply. After all, who will say that their system does not need to be secure, reliable, usable, testable, scalable, and so on? So, this approach does not seem practical.

Another way you could approach this problem is to examine each function to be supported by the system and ask the stakeholder for that function to describe some quality attributes associated with that function. Again, it would be hard for any stakeholder to resist saying the function desires should be high performing, secure, reliable, usable, and so on. This approach seems even worse than the first one because the quality attribute requirements in this case will be some multiple of the total number of functional requirements. Clearly, this number is much more than a handful.

A pragmatic approach is to elicit quality attribute scenarios from stakeholders that directly relate to the business goals for a system. Because there are only a handful of business goals, the same will apply to the quality attribute scenarios. More significantly, these would be the most important scenarios to consider if one is to create a system that fulfills its intended purpose (Ozkaya et al., 2008).

Quality Attribute Workshop (Barbacci et al., 2003) is an architecture-centric method that can be used for eliciting quality attribute requirements from the stakeholders of a given system. The goal of this method is to establish a prioritized set of quality attribute requirements in the form of quality attribute scenarios that are mapped to the business goals. Clearly, it is important that these goals are known before the workshop can be conducted even if they are initially general and will need subsequent refinement.

Table 2.6 shows a prioritized set of scenarios derived from the business goals for the building automation system.

The priorities are based on how business critical a quality attribute requirement is. High (H) means the customers would not consider the product if that requirement is not satisfied, medium (M) means the product would not be competitive in the absence of that requirement, and low (L) means it is something nice to have.

2.7 Summary

The ISO/IEC (International Electrotechnical Commission) 42010 standard was introduced briefly in Chapter 1. This chapter explored the shaded portion of this conceptual framework shown in Figure 2.2.

It is important to know who are the key stakeholders with a vested interest in the system under design. The stakeholders have concerns that define the purpose for which the system is being created. These concerns are expressed as business goals or mission objectives and can have a significant impact on the architecture of a system. Therefore, they must be used as a starting point for determining architecturally significant requirements. Because not all business goals may be relevant, they must first be refined into engineering objectives that relate them to the system under design. The engineering objectives are then refined into quality attribute scenarios. Because these scenarios may conflict with each other, they need to be prioritized, and only a handful of the most significant ones should be considered to avoid complex trade-off situations.

2.8 Questions

1. The Pareto principle states that, for many events, roughly 80% of the effects come from 20% of the causes. If we were to apply this 80–20 rule to the systems development world, we can argue that 20% of the highest-priority features can satisfy 80% of the business needs. In other words, 80% of the features seldom add value to the system under consideration (see Johnson, 2002). How does a clear focus on business goals or mission objectives when creating a system help avoid non-value-added work?
2. Why is it important to refine business goals into engineering objectives?
3. Life-critical systems typically have a requirement to operate continuously. Refine the appropriate business goal for the building automation system into an engineering objective for continuous operation.
4. Map the engineering objective in problem 3 to a quality attribute and elaborate it using a quality attribute scenario. Identify the six parts of the scenario.
5. Look at the automotive systems case study presented in this chapter. List all the important business goals, refine them into engineering objectives, identify the implied quality concerns, and develop at least one quality attribute scenario corresponding to these concerns.

References

M. Barbacci, R. Ellison, T. Lattanze, J. Stafford, C. Weinstock, and W. Wood, Quality Attribute Workshops (QAWs), third edition (CMU/SEI-2003-TR-016). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2003.

L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, third edition. Boston: Addison-Wesley, 2013.

P. Clements and L. Bass, The business goals viewpoint, IEEE Software, November/December, 2010, pp. 38–46.

International Organization for Standarization. ISO/IEC Standard 9126: Software Engineering — Product Quality, part 1. 2001.

ISO/IEC/IEEE Systems and software engineering—Architecture description, ISO/IEC/IEEE 42010:2011(E) (Revision of ISO/IEC 42010:2007 and IEEE Std 1471-2000), pp. 1–46, 2011.

J. Johnson, Chaos Report. Boston: Standish Group, 2002.

J. Mossinger, Software in automotive systems, IEEE Software March/April 2010, pp. 92–94.

National Aeronautics and Space Administration (NASA), Systems Engineering Handbook (NASA/SP-2007-6105 Rev1). Washington, DC: NASA Headquarters, December 2007.

I. Ozkaya, L. Bass, R. Sangwan, and R. Nord, Making practical use of quality attribute information, IEEE Software, March/April 2008, pp. 25–33.

R. Sangwan and C. Neill, How business goals drive architectural design, IEEE Computer, August 2007, pp. 101–103.