Introduction

The SAE Reference Framework is designed to provide a comprehensive framework of all the components necessary to support the migration to and subsequent upkeep of a service oriented enterprise. It addresses the three primary perspectives necessary for capturing methodology - Organization, Process, and Architecture of the Artifacts. These perspectives are built upon a firm “foundation” Model that provides the language and principles of SOA. By tailoring these aspects to the development organization’s needs, a clear target mode of operation can be established to drive the SOA adoption cycle.

The RF Model Component – Language of the Framework

In order build up a Reference Framework that addresses Organization, Process and Architecture a firm foundation of language and principles must be established to ensure that everyone is on the same page. The Model component plays this role within the SAE™ Reference Framework and comprises four main parts: SOA Metamodel, SOA Principles, Glossary, and Service Lifecycle.

The details of these are outside the scope of this article but suffice it to say that these parts define the underlying SOA concepts and their interrelationships: these form the language that is used to describe the rest of the Reference Framework. In particular, the Architecture component makes extensive use of the SOA Metamodel as the language used to describe the various views and other elements introduced below. CBDI first published this metamodel in 2006¹ and continues to refine it based on feedback from CBDI members and standards efforts that are underway² .

Likewise, the SOA Principles established in the Model component of the Reference Framework provide the guide for the layout of the Architecture component, both Views and the Best Practices captured there in.

The Reference Framework Triad – Organization, Process and Architecture

The other three main components of the Reference Framework are Organization, Process, and Architecture. These three parts form a triad that describe key aspects of any methodology framework. The Process component of the Reference Framework published in the February 2007 CBDI Journal³ describes a structure of business processes or activities that a service provisioning organization should follow in order to successfully analyze, plan, design, provision, and run services. The Organization component describes the roles and responsibilities, project profiles, and funding models recommended in order to successfully support the service lifecycle. Finally, the Architecture component, the topic of this article, provides the detailed description of the various views, models and other elements used and created during the execution of the method and how they relate to one another.

Figure 1 – CBDI-SAE™ SOA Reference Framework

Views – “Slices” of the Service Oriented Enterprise

One of the defining characteristics of any methodology is the structure used to capture the relevant aspects or perspectives of a system, whatever system that may be – business, information system, hardware, or what have you. The CBDI-SAE™ Reference Framework includes five views – Business, Specification, Implementation, Deployment, and Technology. These views comprise a consistent level of abstraction for deliverable artifacts that relate to distinct set of stakeholders. This provides an effective mechanism for grouping related SOA best practices based on a particular part of the enterprise under study. Each View defines and clusters together the standards, patterns, techniques, deliverables, models and policies that apply to appropriate View as illustrated in Figure 2.

Figure 2 – Architecture Component of the SAE Reference Framework

Table 1 and Figure 3 provide a first level of detail on each of the five Views highlighting:

• The primary stakeholder roles involved in each level of abstraction
• The mapping to layers commonly used in enterprise architecture.
• The purpose of each View.
• Sample artifacts
• Key perspectives of each layer – the essence of the methodology – showing how the service architecture manages the relationship between conceptual, logical and physical perspectives.

Note: some architecture frameworks break data out as a separate layer however, the Reference Framework captures this within a number of artifacts that reside in the Business, Specification and Implementation views.)

Table 1 – SOA View Descriptions

Figure 3 – Sample Artifacts and Service Perspectives by View of the SAE Reference Framework Architecture Component

Note Figure 3 depicts only key artifacts of the RF Architecture component by Views. It is not intended to be a complete picture of all the artifacts that would be involved in developing a SOA or a software solution based on services; for example there are many existing models (such as logical data models and business process models) that will also come into play. The February journal article gives a more complete picture of the deliverables involved. In addition we have concentrated here on specifically service oriented artifacts.

The Business View

To fully understand the requirements of software systems and the services that they comprise, we need to understand the business context within which they operate. The Business View provides this context. Further, analysis of business objectives and processes from a “services perspective” often provides a significant return on investment to the business in and of itself for many of the same reasons a service perspective improves software. It decouples the “what” from the “how” allowing flexibility in the implementation in terms of business processes, whether internal or outsourced. Goals and objectives of the business can be more easily connected with the services the organization provides.

