10.4 What Do We Model?

Although the UML Specification talks about modeling "software-intensive systems" (Rational Software Corporation 1999, 1 7), it leaves that idea largely undefined. A better way to look at systems modeling is in terms of the three elements that go into making a software product and that form, in a loose way, the real system behind any application, as illustrated in Figure 10.1.

Figure 10.1. The elements of a system product.

Typically, modeling is not just about the end product itself. Instead, designers model the architecture, the domain and the solution, in the process of arriving at a model of the product. Each of these can be looked at and modeled in a recursive fashion. And increasingly, with component-based and iterative development, and the focus on reuse at every level, modeling will build on previously developed models by means of refinement and refactoring instead of being an exercise in reinventing the wheel.

10.4.1 Architecture

As an abstraction, an architecture provides a high-level view of the system or portions of the system. It highlights the most important elements and key features of a system and provides a framework for the details. It is not the design (or as Jacobson, Griss, and Jonsson [1997] maintain, the design is not just the architecture). Rather, it is the embodiment of the strategic decisions around organization and structure for a given technical or business solution.

For a system, architecture is recursive: a system embodies an architecture and also reflects exogenous architectures of different types, such as the enterprise architecture and the network architecture. In fact, architecture provides a "context for the systematic integration of IT into business and a conceptual framework for thinking about the business itself" (Wladawsky-Berger 1999, 449) that facilitates strategic alignment and functional fit.

At the level of an application, an architecture is a structured representation of the pieces of a system and the connections between them. It may include dynamic elements (explanations of behavior) as well as static elements (explanations of organization). It is not the system design; as Philippe Kruchten writes: "Architecture is what remains when you cannot take away any more things and still understand the system" (1998, 78).

It is multi-leveled and loosely recursive. For example, the architecture of an application is constrained by the technical architecture of its target environment and shaped by the enterprise architecture it services. In turn, the technical architecture may be made up of a network architecture, a service architecture, a workstation architecture and more.

An application may be a packaging of components. Each component might have an architecture itself if coarse-grained, or it may adhere to an architectural framework that provides the key standards for its development and use. In most cases, this architecture will be standardized; Enterprise JavaBeans is an example. Component purchases will more than likely need to be managed through contracts that specify architecture as well as services and interfaces because only the architecture can provide a measure of the complexity of a component, and therefore a handle on the risk.

The multiple uses of the term architecture in systems actually cover three similar but different ideas: architecture itself, framework, and topology. The UML metamodel I described briefly is a good (although abstract) example of an architecture model. A framework is narrower in scope, typically covering a specific domain or even an application: a financial suite architecture would be one example. Finally, a topology is more like a map; a network architecture showing the deployment of LANs and routers would be an example.

Even though the distinction that I drew between the three types is not part of the standard vocabulary of systems, it suggests using different types of models for each architecture type:

A conventional layered, static model for an architecture.
A package of collaborations for a framework.
A deployment diagram for a topology.

And, in fact, this seems to be an emerging pattern.

The idea of architecture requires more discussion, not the least because the UML has made architecture an active ingredient in modeling to such an extent. Therefore, I'll return to it in detail a little later.

10.4.2 Domains

A domain is an area of interest (the typical dictionary definition of domain) with the following:

A vocabulary of business abstractions (events, concepts, things) that can be shared across applications
A common set of needs and, perhaps, opportunities

A domain provides the immediate context for software development, and defines the scope of the area of interest and focus of attention for a solution.

This is my definition, synthesized from the multiple variations being used. The idea of domains, like the idea of systems' best practices that I discussed earlier, is in the eye of the beholder. For a software developer with a reuse perspective, a domain may be a family of applications or a product line that is, a collection of products. For someone doing business re-engineering, it may be the overall enterprise or a functional area.

Domain engineering and analysis are recent additions to the development toolset, and so there's still a lot of terminological churn around domain. Beneath the hubbub, they added a key area (beyond those of scope, context, and vocabulary) that needs to be modeled in the face of an emerging emphasis on reuse: commonality/variability.

Domain models define boundaries and scope for engineering, design, and management. They provide the common vocabulary that brings together the development team and the user community. They are created with or by domain experts (the stakeholders formerly known as subject matter experts). They are analyzed for elements of commonality that can be factored out to provide a basis for high-level reuse. Within a domain, chunks of significant variations provide the basis for distinguishing individual products.

A domain can and should be modeled in a fashion that is equally as recursive as an architecture. The enterprise as a whole, or even an interpolation of enterprises, may need to be modeled to provide the context and vocabulary for the problem space. The result, an enterprise model, is used to align a high-level technology architecture with the strategic direction of the business.

For example, shared systems that support multiple co-opetive organizations by providing shared services and a common infrastructure need to be modeled across organization boundaries. Supply chain and extranet-based systems may need to be modeled similarly, without regard to the fading "Berlin Walls" of organizational boundaries.

Of course, there are multiple even overlapping domains within an organization that can be viewed and modeled, depending on the focus of the analysis and the business needs to be served. A functional perspective may serve the operational aspects of the organization. A workflow perspective may serve the customer-driven aspects of an organization.

