Introduction

CBDI has been aware for some while now of the need for much better guidance on the service oriented (SO) process. While we have regularly addressed aspects of the SO process we have, until now, resisted attempting a comprehensive treatment. The underlying reason for this is a need to be more precise about SOA concepts. Hence the publishing of an initial SOA Meta Model in October 2006¹ . In addition a comprehensive approach to process is not piecemeal but must be part of coherent methodology. Since publishing the SOA Meta Model we have been developing our practice research to encompass the methodological underpinnings for SOA in the form of the CBDI-SAE™ SOA Reference Framework (RF) shown in figure 1. The RF provides a context that allows us to formalize our practice research on the SO Process in a form that is readily usable and extendible by our clients. Looking at the figure we can see that the SO Process is one of four RF areas; note that the SOA Meta Model is part of the RF Model.

Figure 1: The CBDI-SAE™ SOA Reference Framework

In defining the SO process we have drawn both on client experiences and on ideas described in many earlier CBDI Journal articles, for example². We have been working to rationalize this knowledge by creating formal definitions, not only of SOA terms as evident in the SOA Meta Model, but of all terms embraced by the CBDI-SAE™ SOA RF including those which are pertinent to the SO Process as listed in table 1.

Table 1 – SO Process Terminology

Figure 2 drills into the SO Process box in figure 1 and shows the disciplines covered by the CBDI-SAE™ SO Process.

Figure 2: CBDI-SAE™ Process Disciplines

The SO process consists of four key discipline areas and their component disciplines:

• Manage: Defining the organization’s “current” and “desired” SOA capabilities, devising and managing the transition process, and ensuring ongoing governance of the various types of SOA policy.
• Consume: Planning SO business requirements, and improving business processes, capabilities and products, through the assembly of software solutions that are specifically focused upon the consumption of services.
• Provide: Identifying and architecting services, planning the delivery and provision of these services, provisioning and implementation of services based upon service specifications.
• Enable: Designing and installing the platform required to run services and managing the run time execution of the services.

Process Rationale

There are a host of cultural factors affecting the uptake of service orientation. Many detailed processes are possible - the fact is that organizations evolve and adapt their processes to fit their people and their market. The operative principle is to establish the “what” before the “how”: if the deliverables and concepts are right then processes will usually follow. This is one of the main reasons why we have focused so strongly on matters such as service specification, the SOA Meta Model, and more recently SLAs.

We have therefore concentrated on as minimalist an approach to process as possible. At the same time we recognize that the SO process is important especially as it is a major departure from traditional models of software development to which many organizations still cling. How is it different? What are the major guiding principles that we are following in our process definition work? The twelve principles listed below have been very influential in our approach to the SO Process.

Guiding Principles

The SO process is heavily influenced by the following overall guiding principles:

• Business-IT Integration: The process centers on and is driven by service orientation as a business concept, which requires measurable capabilities
• Specification before Process: You cannot control what you do not measure and you cannot measure what you don’t specify; definition of deliverables is therefore key
• Built in Traceability: Traceability is not “bolted on” to the process – it is achieved through the consistent identification of the service as formal artefact from business capability to live service execution
• Adaptability: Because there are many potential pathways through the process, depending on individual circumstances, the process must be modular and allow different pathways with respect to the circumstances.
• Organizational Context: Adoption management and governance run right through the SO process
• Role Independence: The process must be separated from the roles, which must be very clearly defined in the light of the increased organizational challenges of service orientation.

Separation of Concerns

The SO process must address three key gearshifts that reflect the needs of the service oriented business landscape in which we increasingly find ourselves:

• Provide-Consume Separation: Consumers work in evolutionary incremental fashion composing business solutions using services that are architected and specified by providers in technology and business context neutral fashion for maximum agility across solutions, according to business requirements
• Flexible Provision: Providers scope and specify the software required to realize the services, independently from the actual implementation design and code. The same service can be realized by different implementers, allowing implementers to be replaced and providing significant potential control of over outsourcing arrangements
• Provide-Enable Separation: Enabling technology (service platforms and operating environments) executes services such that alternative (or aggregated) implementations can be dynamically invoked at run-time in line with provider specifications, and be proactively managed with respect to business needs.