The Business View includes a number of key artifacts and models used to capture and analyze important aspects of the business. These artifacts and models are captured in Table 2.

Table 2 – Key Business View Artifacts

The Business View also includes other best practices such as policies, patterns, and techniques that provide guidance as to how to capture knowledge about the business. Table 8 includes sample best practices in these areas.

This list of artifacts and models may seem daunting to the neophyte modeler/architect but remember that not all are strictly necessarily. Each project team that uses the Reference Framework will tailor it to their needs using or ignoring artifacts and models as they see fit in order to analyze and address the concerns that they find important. The key is to know how and why to use each one – its pros and cons.

For models the question of notation or “language” comes into play. While business modelers have not found the same level of convergence in terms of modeling language as software modelers have with UML™, there are still aspects that are generally agreed upon such as Organization, Business Process, Policy, Business Objective, Business Rule, and Business Entity. Everware-CBDI has included these salient concepts in our SOA Metamodel⁴ and standards from OMG such as Business Process Modeling Notation (BPMN), Semantics of Business Vocabulary and Rules (SBVR) and (hopefully) soon to be approved Business Process Definition Metamodel (BPDM) are a big step in the right direction. Often, multiple languages are used to capture business architectures – swimlane diagrams for business processes, entity relationship diagrams (ERD) for business information models, org charts for organizational structure, and various proprietary notations from tool vendors. UML is increasingly being used to capture business models though some believe it to be too complex for business users to understand. Again, selection of the appropriate language and tools is part of the tailoring process.

Specification View

The Specification View comprises the artifacts and models required by architects to specify the functional and non-functional requirements of software solutions and services as well as the architectural dependencies between them. This view is meant to be independent of any particular platform such as an application server, operating system or even Enterprise Service Bus (ESB). The idea is to capture how services behave, allow for refactoring of that behaviour into appropriate “chunks” in order to optimize for reuse and other characteristics that are independent of any particular technology. That said, it may very well be that the choice of deployment platform has already been made and that the services will be required to be implemented on that platform. However, technology churn takes place on different cycles than business requirements and so providing a mechanism for separating these concerns is critical to maintainability of the service architecture.

The primary diagrams of the Specification View is the Service Dependency diagram (part of the Service Specification Architecture) that shows the layers of the Service Architecture, the services in each layer and the dependencies between them (See Figure 4). As shown in the figure, service domains can also be shown in this view.

Figure 4 – Service Specification Architecture – Layering and Dependency

The actual diagrams captured will depend on the needs of the architects creating or specifying the services and other stakeholders that will use them. Some organizations capture very detailed structural and behavioral views at the specification level that are used to drive the implementation and deployment design processes down the road. Other organizations only use the dependency diagram for high level organization and portfolio planning.

Typical artifacts and models that are captured as part of the Specification View are described in Table 3 below.

Table 3 – Key Specification View Artifacts

Now the question is how we relate the elements captured in the Specification View back to the Business Model. As stated above, the Business View provides the context and requirements for solutions built using services captured in the Specification View. In order to convince ourselves that each requirement from the Business View has been adequately addressed we need to capture the traceability from elements in the Specification View back to the elements in the Business View.

A detailed discussion of how traceability is achieved is beyond the scope of this article but at a high level this traceability might be done as follows:

• Business Processes are captured in terms of activity diagrams that include swimlanes representing logical business roles.
• The business roles that are currently or will be automated in software are identified.
• These automated business roles become solutions or services in the Specification Model.
• Lines that cross the swimlane boundaries of automated roles become operations or messages that trigger the activities within the swimlane.
• These activities are the requirements of the solutions or services captured in the Specification View.

Capturing the traceability can take a variety of forms. One mechanism is to use a tool like Rational’s RequisitePro to maintain a table of business requirements and the elements from the Specification View that address them. Another mechanism is to create a diagram within the modeling tool that shows the dependency of the Specification View elements to the Business View elements.

Implementation View