Chapter 6, "Domain Patterns," provides a picture of the essential elements of domain modeling based on the previous discussion. However, some development approaches extend the notion of domain. Jim Coplien talks about concepts such as problem domains and solution domains in his latest writings. The Shlaer-Mellor methodology breaks a system down into multiple interacting domains, including an application domain (the area of interest to the end user) and a variety of technical domains, covering the technology and infrastructure aspects of the system.

10.4.3 Products

A product is both narrow and extensive. On the one hand, it is what is delivered to the customer one slice at a time. On the other, it is what is managed by the producing organization, through its life. Ultimately, a product is what is planned, managed, and delivered to the end user as a unit.

Products have a life and a lifecycle that is separate from the development lifecycle, especially now with iterative design and incremental delivery. They are birthed, introduced, evolved, matured, and theoretically have a sunset. Whether internal to an organization or sold on the open market, they need to managed and modeled beyond the boundaries of a single development project, and provide the context for specifying and designing each development spurt. The product "owns" the design artifacts, including the requirements.

10.4.4 Solutions

In some ways, the great technological achievement of the nineteenth century was the discovery of systems. The focus of technology innovators shifted from the individual tool or invention the machine to the whole environment that was needed to make a piece of technology practical, useful, and profitable. Both Edison and Ford were examples of whole system thinking: for example, the electrical lamp required the provision of generating stations, distribution facilities, and a marketing infrastructure. A product was not enough.

In the schema you're exploring, a solution is the total package what Geoffrey Moore, the technology marketing guru, called a "whole product" in his influential book Crossing the Chasm (1991, 110 135). It's the idea of the product extended to include varying perceptions of the product and an enlarged understanding of what is needed to make a product successful. Although Moore's book is about marketing new technology, rather than developing it, many of the points he raises need to be part of the design process to help shape the models that are produced. They provide an additional aspect of product context, beyond what's identified from investigating the domain.

Essentially, in discussing the idea of a product, Moore says he is leveraging the work of Theodore Levitt (1984). According to Moore, Levitt suggested that there's a gap between the marketing promise made to the customer and what the customer gets.

This is familiar territory to software developers, for whom managing user expectations is a skill as critical as marketing, and for whom communications among the players in a development effort is never perfect. Anyone who's been in software development for any length of time has seen the cartoon that shows a swing built by IT as understood from the perspective of the roles of analyst, designer, programmer and user. What the user wanted, a board hanging from a tree branch by two ropes, ends up as a tire suspended across the trunk of a tree. The tree is held up on poles, with a hole in the trunk to accommodate the swing.

Levitt identifies four perspectives for a product, which, as I interpret them for software development, include the following:

The generic product what the user gets.
The expected product what the user thought he or she was getting the minimum configuration needed to satisfy the user.
The augmented product the product fleshed out in a way that will meet the maximum expectations of the user.
The potential product the product's room for growth as supporting products become available and enhancements are made.

Each is a slice of the product in time as envisioned by the designer.

Moore uses a PC as an example. The generic PC is the basic box. The expected product includes a keyboard, monitor, and mouse. The augmented product includes a printer, some software, training, and real support. The potential PC could include blue-sky add-ons such as voice recognition and an integrated development environment. (Since Crossing The Chasm was published in 1991, its influence has become obvious in the way that PCs are marketed today.)

These perspectives are worth incorporating into the design and planning process for software, and some might be useful to model as part of an incremental development lifecycle. For example, one corollary consideration Moore presents is that the different types of product may be useful at different stages in the life of a product; with early adopters, for example, being more forgiving and adaptable when presented with a product that is generic.

Moore offers his own vision of the whole product that is more directly and obviously applicable to thinking about a solution. It provides the basis for that outside-the-box thinking that needs to be a part of the modeling exercise. His version has two components rather than the four product types: the product as delivered and the supporting services and features that need to be provided to make the purchase and use successful. So, his whole product diagram includes items such as testing, installation, training, and documentation. These are all aspects of a successful development effort that need to be considered early on, rather than at the end, and need to be evolved as the development effort proceeds as well as over the life of the product.

These insights can be applied usefully within an organization as well. The Software Engineering Institute, source of the Capability Maturity Model, is currently working on a process for facilitating the adoption of new technology that interprets Moore's ideas.

Neither Levitt's nor Moore's version of whole product thinking in defining a solution is supported directly or even required by the UML. Despite an understanding that products evolve, both when being designed and after, there's not much in the UML to support a product lifecycle or whole product thinking. Both fall into the category of items that need to be documented and made part of the model packaging as text and non-standard diagrams that supplement the UML diagrams.

Perhaps this is a good thing. As Desmond D'Souza and Alan Wills write, the emphasis should be "on small fragments of models interleaved with explanatory prose" (1998, 708) by using narrative text to communicate the informal elements rather than glossy diagrams in a picture book. In a sense, this approach consists of applying the whole product idea to UML models themselves.