Existing Context

Last but not least the SO process does not work in a vacuum, but needs to address some quite messy factors:

• Legacy System Integration: The great majority of organizations do not enjoy the luxury of introducing SOA on to a clean white canvas, but rather have to meld it into an existing legacy system context, the treatment of which must be an integral part of the process.
• Existing Methodology Integration: Many organizations use existing methods, techniques and lifecycle stages - some of which may work well and not all of which can simply be thrown out – that must dovetail as cleanly as possible with the SOA process
• IT Operations Integration: Existing run-time technology and operations best practice (for example, the ITIL guidelines) must be integrated with respect to the process.

Disciplines

In this section we define the disciplines, and identify the main associated process units, key inputs and deliverables.

Each discipline is a competency that offers "services" to a project (or process instantiation), which should call on these “services” as it unfolds through the logic of the process. We call these “services” process units, which provide a way of chunking a discipline into reusable pieces. Though it is possible for a process unit to consist of just one task, we aim for process units that represent cohesive groupings of tasks.

We are also aiming to provide process patterns that illustrate very clearly the use of these concepts by example – article to follow.

This approach is a key differentiator of the SO process, which centers on organizing competencies in a service oriented way. Process units provide a good mechanism for grouping together cohesive sets of tasks into reusable units that can be assigned to roles, in analogous fashion to assigning automation units to implementers. While some companies might establish a team that corresponds to a discipline, other organizations might design more fluid organization structures.

At the same time we recognize the importance of providing a hierarchy bill of materials of tasks organized into process groupings. This is critical both for process unit identification, completeness of information and for migration from traditional project management, based upon a waterfall mindset. Therefore we also aim to support this structure as part of SAE™.

The Manage Disciplines

The management disciplines - SOA Adoption and Excellence, and SOA Governance - oversee the other disciples.

• SOA Adoption and Excellence assesses the organization’s “current” and “desired” SOA capabilities and expected outcomes in terms of different roadmaps streams with respect to different maturity levels. It works out a suitable adoption plan, and manages the phased implementation of the plan, progressively reviewing maturity ³.
• SOA Governance evolves a SOA Governance Framework, which is used to manage a set of service lifecycle states in relation to different policy types and responsible roles⁴ ; this framework must be consistent with the SOA Reference Framework and dovetail cleanly with existing organizational governance practices. It is anticipated that further aspects of governance, such as governance of the SOA process, will be defined as our research progresses.

The process units, key inputs and deliverables of the manage disciplines are shown in table 2.

Table 2 – Manage Disciplines (Examples)

Each process unit is composed of one or more tasks, which can be organized in hierarchical fashion as illustrated in table 3. Our aim is to identify all tasks and to document these within SAE™. These tasks may be organized into process hierarchies where appropriate, as for example in traditional project management work breakdown structures.

Table 3 – Example Tasks of Plan SOA Adoption

The Consume Disciplines

The consume disciplines work progressively and in iterative fashion from addressing overall service oriented business requirements through the design of specific business features accented on consuming services to the incremental assembly of working solutions using services:

• SO Business Requirements Planning is a strategic discipline identifying business requirements specific to service orientation that would not be explicitly addressed by a more conventional approach.
• SO Business Improvement is a nearer term focus discipline focused on “servicization” of existing processes, products and capabilities, and improvement of the business by adding new processes, products and capabilities that use services.
• Solution Assembly designs, codes and tests the solution based on use of services. A range of techniques can be used from service discovery and gap analysis, to scripting of business process flow logic, creation of user interface components and utilization of existing software. This discipline normally sits within the context of the organization’s existing systems development lifecycle (SDLC).

