Models and Application Life-Cycle Management

Clemens Reijnen

Ir. Robert Deckers

June 2010


Summary: This article discusses the creation and maintenance of consistent, correct, and communicative software architecture by using Microsoft Visual Studio 2010.



Setting up, validating, and maintaining consistent, correct, and communicative software architecture in its context and interaction with its environment is no trivial task.

A new architecture needs to be created. But how do you know if this architecture is good? Covering all areas, dealing with all the requirements and quality attributes is difficult; but forgetting to discuss one or more is easy and will leave space for assumptions.

Because of changing requirements, your architecture needs to be changed. But how do you know if it is still consistent? Unstable documents and models will confuse the development and test teams, who will not know what to build or what the intention of the system is.

How can you make practical use of the Microsoft Visual Studio 2010 modeling capabilities in the application life cycle and an architectural approach, to cover these challenges and create good software architecture?


Good Software Architecture: An Approach

Software architecture gives direction to the realization of a software system, which must fulfill business goals. This software architecture has to be correct, consistent, and communicative when it has to cover the needs of these business targets. When you focus on these aspects of software architecture, you can determine that the architecture is indeed good when it is:

  • Correct. The architecture is based on validated statements that cover the system environment and, especially, stakeholder interests. These statements are prioritized. The final architecture is the balance between all of these prioritized statements.
  • Consistent. Architectural decisions do not clash. The architecture is checked for completeness, consistency, accessibility, and translatability into application life-cycle management (ALM) artifacts, configuration items, and work items such as test cases, sources, and maintenance documents.
  • Communicated. The architecture is communicated and checked with the stakeholders, who know their relationship with and influence on it. The physical architecture and architectural decisions must be communicable, and stakeholders must find the right spot for them.

Reasoning Model

To support the creation of a correct architecture, we use a reasoning model (see Figure 1) that is based on DyA|Software.1 This model helps the software architect with decision-making and—even more importantly—with analysis of the correctness and consistency of the architecture.

During the application life cycle of a system, including the realization process (the software-development life cycle [SDLC]), a system is influenced by changes in requirements and planning, differences among project teams, and more. All of these changes must be fitted within the architecture and vice versa. Given these different changes by and for different people, the widespread diversity of aspects makes architecture creation an interesting task. The reasoning model helps to cover all of these aspects of software architecture.

There are three dimensions about which an architect must think in relation to the system. These are the application domain, the construction domain, and the development domain:

  • Application domain—Addresses what the system means for the customer—the end user of the system. This domain describes the goals, needs, business value, use cases, functionality, and quality of the system.
  • Construction domain—Addresses the elements from which the system is built—the components, the interfaces, and so on—as well as the design patterns, necessary infrastructure, and other technologies.
  • Development domain—Addresses the processes or methodologies that are used for realizing the system. These include organizational structures, road maps, knowledge, roles, people, and outsourcing.

Figure 1. Reasoning model

Decisions that are made in these three domains all have their influences in the environment of the system, the borders of the system, or the system itself. Every decision in a domain has to be related to a decision in the other domains, so as to get a correct and consistent architecture.

For example, a statement such as, "The customer must be capable to edit his/her own information" (which has its place in the customer-value section) will influence all of the different domains. The application must have a capability for user logon, and there must be a subsystem for customer information that is based on the technology that is used. Construction statements are made that have an influence on team members, who must have experience with these types of application and technology. As for the planning, the statements also have their influences, which may result in a team per subsystem or a component per iteration.

Every domain is connected; statements about one domain must be covered by statements in the others domains to get a correct and consistent architecture. When a statement is not related to another, you have a dead end; when two statements interfere, you have a challenge.


Design & Realization in the Application Life Cycle

As described in the previous paragraph, good architecture is based on a set of statements—requirements that are connected to and influenced by each other—and is translatable into consistent ALM artifacts (see Figure 2), so that people to whom the architecture is communicated will understand it and can add their knowledge to it. However, none of this can be realized in an ivory tower. To design and realize good software architecture, one that has value throughout the application life cycle, you must work together with—and be connected to—all team members, with their different roles, as well as all influencers outside the system.

Figure 2. Application life-cycle management (ALM)

