TN_1112: System Portfolio Management

Bill Gibson, Program Manager
Microsoft Corporation

The System Designer is used to design configurations of applications and other systems for deployment. The ability to compose systems means that complex configurations of nested systems can be defined. This note discusses the design of portfolios of systems and issues that may arise.

Systems

Visual Studio Team Edition for Software Architects is based on the System Definition Model (SDM), which provides a type system for expressing the structure of computer systems. The Application Designer and System Designer are used together to design and document application systems. The Application Designer is used to define applications—atomic systems composed of resources such as assemblies, configuration files and other resource files. The System Designer is used to define (application) systems—configurations of applications and other systems. Application definitions and system definitions are stored in individual version-stamped SDM documents.

For more information, see Understanding the System Definition Model, Understanding Applications and the Application Diagram, and The Role of the System Designer.

Why Use Systems?

In this release, the primary scenario for the System Designer is the composition of simple systems for purposes of deployment validation. This requires a logical datacenter definition that describes the application hosting capabilities of a datacenter or a portion of a datacenter. Deployment validation is always done in the context of a specific system. At its simplest, you can use the default system created automatically by the Application Designer. In some simple cases, this default system may be all you need, but it is not intended to be used as the basis of any significant deployment and handles only cases where the deployed application configuration mirrors that used in the development environment. For a more detailed discussion on the use and limitations of the default system, see Understanding the Default System.

To go beyond the default system, you must design systems explicitly. Doing this still doesn’t mean that they must be used in a rigorous fashion. A system diagram can be useful even if created solely as graphical documentation. A system diagram can be printed, or pasted into documents or presentations. To copy a system diagram image, select the outermost system and use Copy to copy a bitmap image or Copy Image to copy a higher quality scalable vector graphic image.

The real value in system definitions lies in using them as an integral part of your overall architectural design process to describe and manage configurations of applications and configurations of systems. The System Designer provides software architects a tool to think about and design complex portfolios of application systems. Systems can be arbitrarily complex and can contain any number of levels of ‘nested’ systems. Systems can be single purposed or highly factored to enable reuse. Individual systems can be defined from the bottom up by composing them from existing members, or from the top down by first defining a higher-level system and then how it is implemented or any mix of the two. For information on how to design systems top-down see Top-Down System Design.

Composing Systems

Systems can be included as members of other systems. To be connected in a higher-level system context, a system needs to expose endpoints. A system endpoint is a proxy to an endpoint on a member of the system and delegates all communication to or from that endpoint.

Proxy provider endpoints expose services to other systems or applications. Selectively exposing endpoints allows you to encapsulate aspects of a system that you wish to hide from the outside and to expose only specific entry points. There is no modeling requirement that provider endpoints be connected in any context. All services are assumed to be optionally available.

In general, consumer endpoints on applications must be connected in a deployment. If an application can be deployed with a consumer endpoint unconnected, then this is indicated by overriding the ConnectionRequired setting on the consumer endpoint. Most simply, consumer endpoints are connected to provider endpoints on other members in the same system. However, a consumer endpoint can also be resolved by connection to an application outside of the system. There are two ways you can do this.

The first is to introduce a proxy consumer endpoint on the system that delegates to the consumer endpoint on the application. This proxy endpoint identifies the requirement for the connection and allows the connection to be resolved either by connection or further delegation in higher-level systems in which it is included, or by the intervention of an operator or a deployment script.

The second approach is to add a suitable external application which defines a fixed provider endpoint address to the system. You can use this approach when the address of the provider is known and you want to lock this address into the definition of a system. If you connect the consumer endpoint to the provider endpoint on the external application, the connection is resolved, and no proxy endpoint need be exposed. An external application can be added at any level in a design, so you can expose a consumer endpoint as a proxy endpoint on a lower-level system and then decide in a higher-level system whether to resolve the connection within the system by connecting to another system or application, to pass on the requirement by creating another proxy endpoint, or by adding an external application. External applications are provided for Web services, BizTalk services (which are simply special-purpose Web services) and databases. Other kinds of external applications can be defined using the SDM SDK.