The process units, key inputs and deliverables of the consume disciplines are shown in table 4.

Table 4 – Consume Disciplines (Examples)

The Provide Disciplines

The provide disciplines perform a key role in aligning run time services technology with the business needs of consumers. They center on structuring and specifying services for maximum agility in their use by the consume disciplines and on realizing the service implementations for run-time execution and management by the enable disciplines:

• Service Oriented Architecture and Design (SOAD) maps out the SOA reference framework for a particular organization, and prepares and evolves the Service Portfolio Plan (SPP) and SO Security Architecture. SOAD sets the context for the other provide disciplines and, in particular, designs the services for input to Service Provisioning.
• Legacy Transition Planning creates a Legacy Transition Plan to take the organizations current systems toward the SOA vision as documented in the SPP and SO Security Architecture. At the same time the vision must be tempered by an understanding of the constraints imposed by the organization’s current IT architecture and systems.
• Service Provisioning sits at the cross roads between SOAD, Solution Assembly and Service Implementation. It performs a key brokering and quality assurance role centering on specifying and certifying services.
• Service Implementation designs, codes, integrates and tests the automation units required to realize the services, unless the automation unit is acquired from an external source, in which case design and code is omitted. In addition this discipline embraces work on legacy systems such as creating an underlying service, or more strategic activities such as re-engineering a large legacy system as a collection of services.

The process units, key inputs and deliverables of the provide disciplines are shown in table 5.

Table 5 – Provide Disciplines (Examples)

The Enable Disciplines

The enable disciplines focus on the design of the technology infrastructure required to run the services and on the operation and management of the services themselves:

• Service Platform Design and Installation plans, designs, tests and installs the underlying service platform, which will most likely take the form of an enterprise service bus (ESB), or family of ESBs.
• Service Operations and Management deploys, runs, monitors and controls run time services.

The process units, key inputs and deliverables of the enable disciplines are shown in table 6.

Table 6 – Enable Disciplines (Examples)

Process Views

Earlier we emphasized the need to tailor the process to the needs of different audiences. This is where the idea of process views comes into play and we provide some examples in this section.

Flow View

While the SO process is an evolution of the CBD Provider/Consumer lifecycle, as for example described in an earlier CBDI report⁸ , it is nevertheless a major departure from traditional models of software development to which many organizations still cling. Figure 3 shows a high level view of the overall flow of the SO process. The diagram shows the main flows only to give a sense of direction. In real life there will be much iteration between disciplines. In particular, the results of solution assembly are fed back to SO Business Requirements Planning and to SO Business Improvement in a process of managed evolution.

Figure 3: A Simplified Flow View of the SO Process

Existing Organizational View

Existing disciplines, such as IT strategy and architecture, are commonly disconnected from the SOA process. In addition existing business strategy and architecture, business improvement, application delivery and IT operations tend to have grown up in their own silos and thus be fragmented. This situation no longer cuts it in the world of service orientation. SOA must dovetail with existing disciplines, in a manner that improves and joins up these disciplines into a coherent whole!

Figure 4 attempts to show the relationship between some example organization units (that are quite typical in our experience) and the disciplines covered by the SAE™ SO Process. Note that the management disciplines have been omitted from this diagram.

Figure 4: Example Organizational Context of SO Process Disciplines

A discipline is performed by roles which have the ability to perform the process units and tasks defined for that discipline. A team organization structure that directly mirrors the disciplines allows clean separation and specialization of the skills associated with the roles. In addition, it allows different reward and recognition systems, according to the deliverables teams are contracted to produce.

One of the most important points to consider in forming these structures is flexibility of sourcing. The SO process disciplines may be performed in house or externally. Mapping the team structure directly to disciplines expedites team sourcing decisions and follows the process principles outlined earlier; for example services are provisioned for sharing across multiple solutions and solution developers work to technically neutral specification unhindered by implementation concerns.