During the design, realization, and maintenance of a system and its corresponding software architecture, you must write down (that is, document) the architectural description—the whole set of architecture statements and the prioritization of these statements, for validation and communication. How the architectural description is documented and what kind of documents and tools are used depends on the project methodology that is used. However, to get information about consistency and checks (if there are any contradictions), it is necessary to have a repository that has history capabilities or version-control capabilities that can collect statements.

This ambiguities characteristic counts not only for the software architecture; the combination of architecture with code, architecture with requirements statements, and architecture with planning also has to be seamless. You can say something about the quality of the system and architecture only when you can see the whole picture and the relationship among the different parts.

It is useless to create and use a structure or a terminology for requirements that does not fit the separation of the proposed architecture, so that pieces of the system do not relate to a requirement. The same counts for the project road map and work packages in the project planning; these also must fit the system architecture. A team per subsystem that has specific knowledge is one way of planning.


Valuable Models

It is possible to put all of this—correct, consistent, and communicative architecture—in place without the use of any kind of tooling. At a minimum, a whiteboard can be used (and sometimes communicated by making pictures of it). However, as agile and flexible as this way might be of making an architecture work, it does not fulfill all of the needs for good architecture, as previously described. Traceability, validation, and even communication of these models are difficult. This will result either in stricter communication and project-management rules or in chaos. The models have value only at the beginning of the application life cycle and in the application domain (see Figure 1). There is no possibility to get traceability and validation among the different statements and no possibility to say something about the quality of the system.

A set of disconnected tools (every role in the application life cycle has its own toolset) has the same missing capabilities. While the maintainability of models is much easier throughout the life cycle of the project, it is difficult to get the validation in place. In validation, as described in an earlier paragraph:

"Every domain is connected; statements about one domain must be covered by statements in the other domains.... When a statement is not related to another, you have a dead end; when two statements interfere, you have a challenge."

This validation must be performed manually, which is difficult. It is difficult to get a statement about the correctness and consistency of the architecture and corresponding models.

From the use of a whiteboard to the use of more sophisticated tools, models will get more and more value in the application life cycle when they can be validated for correctness and consistency. Quality is maintained throughout the application life cycle; and, when a tool supports this value with sophisticated features to connect and communicate with other roles in the application life cycle (see Figure 2), this value will be easier to maintain. Models that are created by using a whiteboard have value only in the application domain. Models that are created and used by using disconnected modeling tools have a wider value; they can be used and reused during the life cycle, although validation is difficult. The use of a connected tool, in which every role in the application life cycle can look at and validate its statements, will create even more valuable models.

Figure 3. Visual Studio 2010 ALM tools

The Visual Studio 2010 ALM toolset (see Figure 3) is one such connected and integrated ALM environment. For a long time, there has been support for processes and work items (the realization domain, as previously described) by using Microsoft Team Foundation Server (TFS). The configuration-item support for source code is one of the first features that everybody uses; it supports the construction domain, and the connection between change sets and work items covers a validation mechanism that is needed to check the consistency between the construction domain and the realization domain. With the support of models—UML, Direct Graph diagrams, and Layer diagrams in Visual Studio 2010—capabilities to support the application domain are also added. Not only do the models add this support for creation of good architecture, but the connection of the configuration items and work items to these models makes them more valuable. This connection—the integrated work environment—makes the models so valuable. While this is the first version of UML support in Visual Studio (and, surely, other tools have more sophisticated and extended UML-modeling capabilities), the seamless connection to the other roles in the application life cycle makes it a true game-changer.

The paragraphs that follow discuss a work pattern for how to use Visual Studio ALM features to check statements in the different domains, as described in the previous paragraph (see Figure 1), and how you can validate and check your architecture in a seamless, collaborative, and easier way.


Models in the Life Cycle

Visual Studio modeling tools cover more than UML support. Besides several UML diagrams (Activity, Use Case, Sequence, Class, and Component), there is a layer diagram that checks the implementation and an architecture explorer that analyzes the system. The architecture explorer lets you visualize any kind of reference, dependency in your solution, or other assemblies. All of these models live together with the code as configuration items in a central repository that is accessible by every team member. This kind of capability will support the creation of a correct and consistent architecture, in which every decision in one domain of the reasoning model has a related decision in another domain. This support comes from the fact that Visual Studio 2010 has not only UML tool features, but also capabilities to link modeling artifacts to other ALM artifacts, such as work items and other configuration items.