Scoping Systems

A system should be big enough but no bigger. A system is a versioned definition of a package of systems and applications that should be deployed together. Each of these systems and applications is separately defined and versioned. Each time there is a major version change to the definition of any member of a system, it also requires a version change to the definition of the system.

To reduce unnecessary coupling between systems, you should design systems to be as small as needed from a coupling point of view. It makes sense to design systems at one level that are scoped to include members that are tightly coupled and must be versioned together, and then to design systems at another level that compose these.

This approach can be used to advantage when designing a service-oriented architecture. Services need to be loosely coupled with their consumers but can be arbitrarily complex internally and be composed of any number of loosely or tightly coupled elements. Using systems to define the scope of Services addresses a need to make the boundaries of a Service explicit and visible. By packaging tightly coupled elements together – for example, applications that share a database of are designed with shared implementation knowledge—you increase the autonomy of the Service. Explicit boundaries and autonomy are both desirable characteristics of Services. For more information, see Using Systems to Represent Services in a Service Oriented Architecture.

When designing systems composed of loosely-coupled services, the coupling is based on contract and message schema and not implementation. This is a desirable characteristic that maximizes interoperability across platforms and means that an implementation of a Service can be changed without affecting its consumers. While this loose coupling allows implementations to be changed, in the context of a higher-level system including the new implementation still requires a version change to the higher-level system.

Managing Larger System Portfolios

If managing a large portfolio of systems, it might be impractical to maintain a single versioned tree of systems rooted in a single all-encompassing ‘enterprise’ system. A more practical solution would involve maintaining multiple trees of systems rooted in a single system that represents some meaningful functional group of systems. Connections between systems can then be managed using out-of-band techniques. It might still make sense to visualize the coupling between systems, perhaps using multiple overlapping system definitions that show how different subgroups interoperate. These overlapping system diagrams can be maintained as useful documentation, even if not used rigorously to describe deployments.

Visualizing Connections to Other Kinds of Systems

While the System Designer is focused on modeling application systems, in some cases, it is useful to represent systems that lie outside the scope of the application systems you are designing but that interact with those systems and impact or guide your design decisions. The System Designer is model-driven and can include and connect applications of any type using endpoints of any type, requiring only that the appropriate base models are defined. To represent other kinds of system you can use the generic application type supported by Application Designer or define custom application types using the SDM SDK. You can use generic endpoints to represent any kind of connection or define custom endpoint types and associate these with the appropriate applications types to define application connectivity. Using these techniques you can include unsupported software applications or other kinds of systems, including manual and physical systems as well as software systems in a system definition. For more information, see Representing Connections to Manual, Physical and other Kinds of Systems.

SDM Document Management

The rigorous nature of the SDM type system and the use of an SDM compiler bring familiar software development process requirements to the architectural design process. Managing SDM documents should be considered an extension of the artifact management processes that already exist around software development.

When you think about versioning SDM documents, you should use the same discipline as you would when versioning assemblies. You should fork SDM definitions in parallel with compatible source code or other artifact definitions, and you should give consideration to keeping the SDM design documents that apply to software artifacts in the same source tree in a source control system.

While compiled SDM documents are output as part of the deployment report generation, these documents cannot be opened or referenced in the Application Designer or System Designer. If you wish to open or reference applications or systems, you must load source SDM documents. For a supported application, to include it in other systems requires that you have access to its associated project, source code and the normal SDM source document. This requirement to have access to source code limits some reuse scenarios.

Over the longer term, it is expected that there will be tighter integration between SDM metadata definitions and the artifacts they represent. In this release, SDM application definitions that are synchronized with code are placed in the root project of the application. Over the longer term, the ability to include the SDM definition of the assembly as metadata in the assembly or the definition of other resources directly in those resources would make correlation of models and the artifacts that they represent more straightforward.

Summary

System Designer allows architects to think about designing complex system portfolios in a more rigorous manner. This requires that design documentation be managed with the same discipline that is used for software source code.