However, as we have already observed, integration with existing organizational structures is usually an important factor, and some companies might therefore establish different team approaches. At the same time we recommend that these structures should be overlaid on to the basic SO process, in the manner shown in figure 4, for the reasons stated above. Continuing with the example shown above we might choose to establish Service Provisioning and Service Implementation as organization units in their own right, especially as there may be no candidate units within which to integrate them, or indeed they may exist as offshore organization units, which may be better integrated by the formality of service based separation. We can still create teams for the remaining SO disciplines while integrating these within existing organization units as indicated.

Lifecycle Stages View

In addition to understanding how the SAETM process sits within and enhances existing organizational contexts, it is important to consider its relationship to the stages of activity through which projects naturally pass as indicated in figure 5. This aspect is important from the point of view of integration of the SO process with existing system lifecycle methodologies such as the Rational Unified Process (RUP).

Figure 5: A Sequentially Staged View of the SO Process

Other Views

Clearly there are many possible views of the process and we would be interested to hear readers’ opinions on what other views could be useful. In particular we are experiencing considerable interest in how Enterprise Architecture (EA) relates to the SOA. As an initial thought, EA typically addresses aspects of both business and IT architecture, including technical architecture. Therefore an EA team might cross all three of the teams shown to the left of figure 4.

Concluding Remarks

Up and until recently most thinking has tended to divorce the SO process from the wider picture. Hence the need for the SOA RF. In this article we have shared our evolving thinking on the SO process, within the context of the SOA RF, at quite a high level. A future article, on process patterns, will look at a specific scenario of how the process unfolds.

Again, we find ourselves breaking new ground here in terms of the much more significant cultural transition that involves breaking down the traditional barriers between operations and development in IT, as well as the more familiar ones between IT and business. At the same time we should be mindful that our main intention is to give the reader a look and feel of what is involved in an increasingly important area – the SO process is still a very young and growing discipline.

In addition, although the approach to process should be technically neutral, that does not mean that advances in enabling technologies can be ignored. For example, it is important to note that, as the modeling, development and run time technologies evolve and converge, the iterative loop between Solution Delivery and SO Business Improvement will get tighter under the banner of business process management.

Everware-CBDI is keen to hear readers’ views and to share experiences as we seek to evolve our approach to the SO process in harmony with the SAETM Meta Model and upcoming developments in our reference framework and knowledgebase.

Afterword

This article describes the structure of the Service Oriented Process. The structures provided in this article for the various disciplines are examples. A fully detailed structure, process-units, tasks and deliverables together with details of the processes are being documented in the Everware-CBDI Knowledgebase.

We have recently published an extended version of the SO Process Framework. Please see We have recently published an extended version of the SO Process Framework. Please see http://www.cbdiforum.com/secure/interact/2007-11/editorial.php

The SO process is a major departure from traditional models of software development to which many organizations still cling.

This approach is a key differentiator of the SO process, which centers on organizing competencies in a service oriented way.

1. SOA Reference Model Report, John Dodd, CBDI Journal, Oct 2006
2. The Project Driven Service Portfolio, John Dodd, CBDI Journal, April 2006
3. The SOA Maturity Model Part 2, David Sprott, CBDI Journal, March 2006
4. SOA Governance and the Life Cycle, Lawrence Wilkes, CBDI Journal, Nov 2005
5. A Business Feature can be a business process, business capability or business product.
6. The Solution Project Justification typically includes models of the redesigned business feature; the models used are likely to be adaptations of existing models, such as business process models, used in a particular organization.
7. To elaborate slightly, the Solution Specification includes a fragment of the Business Services Architecture (which is part of the Service Portfolio Plan) produced by SOAD.
8. Establishing a Lifecycle, Wilkes, L., CBDI Journal, January, 2004.

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

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

Reports in February Journal

• Main Menu
• Editorial
• The Service Oriented Process
• SOA Excellence

Print this page