From Stakeholders to Models: It Is All a Matter of Viewpoints
Summary: An article on viewpoints and views, the differences between them, and why you should care. (3 printed pages)
"It was six men of Indostan
To learning much inclined
Who went to see the Elephant
(Though all of them were blind),
That each by observation
Might satisfy his mind."
–"Blind Men and the Elephant," John Godfrey Saxe, 1878
It was the first week of the new millennium and I was sitting in my office trying to recoup from the New Year's parties of the weekend, when Tami entered my office and asked if I would be interested in taking the lead software-architect position for "the project." I must have been a little drowsy, as I immediately said, "Yes." As it turned out, "the project" was a huge software-intensive multidisciplinary beast that sucked all of my personal life for the next three years. On the onset, I was pretty confident. I had successfully architected a few solutions, I had good technical know-how, and I was well-versed with Rational Unified Process (RUP) and its 4+1 views. My first task was to create top-level candidate architecture as part of the proposal. That went pretty well, but then we won the tender, and things started to get complicated—fast.
I was in charge of producing two deliverables. The first was the overall software/hardware architecture, which is a consolidated design document that shows all of the interaction points of the different disciplines. The second deliverable was, of course, to design the software's architecture. Because the project was overly large, we worked in several integrated product teams (IPTs). My team included system engineers from various backgrounds: safety engineers, video experts, mechanics-system engineers, network experts, geographic information systems (GIS) experts, embedded-systems experts, command and control experts, software designers, UX persons, and a few others, including a customer representative. It was certainly a challenge working with so many stakeholders. I quickly learned that they were interested in many different things. Here are few of the concerns that they had:
- The mechanics-system engineer wanted to know how many "U"s our equipment was going to take up on the racks.
- The network guy wanted to know how much data we were going to send and receive, would we be using broadcast, would it be point-to-point, how many video streams we wanted, and so on.
- The safety engineer wanted us to help him calculate mean time between failures (MTBF), mean time between critical failures (MTBCF), mean time to repair (MTTR), to produce hazards lists, and analyze faults.
- The embedded guys wanted us to calculate the needed CPU power and memory sizes, decide on the system-to-system protocol, and so on.
- The software designers wanted us to partition the work as quickly as possible, and in a way that would allow their teams to work as independently as possible.
I looked at the 4+1 views that I knew from RUP and tried to see how they mapped to the different stakeholders' concerns. This is what I thought:
- The Use Case view seemed to be a pretty good fit that would allow us to reach a common understanding of what's needed. It seemed that it would be good for prioritizing requirements, too.
- The Logical view, which describes functionality, would be a good fit to allow describing the customers' concerns.
- The Implementation view was a very good fit for the developers' and designers' point of view.
- The Process view seemed OK for the developers, as well as a good fit for the integrators.
- The Deployment view seemed to address some of the concerns of the mechanics-system engineers.
Uh-oh. It seems the RUP was falling short of providing ways to address aspects of the architecture, which in my project were very important—aspects such as security and safety concerns. Another disturbing fact was that if I was going to document the various views thoroughly (that is, by the so-called book), I was going to end up with a tome hundreds of pages long that, frankly, nobody ever reads—a phenomenon affectionately known as a Write-Only Document.
OK, I was thinking, what should I do now? Luckily, massive-scale search engines were already available back then, and I managed to find an IEEE standard—which was still a draft at the time. As I read the standard, things finally started to click into place.
The standard is IEEE 1471-2000, also known as Recommended Practice for Architectural Description of Software-Intensive Systems. It describes a conceptual framework of the relations between architecture, architecture description, stakeholders, concerns, viewpoint, views, and models, as well as how to approach them. Some of the components in the IEEE 1471 conceptual framework are beyond the scope of this paper—for instance, the relations and definition of SYSTEM, environment, and architecture itself. However, there are a few concepts in the standard that are very important for this discussion, and they can be summed up as follows:
The architect should choose viewpoints from a viewpoint repository to cover the concerns that the different stakeholders have. The architect can then prepare models to detail views and make each of the views conform to a viewpoint.
Before I go back to my story and show how this helped solve my problem, I want first to clear up the terms and the intention behind the preceding paragraph:
- A stakeholder is any person who has some vested interest in the project. Typical stakeholders include customers, developers, maintainers, and upper management.
- A viewpoint is a pattern or generalization of a view. The viewpoint defines the rules for the viewpoint. The aforementioned 4+1 views that the RUP defines should actually be called the 4+1 viewpoints, if we use the standard's terminology. Viewpoints are selected according to the concerns of the stakeholders.
- A view is a representation of the whole system, as seen through the prism of specific concerns. A view can be regarded as an instance of a viewpoint. A view consists of one or more models that represent it.
- A model is an abstraction or simplified representation of a system or part of a system. Models are created by using standardized notations such as UML or E-R diagrams, as well as non-standardized notations such as block or arrow diagrams.
- As viewpoints are system-agnostic, they are basically templates; thus, we can also build ourselves a viewpoint repository and reuse viewpoints when needed.
- A viewpoint repository or viewpoint library is just a name for the set of viewpoints that an architect knows about and on which an architect can draw to find a viewpoint suitable for their immediate needs.
The understanding that I gained from IEEE 1471 was that we architects can—and should—define viewpoints to address all of the important concerns that we and our stakeholders have, whether or not the methodology that we follow supports them. The multiple viewpoints also help ensure that all of the system's quality attributes are really met. What I did then was to sit with the different stakeholders and try to understand what it was that they needed to know. I then described a set of viewpoints that I thought suited that project. (As an aside, I would say that it was nice to see in retrospect that the templates and viewpoints that I devised then ended up as the company's software-architecture document template for all software projects.)
Let's look at a few of the viewpoints that we ended up using:
- For the system engineers, we created a Deployment view that included a UML deployment model, to give an overall view of the deployment within each site. We also included a non-standard diagram that showed the layout of the hardware on the racks and the cables that connected them.
- For the Security view, we created some data-flow diagrams (DFDs) to help model threats. We also created block diagrams to show all of the subnets, VLANs, firewalls, routers, and so on.
- For the Safety view, we included the significant fault-tree models, as well as sequence and block diagrams to show how possible faults and problems would be averted.
Lessons Learned and Takeaways
One underlying premise—of which I was already aware when I started this project—is that there is a need to describe the architecture, so that it can be communicated to stakeholders. This description can be formal or casual, depending on project type, company culture, standards used, and so on.
Another thing to pay attention to is how much detail goes into each model. If you just draw everything, you are missing the point. People who try to understand the architecture will be lost in the details and will be unable to grasp the big picture. Remember that architecture is about the big decisions that affect the whole solution. Make sure that these decisions are understood.
The viewpoint is the class (or template), the view is the instance, and models are the artifacts from which the view is made.
You can look at the literature and your experience to create a viewpoint library. When you must describe architecture, you can draw upon your library to look for the viewpoint that best fits your needs.
The most important lesson, however, is that viewpoints and views are two of the core tools in our arsenal when we set out to design a new architecture. Using multiple views is essential for both designing architectures (so that we can make sure that we did not miss any important aspects) and describing the architecture (so that we can explain to the different stakeholders how their concerns are met). If we fail to look at a system from different perspectives, we run the risk of ending up just like the blind men of Indostan—thinking that we are dealing with all sort of things, but never really understanding that we are actually facing an elephant.
- With which viewpoints are you familiar?
- When would you use a viewpoint? A view? A model?
- Who were the stakeholders for the last project that you designed? What were their concerns?
- What viewpoints did you miss in the last architecture that you designed?
- IEEE Recommended Practice for Architectural Description of Software-Intensive Systems (IEEE Std 1471-2000). New York, NY: Institute of Electrical and Electronics Engineers, Inc., 2000. [ISBN: 0-7381-2518-0]
- Clements, Paul, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord, and Judith Stafford. Documenting Software Architectures: Views and Beyond. Boston, MA: Addison-Wesley Professional, 2002. [ISBN 0-201-70372-6]
- Hohmann, Luke. Beyond Software Architecture: Creating and Sustaining Winning Solutions. Boston, MA: Addison-Wesley Professional, 2003. [ISBN 0-201-77594-8]
- Rozanski, Nick, and Eóin Woods. Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives. Boston, MA: Addison-Wesley Professional, 2005. [ISBN 0-321-11229-6]
- Kruchten, Philippe. The Rational Unified Process: An Introduction (3rd Edition). Boston, MA: Addison-Wesley Professional, 2003. [ISBN 0-321-19770-4]
RUP—Rational Unified Process. An architecture-centric process by Rational (now IBM). (See the Further Study section, for more information.)
About the author
Arnon Rotem-Gal-Oz is a manager and architect with extensive experience in building large, complex, distributed systems on varied platforms (ranging from HP-UX and Solaris to AS400 and Windows). Arnon blogs at www.rgoarchitects.com/blog and writes the Dr. Dobb's Portal blog on Software Architecture & Design at www.ddj.com/dept/architect. You can contact Arnon at firstname.lastname@example.org.
This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.