Figure 4. Linking work items to model elements

This capability—linking and referencing configuration items and work items—and the capability for every role in the ALM to have access to the information make the models valuable in the full life cycle of the application. This definitely supports the creation and usage of a good architecture.

User Stories, Requirements, Work Items, and Models

In the application domain (see Figure 1), statements are made about customer value. The domain addresses what the system means for the customer—the end user of the system. This domain describes the goals, needs, business value, use cases, functionality, and quality of the system. These "customer value" statements can be named user stories in an agile project or requirements in a more formal project. In both types of project methodology, these necessary pieces of customer value are captured in work items within TFS (see Figure 5).

Figure 5. User-story work-item type

To get everything in place, to visualize all of the aspects of the customer-value domain, create in an iterative process the high-level scope—the use cases.2 With Visual Studio 2010 in place, you can also capture this information about actors and processes in a use-case diagram. Linking these diagrams to the work items will give both the creator and the reader a better overview, if all important spots are targeted (see Figure 4). User-story work items that do not have a connection to a use case (and vice versa) give a good indication of inconsistency.

Visualized in a metamodel, this connection—among user goals, use-case diagrams, and user-story work items in the application domain of the reasoning model—will resemble what appears in Figure 6. (Please refer to Sneak peek at the first "Feature Pack" for VS2010 Visualization and Modeling Tools.)

Figure 6. Metamodel: Application domain, user goal (connected with use-case diagram), and user-story work item

Use cases are descriptions of system functions that cover user goals and give a good starting point and overview of what the system must fulfill. They are discussed with the customer and supported by activity diagrams,3 which can also be linked to work items and from use cases. This linking of model elements, diagram shapes, and lines with work-item types such as user stories and requirements is a key feature for keeping the architecture consistent. For example, a change in a use-case diagram points to a corresponding requirement that has a breakdown in tasks or subrequirements (this will help to keep the different corresponding artifacts consistent). Another example can be a project manager who looks at use cases that do not have a corresponding activity diagram or user story. The manager knows that there is something wrong.

We can start to break down the customer needs into tasks and supportive software components. Create the corresponding statements in the other two domains.

Components, Layers, and Scenarios

In the previous paragraph, the application domain and user needs are captured and modeled by using work items and UML diagrams. In the construction domain, statements must be set according to technology, system elements, patterns, components, and interfaces. All of them must be consistent with the application domain; surely, some iteration between them will take place.

Adding the construction domain to the metamodel will result in what appears in Figure 7. A scenario is supported by a function that is implemented by a component. This results in a component diagram.

Figure 7. Metamodel application domain and construction domain, covered by Visual Studio 2010

A layer diagram is created up front to cover layer-diagram patterns that are used in the solution. The layer diagram in Visual Studio 2010 has a great feature: It can validate the implementation. Using this, the layered architecture can be checked for consistency between design and implementation, which definitely will help to maintain a good architecture (see Figure 8).

Figure 8. Visual Studio 2010 layer diagram

Together with the layer diagram, a component diagram is drawn. While the layer diagram is not UML-compliant, the component diagram is. A component diagram virtually holds the same kind of information as a layer diagram, although it is much more detailed with regard to the communication ports and internal parts (see Figure 9).

Figure 9. Component diagram

To have good architecture, we must have statements in the construction domain that cover statements in the application domain. For example, when a statement such as, "As a user, I want to be able to set the output template, so that I can support different formats" does not have a component and interface that support this functionality, you know that the architecture is incomplete or incorrect. There are two ways to create a component diagram.

You can start drawing sequence diagrams that are based on the most important application flows of the system, based on the use cases and corresponding activity diagrams. With the messages and components that are used in the component diagram, we can start drawing the components, parts, and interfaces.

The other way is actually the opposite direction; based on the layer diagram, you can start drawing the main components and interfaces. From there, you can start replaying the main scenarios by using sequence diagrams, checking if there are some inconsistencies in the component, parts, and interface design. The Visual Studio 2010 component diagram has a feature that creates lifelines for components in sequence diagrams.