Once the Specification View is complete or at least beginning to stabilize depending on the process patterns chosen by the development organization, a model that maps the logical specification onto automation units (things that package or will actually be realized in code) should be created. The mapping may be as simple as one automation unit per logical service or as complex as mapping several logical services into some other number of automation units. Further, the services might be (and often are) provided by legacy applications whose software architecture is very complex and not well understood. In situations such as this, one large automation unit might implement many services.

The primary artifact of the Implementation View is the Service Implementation Architecture that captures the structure of the Automation Units that implement the services identified in the Service Specification Architecture. Figure 5 shows an example Automation Unit Dependency Diagram of the Service Implementation Architecture.

Figure 5 – Sample Automation Unit Dependency Diagram (part of Service Implementation Architecture)

Again, the Implementation View may contain a number of artifacts and models depending on the needs of the project. Table 4 describes key artifacts and models contained in the Implementation View.

Table 4 – Key Implementation View Artifacts

The models of the Implementation View are typically captured using UML diagrams. The Service Implementation Architecture is typically captured as one or more component diagrams showing the Automation Units and the relationships between them.

As with traceability between the Specification View and the Business View, capturing traceability between the Implementation View and the Specification View can take a number of forms. Traceability Matrices in tools such as RequisitePro are often used as well as UML Class diagrams that include elements from the Implementation View and elements from the Specification View with Dependency relationships between them. This traceability is crucial in order to be able to map all the way from business requirements to the actual code that supports them.

As for the actual mechanism for providing traceability, Everware-CBDI recommends mapping the Specification of the logical Service in the Specification View to the Provided Capabilities of the Automation Units in the Implementation View. Since there isn’t necessarily a one-to-one relationship between Services and Automation Units, not all of the operations of a Service will be found on Provided Capabilities of an Automation Unit. In these cases the Service can be traced to the Automation Unit in general.

Deployment View

We’ve now seen how the Specification and Implementation Views of the solution “layer” of an enterprise work together to separate the logical design of the solutions and services from the implementation design. This is very compatible with Model Driven Architecture™⁵ and allows us to separate the logical functionality required of services from the physical packaging and technology thereof. The last piece in this puzzle is the allocation of the service packages or Automation Units to platforms or Nodes on the network (see the Technology View below). This mapping is the focus of the Deployment View and represents a key piece in the methodology puzzle for several reasons. First, it provides the mapping of Automation Units onto Nodes or Service Platforms allowing service or solution architects to communicate with infrastructure architects about how services will run in the production environment. This ensures that services required for runtime will be available on the platforms that will run the Automation Units.

Second, it provides a mechanism for these same service and infrastructure architects to analyze the processing and bandwidth capacity required for each segment of the infrastructure. Often, this type of analysis is left until the last minute or disregarded altogether. The result is generally slow response time and subsequent stakeholder dissatisfaction. Table 5 describes key artifacts and models of the Deployment View.

Table 5 – Key Deployment View Artifacts

Ensuring traceability at the Deployment level is relatively easy thing to do since the Deployment View typically includes the Automation Units that come from the Implementation View. This provides direct traceability without any additional work. Alternatively, one might forego creating detailed deployment diagrams and opt for a matrix that shows which Automation Units are deployed to which Nodes or Execution Environments.

Technology View

The Technology View is last piece in the overall enterprise layering. The purpose of this view is to nail down exactly what the network will look like, policies that will govern service operations and to ensure that the technology base required by the services running in the production environment have all the pieces they require.

Table 6 provides a list of the key artifacts and models contained in the Technology View.

Table 6 – Key Technology View Artifacts

Traceability between elements in the Technology View and elements in the Deployment View is often navigated in a direction backward from that of the other layers. For instance, deployments of Automation Units in the service Deployment View need to be traced back to Automation Units in the Service Implementation View. Provisioned Capabilities of Automation Units need to be traced back to Service Interfaces or Operations in the Specification View. Services in the Specification View need to be traced back to roles in Business Process Models. All of these examples go “up” through the Views. Infrastructure-Deployment traceability could go in either direction. The only time the service architect is allowed to directly drive the runtime infrastructure is when the project is dealing with a “green field” situation. This might happen when an organization is first being spun up or when there is a planned migration to SOA from a legacy environment that in no way supports SOA. In this situation traceability might run from the Infrastructure View elements to the Deployment View elements.

