Concept: Solution Partitioning
Systems can be partitioned into logical clusters of elements based on various organizing concerns. Those concerns might reflect business boundaries, physical boundaries, or more abstract subject matter boundaries.
Relationships
Main Description

Introduction

Much has been written about the decomposition of software designs into components or subsystems. Much has also been written about the need to understand the deployment topology required by an application early in its lifecycle so that correct architectural decisions can be made. However, there are very few mechanisms identified or used today to help logically partition a system during architectural analysis, so that decisions regarding the logical topology of a solution and the constraints imposed by non-functional requirements can easily be addressed at the model level before detailed design and implementation work products are generated. The following discussion outlines a set of simple model elements that support this reasoning. While they were developed with service-oriented solutions in mind, these techniques are applicable to any software architecture modeling.

Partitions and Layers

The following definitions are taken from the Rational Unified Process (RUP) glossary and contrast the notions of layers and partitions. Interestingly enough, the term tier, while common in describing the logical architecture of a solution, does not appear in the RUP glossary.

Layer
(1) A specific way of grouping packages in a model at the same level of abstraction.
(2) The organization of classifiers or packages at the same level of abstraction. A layer represents a horizontal slice through an architecture, whereas a partition represents a vertical slice.
Partition
(1) activity graphs: A portion of an activity graph that organizes the responsibilities for actions. See also: swimlane.
(2) architecture: A subset of classifiers or packages at the same level of abstraction. A partition represents a vertical slice through an architecture, whereas a layer represents a horizontal slice.

So, a partition contains a set of elements representing some part of the architecture, but how does the Software Architect slice a model? The answer is deceptively simple: Partitions and layers are organizational constructs; at an architectural level they only represent logical organization. So, what aspects of the organization of a solution do you want to represent? For example, if the model view you are developing is concerned with security, then you might want to represent Trust Zones [JHN05].

What can a partition represent?

As we said above, a partition can be used to represent any particular organization concerns the architect wishes to focus on. The following are common views that are constructed in a model. One key aspect of partitions is that they do not imply ownership/containment, so a service can appear in multiple partitions simultaneously.

Logical Solution Organization; in this case the partitions represent the logical clustering of elements in a given solution. For example, in a business application we might use partitions to represent the separation into user interaction services, business services, and infrastructure services. Such a view corresponds more to the use of layers in RUP to describe tiers of an application. However, as services are not easily layered in the same way as a component or object-based solution, we use partitions. For more information on these service classifications, see the Concept: Service Portfolio.

The following figures are partitionings used to represent logical structure of a solution.

Figure 1. User Interaction Services

User Interaction Services Partitioning

Figure 2. Business Services

Business Services Partitioning

Figure 3. Infrastructure Services

Infrastructure Services Partitioning

 High-Level Physical Distribution; in this case, partitions can be used to denote local versus remote services, at least when physical distance imposes constraints on the architecture. For example, noting that the customer, account, and order services are hosted in our primary data center and that the Electronic Data Interchange (EDI) gateway is hosted in a secondary data center is important when we also discover that the bandwidth connection between these centers is managed and we have to carefully control communication between these partitions.

Business Application/Ownership Boundaries; in this case, partitions are used to represent ownership of services by a business area or by an application area. For example, we might denote that certain services are "owned" by Human Resources, some by Sales, and some by Marketing. Now, while this is not an architectural concern, most projects have to deal with aspects that do not involve technology or architecture, but the social and political aspects of the organization. Partitions, in this respect, enable us to see how the interaction between services crosses such boundaries and might impact the development process by requiring stakeholder support for cross-organizational change. In this case, business functional areas would form the categories for this model.

Business Process Boundaries; in this case, we represent end-to-end process areas with partitions, in effect grouping services by the processes they support. Figure 4 contrasts the process view (shaded) with the business systems view represented as the vertical bars. It is important in many cases to relate these two views of services already deployed and services planned by a project.

Figure 4.  Process view of the organization vs. business organization view

 Diagram is described in the textual content.

To understand this relationship between the vertical business area and the cross-business processes, it is important to understand how each business area provides services to the processes that actually run the business. In respect to our example, this view regroups the services we identified earlier into new partitions as shown in the following two figures: Alternative services grouping, aligned by business area.

Figure 5. Order Management

Order management

Figure 6. CRM  

CRM                 

Partitions in the Service Model

In the Service Model, a SoaML Participant can be used to model partitions. A partition can contain not only instances of service Participants, but also instances of other partitions, and so can be further decomposed where appropriate. A service partition can also specify one or more ServicePoints.  In the context of a partition, these ServicePoints often are known as service gateways. These gateways are themselves services specifying the interface to a partition.

The order management process area is accessed by the same interface as is the order entry service provider in the diagram above. We term this promoting the interface from the service out to the partition. Figure 7 depicts this and shows how the order entry service provider communicates with the other services in the partition.

Figure 7.  Promoting a service interface out to the partition

  

The partition's service gateway has the ability to mediate communication bindings between clients on the outside of a partition and services on the inside. This enables services to deal only with certain protocol bindings within a partition, for example to use a higher performance or more secure protocol within the boundaries and to expose certain capabilities to clients over a different protocol. For more information see the concept Service Mediation.

As the partitions are based on UML 2.0 Composite Structures, there is no "containment" relationship between the partition and the services.  It is possible, as we have shown above, to represent the same services in multiple partitions or views. If this flexibility is tied to the capability of service gateways, the software architect and designer can cluster services in logical groupings and allow service gateways to expose only relevant interfaces to clients.

Specifying Strict Partitions

A strict partition is a partition where all services within the partition are accessed by clients/services outside the partition through service gateways. This implies that the service partition has its own set of interfaces.  As such, it can be viewed as a logical higher-level service provider. This is particularly useful for partitions that represent either business application boundaries or business process boundaries. This representation enables designers to specify the interfaces the process exposes to the rest of the business and to designate which of the services that support the process area are being made publicly available. The order-management partition above is a strict partition, but the concept of "strictness" can only be assessed by evaluating a partition.  It is not a property of the model element itself.

In the example below, the partition on the left can be considered strict because the client (outside the partition) can only communicate with the order entry provider (within the partition) via a gateway. The partition shown on the right hand side of the diagram cannot be considered as a strict partition, as the client communicates directly with the order entry provider inside the partition.

Figure 8. A strict partition

It is important to realize that modeling of strict partitions, even the use of gateways at all, is optional and should be considered simply as a tool that allows for the modeling of explicit communications between partitions (whatever they themselves represent).  For many purposes the additional overhead might not be warranted.

More Information