The interaction between the artifacts that are used in the application domain, use cases, activity diagrams, and linked work items (user stories or requirements) and the artifacts that are used in the technology to create that high-level architecture is a true iterative process. To get the statements in one domain to fit the statements in the other domain, we must go back and forward between them.

As described in the metamodel (see Figure 7), the activity diagram in the application domain is a realization of the use case—the user needs. These needs are supported by functions that are implemented by components. These components, in turn, can be validated by replaying the scenarios in the activity diagrams by using sequence diagrams—thus, creating a setting from which you can check the architecture for consistency and correctness—supported by Visual Studio 2010 capabilities for linking and validating (layer diagram) the different artifacts with each other.

Methodology, Tasks, and Road Maps

In the application domain, statements are made about customer value. The application domain addresses what the system means for the customer—the end user of the system. This domain describes the goals, needs, business value, use cases, functionality, and quality of the system—written down in work items such as user stories or requirements and drawn up in use-case diagrams and activity diagrams, all of which are connected by work-item links. The artifacts in the construction domain—such as components, layers, and sequence diagrams, and the resulting implementation code and configuration files that fulfill these needs—are validated by replaying scenarios from the activity diagram, which is also connected. So, we can check the architecture for consistency and correctness between the application domain and construction domain and, certainly, within each domain itself.

As mentioned in the first paragraph, a good architecture also covers the development domain. It must address the processes—the methodologies that are used for realizing the system—including organizational structures, road maps, knowledge, roles, people, and outsourcing.

Adding the development domain to the metamodel will result in what appears in Figure 10 (starting at the bottom of the model). A component is built by an implementation that is a result of an implementation task, which is part of a development plan. This development plan holds the methodology and tasks that must be executed to realize the use cases. In Visual Studio 2010, the work item-type user story (or requirement), which is used to hold the user needs, can hold several other (hierarchical) work items (see Figure 5)—the implementation and test-case tabs. Using this connection, we can organize the development plan based on the tasks that must be executed to realize the functions that are needed for that use case. And this makes the circle complete.

Figure 10. Metamodel: DyA reasoning model, covered by Visual Studio 2010

One other addition to the metamodel is the test task, which validates the function that supports the scenarios in the activity diagram. This test task is part of the test specification that is derived from the activity diagram—using some kind of test methodology, such as a process cycle test. These test tasks are again part of the work items that serve the user goals, user stories, or requirements.

With this, every domain in the DyA|Architecture reasoning model is covered, and validations are checked against each other. When, for example, there is a completed implementation task that is not part of a user story, we know that we have dead code. The same goes for test cases. When a test case does not belong to a scenario that is written down in an activity diagram, we know that there is not a corresponding statement in the application domain. With this, we have a "kind of" methodology-agnostic mechanism for validating an architecture with regard to consistency and correctness.


It is possible to maintain and organize the separate responsibilities—project planning in a planning tool, architectural models on the whiteboard or drawing program, requirements written down in documents—but the important connection is not there. Validation of statements is difficult and carries a risk of creating an inaccurate, unreliable architecture. As an application life-cycle tool, Visual Studio 2010 covers solutions for many of the challenges that exist, as described in the preceding article and metamodel. Not everything is supported by automation, such as automation of the validation between the implementation and the layer diagram; the links between models and work items must be maintained manually. But having all of the roles working with just one single repository of configuration items and work items is a great start.

We do expect more validations of statements over the different domains, which will make the Visual Studio 2010 models that are used by projects even more valuable in the future. But this is a great way to start creating a good architecture in the application life cycle.


  1. DyA: DYnamic Architecture, an architectural approach by Sogeti Netherlands.
  2. See
  3. See


About the Authors

Clemens Reijnen is a software architect at Sogeti and was awarded Microsoft Most Valuable Professional (MVP) by Microsoft. With over 20 years of experience in IT, he has a broad background in software development and architecture. Clemens runs a technical blog on and is coauthor of Collaboration in the Cloud: How Cross-Boundary Collaboration Is Transforming Business (Groningen: Microsoft and Sogeti, 2009). You can reach Clemens at

Ir. Robert Deckers is a senior software architect and architecture consultant at Sogeti. He is founder of the DyA|Software approach and is writing a book (to be released in summer 2010) about this approach. You can reach Robert at