In the vast majority of situations, however, the infrastructure already exists and must be used with relatively little modification. In these situations, the traceability is navigated from the Deployment View elements to the Infrastructure View elements to ensure that the deployed Automation Units can run on the existing infrastructure.

Multi-View Artifacts

The reader may have noticed in reading the above sections that several of the key artifacts/deliverables described in last month’s article on the SO Process and shown in Figure 3 above are conspicuously missing from the Key Artifact tables. This is due to the fact that these artifacts cover a broad range of issues and act to pull together aspects of a number of layers into one place. Table 7 below provides a list of key multi-view artifacts.

Note: For a comprehensive list of the Deliverables created as part of the SAE Reference Framework please see the February journal article on The SO Process.

Table 7 – Key Multi-View Artifacts

Best Practices – The Methodology “Toolbox”

Best practices are the tools recommended for use in capturing the various aspects of the Business, Specification, Implementation, Deployment and Technology Views. The Reference Framework groups best practices by type – Standard, Pattern, Technique, Deliverable, Model, or Policy. Attention should be paid to each one of these types when tailoring the Reference Framework to your organization so that all aspects of the Framework are evaluated. Not all practices need to be incorporated into a particular tailoring of the Framework. However, the choice to exclude a particular practice should be a conscious one. Table 8 provides a description of each Best Practice type along with examples.

Table 8 – Best Practice Areas

Concluding Remarks

The Architecture component of the SAE™ Reference Framework is been structured into Views and Best Practices in order to support a number of key architectural principles. Perhaps the most critical of these principles is separation of concerns. By dividing the structure into Views, architects can separate business concerns from software concerns, logical concerns from technology concerns and so on. This separation, in addition to allowing the architect to focus on a particular concern without having to remember all the others, also improves the maintainability by “chunking” the architecture into manageable pieces.

The structure is also complementary with industry trends such as the Object Management Group’s (OMG) Model Driven Architecture™ (MDA) and the more general model driven development (MDD). By incorporating detailed models at each level supported by rigorous traceability, organizations are able to capture and maintain detailed models of their service architecture and analyze the impact of changes to that architecture in either direction up or down the enterprise “layers” (e.g., business, specification, technology, etc.). As model generation technology evolves, users of the Reference Framework will be able to more easily incorporate these tools and techniques into their methodology as appropriate since the models are already there.

Organizations will have differing needs for an SOA reference framework. The framework will need to integrate with existing architecture practices, techniques and tooling where they exist. We expect variation in modeling languages/notations used (UML, BPMN) and customization of modeling techniques, policy sets, patterns and standards.
Adoption of a reference framework is also an evolutionary process. Techniques, and particularly patterns and policies will evolve with SOA maturity. In the early stages many policies will probably be advisory; but with more experience they may well become strongly recommended or mandatory.

The term framework is used advisedly – it is provided as a basis for customization and specialization. Also in developing the SAE SOA Framework we are very aware that many architects will already have established some form of framework, often using ideas from one or more sources such as Zachman, TOGAF, EA etc. We will follow-up this report with a mapping to a number of the widely used frameworks.

Everware-CBDi is actively evolving the Reference Framework Architecture together with the Model, Process and Organization components. This will be documented in the SAETM Knowledgebase. Readers’ views, experience and feedback would be greatly appreciated.

1. A Meta Model for Service Architecture and Engineering Dodd, J., CBDI Journal, October, 2006.
2. Everware-CBDI is actively engaged in the Object Management Group’s (OMG) UML Profile and Metamodel for Services (UPMS) initiative and is closely tracking work within OASIS to refine their SOA reference model.
3. The Service Oriented Process, Allen, P., CBDI Journal, February, 2007
4. A Meta Model for Service Architecture and Engineering
5. OMG Model Driven Architecture

  Images used in CBDI Journal March in Powerpoint format (Gold subscribers only)

  CBDI Journal March in Adobe PDF format (Gold subscribers only)

Reports in March Journal

• Main Menu
• Editorial
• SOA Maturity Assessment Survey
• The Architecture Component of the SAE™ Reference Framework for SOA

Print this page