WICSA 2009 BBGA:Business Goals and Architecture

From WICSA Conference Wiki

Birds-of-a-Feather Session

When: Tuesday, 15 September 2009, 18:00 – 19:00

Organizers: Len Bass and Paul Clements (Software Engineering Institute)

Participants (Tentative):

Please sign your name here if you are thinking of attending this BoF. (Click the signature button in the editor). Tell us something about your background. Add a few sentences about the working session topic such as your position, questions you would like to see discussed, etc.

• --Bob Schwanke, Siemens Corporate Research. Although the business goals of the organization ultimately control the priority of the quality attributes, there is often a chicken-and-egg relationship between them. For example, I once participated in an extremely high-profile project that did not define its own business case until 12 months into the project, when enough stakeholder engagement had taken place to work out a winning strategy.
• --David Emery, DSCI. what's not quite clear to me is whether there is a distinction between business goals that the business user/customer can articulate, and technical goals or requirements that are derived from how to implement the business goals. My question is motivated by the observation that a lot of the "ilities" that drive architecture are essentially derived from, rather than being explicitly stated "this is how we run the business" goals.
• --Paul Clements, Software Engineering Institute. We've preached for years that quality attribute requirements drive architectures, but where do they come from? In some of the SEI's methods, we've tried to capture business goals, but haven't done it systematically. Now we think we can. We recently held a pilot workshop with a large company in which the business goals for a new system were captured, and tied to quality attribute requirements -- some of which were a surprise to the system's owners. I look forward to discussing this link between BGs and QAs with the group.
• --Eltjo Poort, Logica. There is an interesting debate going on about quantification of quality attributes, see eg. Glinz's article in IEEE Software last year, about the cost vs. utility of the quantification itself. Business goals are often stated either extremely vaguely or quantified in financial terms. It will be interesting to see how the quantification topic fares in both the business goal and the quality attribute arena.

Call for Participation

It is long established that architectures are largely shaped by quality attribute requirements: requirements to achieve specific measures of performance, availability, security, modifiability, and so forth. Quality attribute requirements that shape the architecture, which we call architecturally significant requirements, are therefore of prime interest to the architect. But where do they come from? We argue that quality attribute requirements exist to achieve business goals of the developing organization and/or the consuming organization(s). High performance, for example, may be required to out-perform a competitor's system, which serves the organizational goal of staying in business. Efficient computing may be required to satisfy a need for low power consumption, which satisfies the business goal of contributing to society by reducing greenhouse gas emissions.

In this BOF session, we will discuss the role that business goals play in architecture, and how the architect can use business goals to spot missing requirements early in the life cycle. We will begin with a presentation about our research into business goals, and present a prototype method for eliciting and capturing business goals for use by an architect.

Contributions

If you have relevant materials or references, please add here:

Meeting Notes

This section started out as the notes that Bob actually took during the meeting, but is being extended as people remember things that Bob did't record, or simply expand the discussion.

Note: BG means business goal

Participants were interested in discussing the following topics:

• How Systems support BGs
• Quantification of BGs
• Affect of trust relations on handling BGs
• Passing BGs across contractual boundary
• Relation between BGs, reqts, architecture, and design (BGs as requirements)
• BG evolution and system evolution (How can systems be built to allow changing BGs)
• Conformance of system and BGs (How does architect know that BGs are met?)
• Business value of architecture
• How can architect argue that BGs are met because of architecture decisions?
• Can BGs be used to explicitly identify and prioritize QA requirements?
• How is architecture influenced by structure of organization?
• How does architect find missing BGs?

Next we tried to talk about what the term "business goals" really means. This note-taker only half-heard the discussion, but offers the following (biased) interpretation.

The term business goals assumes first of all that the activity that produces a software-intensive system is some sort of business, usually a for-profit business. The leaders of the 'business' decide to invest time and money in producing a software-intensive system, based on its ability to help advance a set of goals. While the business may have goals unrelated to the system, or only partially advanced by the system, all these nuances can be handled by referring to a document, typically called the business case for the project, which identifies the business goals that are relevant to the project and explains why the project makes sense for the business to undertake. (Of course, some projects never get such a document, or the document turns out to be completely incorrect, but such is life.) (Note: business case and business use-case are totally unrelated terms. Do not confuse one with the other.)

In the special case of contract software development, where another business ("the customer") is paying a contract software development company to do the work, there will be two business cases, one for the contract software development company, and one for the customer business. As always, some aspects of the customer's business case for the project may be left unstated, to everyone's peril.

--Bob Schwanke In my thinking, the business case is the ultimate rationale for selecting all the other project stakeholders; only the business that is funding the development has the right to designate which other stakeholders' opinions are relevant to the project. All other project requirements are justified by a concerned stakeholder. Hence, every influencing factor (cf. Applied Software Architecture: A Practical Guide for Software Designers by Hofmeister, Nord and Soni)

only has an impact on the project because the business case justifies considering it.

We then took a straw poll from the participants' topics list above and decided to discuss the following:

How can architect argue that BGs are/will-be met because of architecture decisions?

Assumptions

• BGs are stated and reasonably well understood
• ? Architecture has been specified ?
• ? System has been implemented ?
• ? System has been deployed and is at least partially fulfilling its goals ?

Rather than choose a particular timepoint in a particular lifecycle model, we observed that business goal evaluations could be performed at any time in a project, based on whatever partial or complete artifacts were available. To make that concrete, we considered the following artifact dependency reference model:

Business goals <-- Requirements <-- Architecture <-- Implementation <-- Test Results <-- Deployments <-- Implemented Change Requests <-- Business goal evaluation

The arrows above represent document dependeny, a relation that is transitive. Thus, a business goal evaluation depends on all of the other artifacts, but they need not be complete for the evaluation to take place; some of them could even be empty.

After setting all this context, we ran out of time without actually getting to the topic. So, we agreed to meet back here on the wiki and continue the discussion.

--Bob Schwanke This makes me think about the relationship between the two business cases in the case of contract software development. If the two cases conflict, which one takes precedence? I believe that the contractor's business case tells the team how to interpret the customer's business case, but it is a delicate challenge to keep the customer from learning which of his business goals are being taken less seriously than others ... Similarly, supposing that the contractor discovers that he cannot complete the project within scope, cost, schedule, and quality. His decision about how to trade off these parameters may not be to the customer's liking, but may be completely compatible with the customer's business goals.