may 2006everware-cbdi.com/public/downloads/pURv0/journal2006-05.pdf · capabilities of the ESB and...

CBDIJournal2 Editorial

On Evolution and Natural Selection

4 Best Practice ReportThe Service Oriented Infrastructure (SOI)

Maturity ModelWhile SOA infrastructure may be project specific in the early stages, it rapidly becomes apparent that there are real benefits to be gained from standardizing to some extent at the enterprise level. In developing the enterprise SOA infrastructure it is useful to use maturity modeling techniques and in this report we explore an approach that extends and specializes the guidance we have given

in a our general maturity model reports.By Lawrence Wilkes

13 Best Practice ReportBSP for SOA

Within the CBDI service engineering approach, business modeling is used at two distinct levels – at the planning level (as input to business design and service planning) and at the requirements level (as input to service design, acquisition and management). In this article, we shall discuss the development of high-level business

models for planning purposes.By Richard Veryard

23 Best Practice ReportApplying Product Line Techniques to SOA –

Part IIOften separate consumers of a service will follow slightly different processes or require slightly different information for their particular business sector or domain. In addition to loose-coupling, SOA provides the architectural mechanisms to enable many types of variability at both design-time and runtime. But this is also a key driver behind software product lines and application family engineering, two well established software techniques. Part 1 of this series explored methods for identifying reusable components and enabling service variability. Once variability has been introduced, managing configurations becomes critical. This article explores the similarities and differences in configuration management between typical SOA

development and the software product line methodologies.By John Butler

Independent Insight for Service Oriented Practice

may 2006

ISSN 1745–1884

Editorial

www.cbdiforum.com

Business processes are

constantly evolving. You

ignore the organizational

issues at your peril.

On Evolution and Natural Selection

My current reading is This Thing of Darkness by Harry

Thompson, a fictional account of the voyages of the Beagle.

The Beagle survey took five years, two-thirds of which

Charles Darwin spent exploring on land. He studied a rich

variety of geological features, fossils and living organisms, and met a wide

range of people, both native and colonial. He methodically collected an

enormous number of specimens, many of them new to science.

At one point Thompson tells how Darwin crossed the Andes from Chile

to Mendoza, Argentina by mule train, with the pack animals piled high

with bulging sacks of geological specimens and incredibly Darwin’s bed.

They crossed the continental divide at a height of thirteen thousand feet

at a height that was under snow all year round, incredibly cold where no

one had ever lived.

On the way down Darwin set animal traps and succeeded in catching a

mouse. He observed that the animal was quite different from the animals

on the other side. His guides confirmed that all the animals on the Chilean

side are different from those on the Mendoza side – while the condors fly

from one side to the other, the animals will not cross the passes because

it is too cold. So the Chilean animals and the Mendocino animals are all

quite different.

This was perhaps the beginning of Darwin’s thinking about evolution,

and was later corroborated many times over with tangible evidence of

independent development. A good example is that every island in the

Galápagos Archipelago had its own kind of tortoise, these had originated

from a single tortoise species and had adapted to life on the different

islands in different ways.

The parallels with today’s modern enterprise are way too close for

comfort. We see most enterprises are organized in such a way that

business processes are constantly evolving in a manner that is

specialized to particular lines of business. While there is increasingly

centralized planning of technology infrastructure, there is typically almost

no central or coordinated planning of data and applications/services. In

this environment evolutionary business pressures inevitably and quickly

create variants that have interesting consequences for business.

Darwinians might suggest divergence is good news for a corporation,

strengthening the species by natural selection. However the obvious

cbdi journal © CBDI Forum Limited, May 2006 �

downside is excess cost – incurred through massive

duplication of functionality across lines of business

generate huge, unnecessary life cycle costs. Even

more worrying we can see evidence everywhere that

divergent data and processes cause inconsistent

customer experience that is a major problem in many

businesses today.

Over the past year we have written and talked a

lot about standardization as a key mechanism

underpinning SOA. We suggest it is vital that business

management decide on what areas of the business

should be standardized and which should be allowed

(encouraged even) to evolve and innovate. In effect the

question of standardization vs variation becomes an

essential part of business strategy, a topic that has

been inadequately debated in corporate boardrooms.

If one listened too closely to vendor marketing one

might have been persuaded that adaptability (or

agility, flexibility, responsiveness etc) were the primary

justification for service architecture. Yet standardization

of foundation stones such as customer experience

based on consistent customer data, is about stabilizing

corporation data and process rather than increasing

the rate of change.

I don’t suggest that SOA doesn’t deliver more adaptable

environments. It does because formalization of well

designed, contractually based interfaces is going to

reduce the horizon and cost of change. However the

notion that everything is in a state of constant change

is complete nonsense. Rather each enterprise needs

to decide where it’s innovation dollars should be spent,

and stabilize areas that will obviously have a high level

of continuity.

In his time Darwin’s ideas were considered heretical

and he did much of his work in secret. Darwin’s book,

On the Origin of Species by Means of Natural Selection,

set off a public controversy which he monitored closely,

keeping press cuttings of thousands of reviews,

articles, satires, parodies and caricatures. The SOA

parallel is that managing business standardization

and variation requires profound changes in the way

a corporation is run. Much of this change is inevitably

going to be unpopular with LOB managers who are

used to controlling their own business processes and

IT investment, and are not accustomed to operational

collaboration with their peers.

There is growing understanding that the key to SOA is

solving the organizational issues. It is all too easy to

push ahead with projects and technology infrastructure.

These are controllable matters that we technologists

understand. But you ignore the organizational issues

at your peril. You will find that natural selection and

evolution will continue to happen apace that completely

undermines all the investment put into SOA.

David Sprott, CBDI, May 2006

Best Practice Report

� cbdi journal © CBDI Forum Limited, May 2006

By Lawrence Wilkes

The Service Oriented Infrastructure (SOI) Maturity Model

While SOA infrastructure may be project specific in the early stages, it rapidly becomes apparent that there are real benefits to be gained from standardizing to some extent at the enterprise level. In developing the enterprise SOA infrastructure it is useful to use maturity modeling techniques and in this report we explore an approach that extends and specializes the guidance we have given in a our general maturity model reports.

IntroductionIn our Maturity Model reports1 we have conventionally included operational infrastructure as one activity stream in order to guide and manage the SOA infrastructure development in line with application driven requirements.

In practice many enterprises are acquiring SOA infrastructure on a project by project basis because this is the natural driver and justification for the investment. Consequently there is a tight linkage between infrastructure and application needs. However most enterprises will come to recognize the significant opportunities that are created by some level of infrastructure standardization and it may often be that investment in common infrastructure is one of the first and most obvious steps to enterprise SOA adoption.

There are always linkages between SOA infrastructure and applications, however as the infrastructure increasingly supports a broadly based set of business service needs the relationship changes from specific feature function support to macro issues such as consistent security, trust and SLA architectures; consolidation of resources to deliver economies of scale and scalability and so on.

In this report we suggest that the enterprise Service Oriented Infrastructure (SOI) has a maturity model that needs to be addressed, communicated and managed in a manner that is largely independent of individual application programs. Further we suggest that by delivering levels of cost, adaptability and standardization, SOI maturity is potentially an important enabler of new business strategies.

1The SOA Maturity Model. http://www.cbdiforum.com/secure/interact/2005–12/The_SOA_Maturity_Model.php. The SOA Maturity Model – Part II http://www.cbdiforum.com/secure/interact/2006–0�/The_SOA_Maturity_Model_Part2.php

Service Oriented InfrastructureService Oriented Infrastructure (SOI) is a generic term used for the infrastructure to support SOA. It is useful to see this from two perspectives. From one, infrastructure is seen as an enabler of the Business SOA. For example, the current focus in the early learning and integration stages of SOA Maturity on the use of an Enterprise Service Bus (ESB) as an agile mechanism to facilitate the delivery of Business Services. We term this SOA Infrastructure which we define in Box 1.

However, from a second perspective we can see that the infrastructure to support SOA will go through its own separate maturity model as it becomes Service-based. That is, infrastructure itself increasingly adopts the SOA approach, delivering its capability through published Services and conforming to the principles of SOA such as loose coupling.2 This view is consistent with the use of the term SOI we have seen presented by Intel, Microsoft and the grid community. To differentiate however, we therefore define this as Service-Based Infrastructure (SBI) as shown in Box 2.

SOA Infrastructure is the IT infrastructure that supports delivery of SOA.

Key capabilities are:

Ability to support the delivery of Business Services

Support for Service as a 1st order concept

Mediation of Service Requests

Management of Services to Service Level Agreements

Key components are:

Enterprise Service Bus (ESB) – to provide integration and mediation capability

Network – to provide local and wide area connectivity

Security – to ensure integrity and confidentiality, and manage access

Service Management – to manage and deliver Quality of Service (QoS) according to Service Level Agreements (SLA)

Registry – to manage publication and discovery of Services.

Box 1. SOA Infrastructure Defined

•

•

•

•

•

•

•

•

•

Service Based Infrastructure (SBI) is IT infrastructure that adheres to the principles of SOA. Key characteristics of SBI are:

Service-Based – infrastructure capabilities are exposed as published Services

Virtualization of Resource – Physical resources are not dedicated to specific applications or users, but allocated from a shared pool as required

Location Independence – Physical resources are location independent (internal or external)

Policy-Based – Usage and allocation of resource is determined by policies

Separation of Concerns – infrastructure capabilities are separated from the IT processes that manage them

Box 2. Service Based Infrastructure Defined

•

•

•

•

•

2Principles of Service Orientation. http://www.cbdiforum.com/secure/interact/200�–0�/Principles_of_Service_Orientation.php

cbdi journal © CBDI Forum Limited, May 2006 5

6 cbdi journal © CBDI Forum Limited, May 2006

The Service Oriented Infrastructure (SOI) Maturity Model continued . . .

Figure 1 differentiates between,

SOA Infrastructure. The infrastructure needed to support the Business SOA. Primarily the capabilities of the ESB and network. It should also be recognized that the separation of concerns in SOI requires the same mediation and networking capability as the Business SOA. That is, the consumers of SOI such as IT processes are loosely coupled to infrastructure resources, and may require an ESB to mediate the connection between them.

General Purpose SOI. The underlying network, compute and data resources that support business or IT applications – regardless of whether that application is itself Service-Based.

SOA Infrastructure as SBI. The components such as ESB that provide the SOA Infrastructure will themselves become Service-based.

•

•

•

Orthogonal to these layers are the capabilities that are again relevant to the Business SOA and SOI. For example:

Security infrastructure is required to ensure secure use of both the Business SOA and the SOI. E.g. authentication of IT operators is as relevant as Business Users.

Management. The Service-based provisioning of resources and monitoring of their status is equally applicable to business application resources and infrastructure resources.

Governance over the IT processes applies equally whether the process is one of delivering the business SOA or the SOI. The Service Lifecycle3 is applicable to both Business Services and Infrastructure Services.

•

•

•

3The Service Lifecycle. http://www.cbdiforum.com/secure/interact/2005–11/the_service_lifecycle.php

Figure 1: SOI Layers

The scope of SOI is shown in Figure 1:

SOA Infrastructure


Again, each of these capabilities will also become Service-based, with Security and Systems Management already well down that track.

CBDI SOI Maturity ModelAs discussed, the infrastructure to support the Business SOA is not necessarily Service-Based. That is, it may support the delivery of Service-based business solutions that use the Business SOA, but the infrastructure capability itself does not apply the principles of SOA. This is reflected at Level 1 (SOA Support) of our SOI Maturity Model shown in Figure 2.

The key change to SOI occurs at Level 2 (Integrated), when the infrastructure itself becomes Service-based. At Level 2 infrastructure capability is exposed as Services enabling integration of capabilities from different providers such as external infrastructure Service providers, or Services exposed from internally operated infrastructure (typically

purchased from a platform or middleware vendor – or open source). An example of the type of capabilities that might be assembled this way to support IT processes is shown in our recent report on IBM Tivoli enabling Service Oriented Management4.

We first introduced the Infrastructure Services Architecture (ISA) concept in an earlier report on ESB5.In the same way organizations require a Business Service Architecture (BSA), to enable assemblies of infrastructure capability requires an ISA defining the set of Services for each infrastructure domain (e.g Systems Management, Security, Mediation, etc).

If infrastructure capabilities from different sources are to be orchestrated in the same IT process, clearly it is advantageous if Services from various providers conform to a standardized Service specification. As with the BSA, not every Service in the ISA needs be standardized, but the ability to plug & play different providers together, or dynamically mediate between different Services depending

Figure 2: CBDI SOA Maturity Model

4IBM Tivoli–Enabling Service Oriented Management. http://www.cbdiforum.com/secure/interact/2006–01/IBM_Tivoli_Enabling_Serv_Oriented_Man.php5Time to Board the Enterprise Service Bus. http://www.cbdiforum.com/secure/interact/200�-0�/Enterprise_Service_Bus.php

SOA InfrastructureCurrent infrastructure hardware & software

� cbdi journal © CBDI Forum Limited, May 2006


on current conditions and policies is greatly enhanced when those providers share a common specification. This is reflected at Level 3 (Standardized).

A consequence of standardization is commoditization. With Infrastructure Services from different providers complying with the same specification and hence delivering the same capability, differentiation is achieved in variation of Quality of Service (QoS) and price. With fully Service-based infrastructure, the location of the capability is transparent, and the capability can be shared between many consumers and virtualized across many providers. Hence the SOI becomes L4 (Utility).

Further characteristics of these maturity levels are explored in Table 1.

Impact on ITTable 2 illustrates how SOI maturity impacts the IT organization. Gradually, IT moves from being a Service Provider to the business, to becoming a Service Provisioner. That is, it moves from operating the infrastructure, to managing the provision of infrastructure that is itself operated by other entities. Focus shifts from implementation and integration, to selection, procurement, policy administration and some aspects of management.

A key raison d’etre for SOA is to enable the automation of processes rather than manual self-service. This is equally applicable to both Business and IT processes. Consequently, as the SOI becomes more mature, IT

processes are increasingly automated. IT’s role is to set policies and contracts, not the low-level configuration of individual SOI components which is undertaken by the SOI provider.

SOI BenefitsA key benefit to customers of SOI is cost reduction. Reductions in the cost of infrastructure provision and administration are suggested by the organizational impacts identified in Table 2. Further cost reductions are explored in Table 3

Cost reduction is not the only motivation of course. Other reasons for SOI adoption include

Scalability, Reliability – QoS is easily delivered across a shared virtualized pool of resources

IT Agility – ability to use alternative better/cheaper/faster resources on demand

Business SOA Maturity and Business Agility – The ability to deliver the top levels of SOA Maturity for the business will require corresponding levels of SOI maturity

Figure 3 suggests there is a process of continuous improvement at each level of SOI maturity with further incremental steps detailed in Table 4.

Figure 3 is similar to a graph presented by Intel at a recent OMG meeting. The CBDI model expands the number of

•

•

•

L1SOA Support

L2Integrated

L3Standardized

L4Utility

Deployment InternalCentralized

Internal Virtualization External VirtualizationFederatedPolicy driven On Demand deployment

Integration of different SOI Products

IsolatedLimited interoperability

Integration of products via published Services

Full interoperability based on standardsPlug & play

Provider/Vendor

Software/Hardware vendorMiddleware vendorNetwork vendor

Some point Service ProvidersSpecialist Infrastructure Service vendorse.g. Security ProvidersSpecialized Hosting (e.g. Web Servers

In addition, the Telco or similar provides SOI as part of the network

“Grid” like SOI resource providersSingle Service Provider takes overall responsibility

Commercial Basis Software License SLA Level (e.g. Gold Customer)

MeteredDynamic negotiation

Table 1: Further Characteristics of SOI Maturity


L1SOA Support

L2Integrated

L3Standardized

L4Utility

IT/Business Relationship IT is a Service Provider IT is a Service Provisioner

Focus of IT Operations Implementation Integration CertificationPolicy administration

Selection

Systems Management Reactive PredictiveConfiguration Management Service

Manage to SLA Autonomic

IT Process Manual, fragmentedTool specific

SOI enables Process AutomationSeparation of IT Process from SOI capabilityIT is seen as a “business process” Use of ITIL, COBIT

Process is Contract and Policy-based

Governance and Policy Management

Config files and scriptsGovernance is fragemented and non-automated

Proprietary policy definitionsTool dependent and lifecycle state specificSome automated governance though policy compliance checking

Growth in Policy Assertion LanguagesPolicy Assertion Languages and frameworks standardizedFull lifecycle Governance

Table 2: SOI Impact on IT Organization

L1SOA Support

L2Integrated

L3Standardized

L4Utility

Deployment Consolidation Internal virtualization for pooling and sharing

Limited outsourcing Lower cost provision of certain point SOI capabilities

Wide-scale outsourcing Seamless Virtualization

Commercial Rationalization and consolidation to reduce software/hardware licenses

Reduce cost by only paying for what is needed/used

Pay only when Service Level delivered

PAYG (Pay As You Go)

Infrastructure Operations and Configuration Management

Reduce problems through Predictive analysis

Plug & Play Autonomics replaces need for most manual intervention

Infrastructure Management Process

Reduce time though Process AutomationRepeatable process to reduce errors

Delegate much of infrastructure management process to Managed SOI provider

Only need to administer SLA, Policies

Table 3: SOI Enabling IT Cost Reduction

10 CBDI Journal © CBDI Forum Limited, May 2006


stages and makes a distinction between internally and externally virtualized infrastructure. We feel this is important because today the focus of virtualization is on the general purpose infrastructure (network, compute, data). Virtualization is typically enabled through proprietary “clustering” type approaches (many jobs sharing many processors, or one job using many processors) and the virtualization of a single processor (many jobs sharing a single processor). Today, virtualization is not service-based. Hence management of the resources is tightly coupled to the resources. Whereas, with SOI:

Virtualization should be based on SOA to enable loose coupling of resources and management of the resources.

Virtualization should also include the other components of SOI that enable SOA such as the ESB.

Virtualization should also be applied externally in a more “grid” like fashion, with SOI shared across many consuming organizations. The grid community is already

enabling external virtualization using SOI today via Open Grid Service

Architecture6 (OGSA) – though the focus is primarily on technical/scientific applications.

•

•

•

enabling external virtualization

•

•

The infrastructure to support

SOA will go through its own

separate maturity model as it

becomes Service-based

6http://www.globus.org/ogsa/

Figure 3: SOI Enables Continuous Improvement


Business SOA and SOI ConvergenceWe started by suggesting that Business SOA and SOI have their own independent Maturity models. This report has considered how there are benefits to IT in adopting SOI at each level of maturity regardless of the maturity of their adoption of SOA in support of business requirements.

For many organizations however, it is likely that their SOI needs are driven by the requirements of their Business SOA, and the two will be entwined.

Finally therefore we consider how SOI supports the business SOA, and how ultimately they are on a path of convergence.

L1/2 – Internal Business SOA Integration and Agility

At level’s 1 and 2 the prime thrust is enabling integration and agility using SOA. For example, the delivery of enterprise-level Shared Business Services requires

Enterprise-wide SLA and trust architecture

Enterprise-sharing of SOI

•

•

To support these, at these levels the SOI provides

Common Mediation layer

Common Service Management and monitoring services – integration of disparate management capabilities

Common Security Services

L2/3 – External Business SOA Agility

At level’s 2 and 3 we would expect to see more requirements for SOI to support federated SOA with multiple participants, and to support collaborative and virtualized businesses.

This gives rise to ecosystem-level dependency on Shared and External Business Services that require

Consistent SLA and response

Federated Manageability

Predictable and reliable response to change

Normally, each participant may be expected to still continue to operate their own infrastructure, but in some scenarios there may be ecosystem-level sharing of SOI components.

•

•

•

•

•

•

Level SOI Benefits

L1 SOA Support SOI InfrastructureInfrastructure Software/Hardware deployed in houseInfrastructure used to support Business SOARationalized Standardization of products, consolidated deployment

Cost saving, simplified management, control

Internal Virtualization Proprietary internal virtualizationShared resources using proprietary clustering and provisioningCentralized (clustered)

L2 Service-Based Internal and external SOI capability is exposed as a service.Use of proprietary, point SOI Service solutions

Ease of integrationReduction in manual effort, errorsAbility to integrate best of breed specialist Services

L3 Service Standardization

Standardization of capability Consumer choice and flexibilityInteroperability

Policy Based Allocate resources based on policyMediate based on Policy

Improved governance – Consistency of policy enforcement

Managed Service Full portfolio of SOI is provided as a managed Service Full end-to-end SLA

External SOI and SOA Virtualization

Enabled by L2/L3SOA and SOI Standards-based virtualization (grid)Manage to SLA

Reduction in cost and improvement in scalability across large-scale shared resources

L4 Utility Commodity SOI GridStandardization of SOI Services and SOI Management facilitates commoditization

Lower cost SOI provisionCompetitive provision

Table 4: Benefits of Continuous SOI Improvement



To support these SOI level 3 provides standards-based federated interoperability and manageability.

L2/3 – Managed SOI

At these levels some scenarios may also benefit from a managed SOI. The concept of a Business Service Network7 that is provided as a service to all participants.

A managed SOI helps to provides:

Management of end-to-end service delivery process, including federated scenarios

Dynamic response to major change in demand within the SOA at optimum cost (upgrade, dynamic scaling)

L4 – Managed SOI and Business SOA

At level 4, the Business SOA is key competitive opportunity enabling predictable and continuous business process improvement. Business Services are virtualized and there are commodity Business Service providers.

•

•

At this level we would expect to see convergence of the Business SOA and SOI in that a virtualized Business Platform (Figure 4) can provide both Business and Infrastructure resources supporting whole federated ecosystem.

The Virtualized Business Platform can support reconfiguration of the business network with minimum cost and time to change with autonomic response from the SOI to support the business change.

ConclusionsSo where are we now? Figure 3 shows the current state of the market. The SOA infrastructure to support the business SOA such as the ESB is well established. Organizations can also take advantage of the virtualization offered by platform vendors today to consolidate resources and reduce costs.

Level 2 SBI is beginning to appear, most notably in the Systems Management arena, and for some point infrastructure capabilities such as the Service Registry.

More advanced Level 3 SOI is apparent in Security, with the WS-Security standards providing a policy-based approach, and support of federated SOA requirements through Liberty Alliance. External Service-based resource virtualization is also possible through the use of OGSA8.

We anticipate over the next 12 months that initial commercial offerings of Business Service Networks will become available providing the initial platform and roadmap for delivering L4 capability.

As we have highlighted elsewhere SOA is meant to free organizations from the tyranny of tightly coupled applications. This applies equally to infrastructure as it does business applications.

It is therefore important that organizations understand the SOI maturity level of the Infrastructure they are using to support SOA, and get a clear vision from the vendor as to their plans.

Figure 4: Virtualized Business Platform

7Strategy Review – Enabling the Business Service Network. http://roadmap.cbdiforum.com/reports/ICT/8Grid and SOA. http://www.cbdiforum.com/secure/interact/2005–02/Grid_and_SOA.php

cbdi journal © CBDI Forum Limited, May 2006 1�


By Richard Veryard

1Applied Insight: How to Find Your Competitive Advantage http://www.cio.com/archive/050106/applied.html

BSP for SOABusiness Strategy Planning for the Service Economy

Within the CBDI service engineering approach, business modeling is used at two distinct levels – at the planning level (as input to business design and service planning) and at the requirements level (as input to service design, acquisition and management). In this article, we shall discuss the development of high-level business models for planning purposes.

Introduction

Motivation

Why model your business before you plan? Because if you don’t, your plan will be the same as everyone else’s – only worse. In a recent article in CIO magazine1, Geoffrey Moore provides a few strategic thoughts from his recent book Dealing with Darwin (Penguin 2006).

Moore argues that IT needs to support the business strategy by providing different kinds of systems and services to support different capabilities – according to how each capability sits within the business strategy. I’ll come back to Moore’s model later in the article. But let me just quote a few examples of his thinking here.

At Domino’s Pizza, customer delivery is core; at Pizza Hut, it’s context. At Volvo, safety is core; at Ford it is context.

I think it is a fairly clear consequence of Moore’s thinking that you cannot have a one-size-fits-all approach to service planning. A service portfolio that is right for Domino’s Pizza is not going to be right for Pizza Hut. How does the IT person know whether he’s working in a Domino’s company or a Pizza Hut company? Moore suggests a set of questions that helps the IT person find out about the company strategy.

Discovering Company Strategy

For each competitor

What are they so good at?

Is our goal to equal or beat them at that?

Is there some other thing that we do, or could do, that they in turn would find hard to compete with?

Is it our plan to commit significant resources to such an activity?

•

•

•

•

For our own company

What is our company’s primary competitive differentiator today?

What is its best chance for equal or greater differentiation tomorrow?

What are the most important business initiatives under way to create that future competitive differentiation?

•

•

•

Table 1: Discovering Company Strategy (source: Moore)

1� cbdi journal © CBDI Forum Limited, May 2006

The Service Oriented Infrastructure (SOI) Maturity Model continued . . .BSP for SOA continued . . .

These are basically questions about capabilities and outcomes (goals). Our business modeling approach provides a systematic way of exploring capabilities and outcomes, and mapping them to each other and to the core business concepts. The marketing guru Seth Godin puts it differently2, but his questions can also be understood as referring to capabilities.

What is the hardest thing in your business? Does everyone you work with know that it’s the hardest thing? And what percentage of your time do you

spend on it?

This is the reason why business modeling is important. And you can’t just go to Accenture or IBM or SAP, and expect them to give you the standard functional decomposition for any generic food services industry, which you implement without further thought. Of course, if a standard industry model exists, you can use it as a starting point, but what is important (core to your own business strategy) is what

you inscribe onto this model. (To do otherwise would be tantamount to outsourcing your business strategy.)

ScopeWhich comes first – business modeling or service planning? In a top-down process, we may do business modeling at several different levels. We may model for a whole ecosystem, for a single enterprise, or for a domain within an enterprise. (Each domain may have a separate semantic model.) The domains themselves may be defined as part of the service planning activity.

At the higher levels, the primary purpose of business modeling is to understand the requirements for business design and service planning. (This corresponds to what in older methodologies was known as Business Strategy Planning). At the lower levels, the primary purpose of business modeling is to understand the detailed requirements for service design.

Figure 1: Service Engineering

2http://sethgodin.typepad.com/seths_blog/2006/0�/the_hardest_thi.html


Business PlanningDistinction between planning and requirements

Modeling Construct

Planning Level Requirements Level

Outcome At the planning level, we are interested in high-level business goals.

At this level, we are interested both in steady-state outcomes (what the business must continue to achieve if it is to remain viable) and major improvement outcomes (where the business wishes to make strategic improvements).

The strategic differentiation between “core” capabilities (which cannot be outsourced) and “contextual” capabilities (which may be outsourced) depends largely on mapping the capabilities to the business goals.

We are also interested in the key uncertainties facing the business.

At the requirements level, we are interested in the outcomes that can be delivered by simple or composite services, matching the required outcomes to the available outcomes, and identifying additional services to fill any outcome deficits.

Outcomes are also used to determine required service levels.

When building customer-facing services, we are interested in the outcomes for the customer as well as the outcomes for the business, and in creating win-win service outcomes.

In addition, every business outcome implies a set of services for monitoring and controlling that outcome, which may include closed-loop business intelligence.

Collaboration At the planning level, we are interested in identifying collaborators. This is a key aspect of defining scope.

For example, in the case of a regulated industry, the scope of the model may include the regulator and the regulated companies, as well as other parts of the ecosystem.

At the requirements level, we are interested in the detailed collaboration arrangements. Although we don’t generally want to fix the choreography or orchestration into the service architecture, it is useful to identify some typical collaboration patterns to make sure that the architecture is sufficient robust and flexible.

Capabilities At the planning level, we are interested in assigning capabilities to collaborators. Some capabilities will be designated “core”, while others will be designated “contextual”.

At the requirements level, we are interested in identifying capabilities that can be rendered as services.

Those capabilities that have direct value to customers, or direct relevance to external collaborators, may be exposed as external services.

Coordinating capabilities may be implemented as process-level services.

Business Concept At the planning level, we need a strategic semantic model showing the strategic assets of the business.

At the highest level, strategic assets are things that contribute to the value of the business, which might be reflected in the company balance sheet, or otherwise perceived as central to the value and viability of the business.

For example: Brand, Customer Relationships, Product, Distribution Channels, Intellectual Property, Human Capital, Knowledge.

At the requirements level, we need to have a referential semantic model, which defines how the business concepts are identified and differentiated.

The referential model supports the semantics of services and messages, and also supports the precise definition of outcomes (including metrics).

For example, at the reference model level, we need to know things like whether a married couple counts as one customer or two (or even three), and how we recognize and differentiate customers.

Domain Strategic assets may be grouped into domains. A domain manages the creation, development, preservation and use of strategic assets.

A single domain may provide the scope for a detailed requirements analysis exercise.

Table 2: Two Levels of Modeling

16 CBDI Journal © CBDI Forum Limited, May 2006


Business Strategy for ITIn the general business modeling method, we are interested in different kinds of outcomes at different levels. At the planning level, we are interested in the outcomes desired by the business (i.e. goals) and the outcomes that affect the success of the business (i.e. key uncertainties or risks).

We are going to want to see capabilities that manage these high-level outcomes (including monitoring and control capabilities), and we are going to want to understand how each capability contributes to the top-level business goals.

One way to differentiate between core capabilities and contextual capabilities is that the core capabilities are the ones with the greatest impact on the top-level business goals. Meanwhile, designating a capability as contextual is often a useful way of exporting risk. We use a loosely coupled architecture as a way of limiting the impact of a given uncertainty.

Understanding third party goals is relevant to the platform strategy – for example, releasing value by creating a better alignment between our capabilities and the customer’s goals.

Handling UncertaintyHere’s an example of how a business uncertainty may be reflected in the IT strategy.

Many companies have a strong requirement for capabilities that reference identity, but these capabilities are potentially affected by an uncertainty about the external shape of the identity ecosystem. There are several plausible scenarios as to which players will be dominant.

Credit card companies

Government agencies (e.g. national ID cards)

Telecoms companies

No single dominant position

So what is the appropriate strategic response to this uncertainty?

1. Do nothing until the situation resolves itself.

2. Pick a winning horse. Maybe try to influence the outcome.

3. Develop a strategy that is independent of the outcome.

SOA provides useful support for the third approach. If identity is a significant source of uncertainty (which it is),

•

•

•

•

then abstract away from any identity-related assumptions. Strip all identity from the applications, and prevent developers creating any local identity processing. Establish a standard set of identity-related services, separate from the basic applications. We may then be able to define two different business cases for building and using these shared services.

1. Tactical efficiency. Economics of scale / scope.

2. Strategic flexibility. Ability to accommodate any of the possible scenarios.

Experience indicates that four scenarios is a good number for this kind of analysis – sufficient to provide reasonable variety, while small enough to be meaningful to management.

CBDI ApproachIn the general business modeling method, we are interested in different kinds of outcomes at different levels. At the planning level, we are interested in the outcomes desired by the business (i.e. goals) and the outcomes that affect the success of the business (i.e. key uncertainties or risks).

We are going to want to see capabilities that manage these high-level outcomes (including monitoring and control capabilities), and we are going to want to understand how each capability contributes to the top-level business goals.

One way to differentiate between core capabilities and contextual capabilities is that the core capabilities are the ones with the greatest impact on the

top-level business goals. Meanwhile, designating a capability as contextual is often a useful way of exporting risk. We use a loosely coupling architecture as a way of limiting the impact of a given uncertainty.

Understanding third party goals is relevant to the platform strategy – for example, releasing value by creating a better alignment between our capabilities and the customer’s goals.

Having analysed goals and uncertainties and mapped these to the business concepts and capabilities, we can now produce a loosely-coupled business architecture.

This will be used in service planning to produce a loosely-coupled systems architecture.

One of the strategic questions at this level is what business services will be exposed to customers and other external collaborators. The whole business becomes a platform. (See my piece on the Lightweight Enterprise in the April Journal).

Why model your business before you plan? Because if you don’t, your plan will be the same as everyone

else’s – only worse


Examples

Customer Relationship Management

The strategic asset called Customer Relationship may be managed by a domain called Customer Relationship Management. Some administrative aspects of customer relationship management (CRM) may be delegated to a software package or commercial service (e.g. SalesForce), and some aspects of customer service may be delegated to a call centre operation, but the capability of building relationships with customers may well remain as a core capability.

So there is an important distinction here between the business capability of CRM, which is core, and the information processing capability of CRM, which may be contextual.

Part of the problem here is that CRM is an inaccurate name for a software product or service. Companies like Salesforce.com provide services that SUPPORT customer relationship management, they do customer relationship management information processing, but they don’t really DO customer relationship management.

And this is one of the reasons why it’s useful to analyse outcomes – because it defines what precisely is and isn’t being delegated to the service provider.

Industry Regulation

Consider a regulated industry, such as financial services, where a regulator must monitor a number of operating companies.

So there is a compulsory collaboration between the operating company and the regulator, which can be modeled like any other collaboration. Both operating company and regulator have an interest in controlling certain key outcomes, such as capital adequacy, and have similar or overlapping information needs.

The current arrangement (let’s say) is that the operating companies must provide loads of data in a specified format to the regulator. Some of the data may be dual-purpose – used internally as well as for external reporting. But despite this, such arrangements are often burdensome to both sides. The formats are inflexible, and the regulator is often unable to make effective use of the data to achieve the underlying regulatory goals.

Figure 2: How CRM can support management of Customer Relationship



So a good question for SOA is this. How might it be possible to use SOA to make such collaborations more productive for both sides? For example, to make the necessary controls more flexible and responsive.

One possible answer to this question involves the definition of a platform – a standard set of services that each operating company is required to establish, both to support its own internal controls, and also to expose for specified external access. In some cases, access to these services will be restricted to the regulator; in other cases, these services may be made publicly available for other interested parties such as customers and investors. Regulation often achieves its aims by requiring certain types of transparency, and it will often be more efficient to deliver this with a pull model instead of a push model.

Let’s suppose we are doing this from the regulator’s perspective. At the planning level, we focus on the commonality of the outcome (in this case Capital Adequacy) to identify the potential for a service solution (in this case a Capital Adequacy Platform).

At a later stage (analysis), we shall analyse the differences between the goals of the various stakeholders, to help specify and standardize the content of the service solution.

In business terms, the regulator needs to take a view about which aspects of capital adequacy control are aligned with the goals of the operating company. The regulator may choose to focus attention on those aspects of capital adequacy where there is the greatest risk of non-compliance, which may be inferred from a detailed analysis of the outcomes.

Strategy

Triage: Core and Contextual

The IT strategy tends to follow a different path for those capabilities designated “core” and those designated “contextual”.

This requires some triage, which is based on three aspects of the business model.

impact of capability on strategic outcomes (goals, uncertainties)

knowledge and know-how embedded in capability

future trajectory of capability (innovation, commoditization, etc.)

In the recent work of Geoffrey Moore, he talks about the split between core and contextual capabilities, and how this shift evolves over time. This model corresponds to a retail

•

•

•

Figure 3: Current Arrangement (pre-SOA)

Figure 4: Mapping Shared Outcomes to Shared Capabilities

Figure 5: Service Platform as Possible Solution


cycle which Philip Boxer and I mentioned in our article in the Microsoft Architects Journal (5).3

The classification of capabilities depends partly on the link to business outcomes / value. It also depends on the knowledge associated with each capability. Correct decoupling between capabilities depends on encapsulating the knowledge (know-how) embedded in each capability. (This is a version of the well-known architectural principle: separation of concerns.)

So we can understand the strategic cycle of capabilities (core and contextual) proposed by Geoffrey Moore (Figure

6), by reference to a model of the knowledge cycle proposed by Max Boisot (Figure 7).

Handling Diversity

Geoffrey Moore tends to describe these strategies very much in either/or terms. Either you are Volvo or you are Ford. But what if you are both? (Volvo Cars is now part of the Ford Motor Company.) What about the CIO who has to support a diverse enterprise (Ford, Lincoln, Volvo, Land Rover and Aston Martin), with as much common/shared services and infrastructure as possible?

Figure 6: Services on the Fault Line (based on Geoffrey Moore)

Outsourcing Strategy Platform Strategy

Which capabilities do you want to outsource to appropriate suppliers?

now

future

Are appropriate services available?

Are they cost-effective and adaptable?

•

•

Which capabilities might your customers want to outsource?

now

future

Would this make a viable business platform?

•

•

Table 3: Twin Track Strategy

3http://www.architecturejournal.net/2005/issue5/Jour5Metro/. See also http://www.asymmetricdesign.com/archives/2�



This comes down to a question of scope. If you are doing a service portfolio for Volvo alone, you may be able to base this portfolio on what is deemed core/contextual at Volvo. But if you are trying to do a service portfolio that will span both Volvo and Ford, you have to build in a much greater degree of flexibility, so that what is core at Volvo can be contextual at Ford, and vice versa.

It may also be a question of time horizon. Volvo and Ford may be at different stages of the knowledge cycle in respect of a given capability. So by having to support Volvo now, the CIO is perhaps implicitly supporting something that Ford will want to do next year.

So in a diverse or future-oriented enterprise, we can’t always just divide capabilities into “core” and “contextual” for the purposes of service planning. We may need additional categories such as “mostly core”, “mostly contextual” and “core-for-the-time-being”. This may create additional complications for the service portfolio, but this may be a justified investment if it makes the business SOA more future-proof.

Service Network Grid

A standard service provides a fixed one-size-fits-all service to each user in isolation. Network services provide the capability for users to connect and communicate with one another. The service network represents an opportunity for

a network provider to move upwards. A variable service network represents a further opportunity for a network provider to move sideways. (This can be understood as a response to asymmetric demand.)

ConclusionsProblem Solving. It may not be necessary for the process to specify how an organization generates the idea for a service – there may be many alternative triggers for identifying a service opportunity. What is important is that an organization has a systematic way of evaluating and implementing such ideas.

Modeling. We need a diagram that shows the ecosystem context for a service. This is used by the service planners, for identifying or verifying service opportunities. It is also used by architects, to confirm that the technical service arrangements are aligned with business service objectives.

Risk Management. One of the most important risks to a service is that the ecosystem changes in ways that undermine the value of this particular service. Among the risks to a service consumer is that the ecosystem changes in ways that invalidate the chosen service architecture. The service engineering process must include some risk management, which will (among other things) reference a model of the ecosystem.

Figure 7: Knowledge Cycle (source: Max Boisot)


Scoping. The analysis of a business opportunity and the development of a solution require an understanding of a moderately wide area, and the inclusion of multiple stakeholders/perspectives. But however broad the “big picture”, it is always possible to get a bigger picture – and the attempt to include all possible stakeholders and perspectives may lead to infinite scope-creep. This makes scoping (and if necessary rescoping) a critical aspect of the service engineering process.

AcknowledgementsThe material on handling identity and uncertainty is partly based on a contribution made by Steve Davis of Disney Studios to the SPARK architecture workshop in Las Vegas, February 2006.

Thanks to Philip Boxer for helping to clarify the relationship between Geoffrey Moore and Max Boisot, and also for clarifying the opportunities for extending the Service Network Grid to accommodate asymmetric demand.

Figure 8: Stack Strategy

Moving Beyond Early Learning?CBDI Education Services provide methodology

and reference architecture for SOA

CBDIprovides consulting and educational services to enterprises and governments

in our specialized topic areas. CBDI recommends the following classes as

essential guidance for organizations moving beyond the Early Learning stage

of activity:

SOA for ManagersThe challenges in SOA adoption are much wider than simply the technology and engineering skills. If you don’t manage the introduction properly you run the risk of wasted investment and sub-optimal results. This two day workshop for essential education for Program Managers, Architects, Governance Managers, Product Managers, Planners, Development Managers, Integration Managers and Business Analysts provides detailed guidance on managing the adoption of SOA.

Service Portfolio Planning WorkshopA three day workshop providing detailed guidance on creating a reference architecture and policy set for business services; identifying, describing business services, setting policy and establishing project scope that progressively moves an organization towards a well formed service oriented architecture. This workshop is highly relevant to project and enterprise architects, business analysts and program managers involved in SOA. Attendance at the SOA Seminar is strongly recommended as a prerequisite.

Business Modeling for SOAA two day workshop providing detailed guidance on establishing business requirements specifically for SOA, establishing requirements for information and policy based on an event driven business architecture. The class provides delegates with a methodology for determining requirements for standardization and differentiation based on assessment of business need. This class is recommended for Hybrid Business/IT managers, Strategic Planners, Program Managers, Architects, Business Analysts and Senior Developers.

These classes are available as in-house and public courses. For further details see:

http://www.cbdiforum.com/public/events/



By John Butler

Applying Product Line Techniques to SOA – Part IIExploring Configuration Management Patterns for SOA

Often separate consumers of a service will follow slightly different processes or require slightly different information for their particular business sector or domain. In addition to loose-coupling, SOA provides the architectural mechanisms to enable many types of variability at both design-time and runtime. But this is also a key driver behind software product lines and application family engineering, two well established software techniques. Part 1 of this series explored methods for identifying reusable components and enabling service variability. Once variability has been introduced, managing configurations becomes critical. This article explores the similarities and differences in configuration management between typical SOA development and the software product line methodologies.

IntroductionAnyone that has been a part of a large software development or system integration organization understands the fundamental need for managing the individual assets that comprise a complex service or system and their overall configuration for each release of that service or system. While small services do not typically require sophisticated configuration management (CM), large scale services or complete application systems often involve many analysts and developers working in parallel on the various artifacts created and modified during the lifecycle of that service or application system. And while we want to strive to limit the rate of change in our services, change is inevitable. In order to prevent accidentally “stepping on each others toes” during the lifecycle a robust configuration management process and tooling infrastructure must be established. As noted in an earlier CBDI report1 “If change control does not exist, as more services are introduced into the enterprise, every weekend or maybe even every day can turn into an experiment in software interaction” – Charlie Bess, EDS.

1CBDI Journal, The SOA Lifecycle. Jul/Aug 200�. http://www.cbdiforum.com/secure/interact/200�–0�/SOA_Lifecycle.php


Applying Product Line Techniques to SOA continued . . .

As if this problem weren’t already difficult enough, SOA introduces additional complications that, if left unaddressed, can eventually swamp a service delivery organization. Part 1 of this series2 talked about the similarities of SOA and Product Line approaches to software development in the area of identifying and enabling variability within services. But while providing a vehicle to enable variability is a key benefit, managing the various configurations that may all be in operation simultaneously significantly increases the complexity of the asset/configuration management process.

What do we mean by an “Asset”?Terminology varies greatly between methodologies. The terms “asset”, “artifact”, “configuration item” have all been used as generic terms for the various “things” containing information generated during the lifecycle of a service. To add further confusion, the Reusable Asset Specification3 standard created by Rational Software prior to its purchase by IBM and subsequently adopted by the Object Management Group (OMG) defines an asset essentially as a collection of artifacts where an artifact is nothing more than a file. CBDI generally refers to a software development asset (SDA), artifact, and file interchangeably.

Examples of the types of SDA that might be created during the development and ongoing maintenance process include the requirements specifications, complete or partial models (such as use case models, analysis models, or design models), architectures, design constraints, user interface specifications, project management plans, test cases, test results, change requests, and/or configuration management plans. In other words, anything that impacts, drives or is created during the development and ongoing maintenance cycles of the service is potentially an asset that should be managed.

Asset Management vs Configuration ManagementWhile asset management has evolved to include much more than simple software configuration management (SCM), SCM still plays a major role in the lifecycle of a service or system. Whereas asset management often includes capabilities such as provider harvesting, provider publication, consumer discovery, consumer reuse and metrics8, configuration management is traditionally defined as the “set of activities designed to control change by identifying the work products that are likely to change, establishing relationships among them, defining mechanisms for managing different versions

Term Methodology Definition Synonyms

Asset AFE4 Valuable, high-quality software workproducts (such as code, designs, architectures, interfaces, test), documents, tools, processes, and compiled knowledge (guidelines, models, formulas, . . . ).

This term is sometimes used instead of component or work product.

FAST5 Not used.

Product Line Practice6

Implicitly defined as a software artifact that is used in the production of a product in a product line. An asset may be an architecture, a software component, a process model, a plan, a document, or any other useful result of building a system.

RUP7 No explicit definition within RUP though term is used.

2CBDI Journal, Applying Product Line Techniques to SOA. Feb 2006. http://www.cbdiforum.com/secure/interact/2006–02/Applying_Product_Line_Techniques_SOA.php3Formal/05–11–02, Reusable Asset Specification, Version 2.2. The Object Management Group. November 20054Jacobson, I.; Griss, M.; & Jonsonn, P. Software Reuse: Architecture, Process, and Organization for Business Success. New York, NY: Addison-Wesley, 1��.5Weiss, D. & Lai, C. T. R. Software Product-Line Engineering: A Family-Based Software Development Process. Reading, MA: Addison-Wesley, 1��.6Clements, P. & Northrup, L. Software Product Lines: Practices and Patterns. New York, NY: Addison-Wesley, 2002.7Rational Unified Process8CBDI Journal, Software Development Asset Management with LogicLibrary Logidex. Jun 2005.


Reusable Asset Specification

An asset is a solution to a software development problem. The problem may be related the evolution of the system’s artifacts or be directly related to the domain problem that the system is being developed for.

Artifact AFE Not used.

FAST Artifacts represent final or intermediate work products or the information needed to produce them. Such work products may be documents, code or various representations of information. For example, a set of data stored in a file may be an artifact. Artifacts indicate what must be produced.

Work product

Product Line Practice

No explicit definition. Used generally to mean a work product or file of generated during system development.

RUP An artifact is a work product of the process: roles use artifacts to perform activities, and produce artifacts in the course of performing activities. Artifacts are the responsibility of a single role, making responsibility easy to identify and understand, and promoting the idea that every piece of information produced in the process requires the appropriate set of skills.


An Artifact is either an actual file or represents a logical entity that contains at least one child Artifact that is an actual file. As an actual file, an Artifact is a work product that can be created, stored and manipulated by asset producers/consumers and by tools.

Configuration Item

AFE A configuration item is a segment of a model that may be subject to version control such as a use case type, a service package containing analysis types , or some code modules. Represented by a package, <<configuration item>>. An entity is a configuration that satisfies an end-user function and that can be uniquely identified.

FAST Not used.


Implicitly defined as an artifact that is under the jurisdiction of configuration management

RUP An entity in a configuration that satisfies an end-use function and can be uniquely identified at a given reference point.


Not used.

Work Product AFE A work product is a unit of software model, code, or document that can be independently managed within a software engineering organization. Individual types and classes from different models, diagrams, and related documents are typical workproducts. Complete models, subsystems, and test models are also workproducts.

Sometimes referred to as Asset.

FAST Synonym for Artifact Artifact


Not used.

RUP No explicit definition.


Work product is not explicitly defined though it is implicitly defined as a file produced during project.

Term Methodology Definition Synonyms



of these work products, controlling the changes imposed, and auditing and reporting on the changes made.”9 In other words, it’s a methodology for managing the change to assets during the lifecycle of a service or application.

Service Variability, Dependence on Core Services and Other Configuration Management IssuesAs discussed in Part 1 of this series, there are substantial similarities between SOA methodologies and product line methodologies such as FAST, Product Line Practice Initiative, and Application Family Engineering from the aspect of service/product variability. Support for simultaneous operation of multiple variations of services (or products in the product line domain) causes a multidimensional version

of the configuration management problem.

Configuration management for a single system defines the set of versions of configuration items that comprise each version of the overall system (see Figure 1). For product lines, versions of each configuration item must be tracked for each product in the line (see Figure 2). This is not surprising since development and support must be provided for each product. As an added wrinkle, however, some products within the line may use an older version of an asset due to a particular need of the market or client base it supports. With a small number of products/variations this is not likely to be much of a problem. But as the number of variations grows, the problem can grow geometrically.

The following is an example of this variation explosion. Some years ago I worked for a small Internet company that provided contract management services within the

9Pressman, Roger S. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, NY. ��2

Figure 1: Versioning of Assets for a Service


pharmaceutical supply chain. These services included the ability for group purchasing organizations (GPOs) to create requests for proposals (RFPs), send them to pharmaceutical manufacturers and compare the proposals for product and price that came back from the manufacturers. Once a proposal was accepted, the GPOs would forward the agreed pricing information to wholesalers. The wholesalers were then responsible for actually filling orders for product to pharmacies and hospitals who qualified for the GPO-Mfr contract pricing.

In all there were approximately 100+ GPOs, 100+ manufacturers, and 15+ or so wholesalers – not a huge market but even so most organizations had a slightly different contracting processes and each manufacturer had a different proposal format resulting in potentially thousands of combinations. There are a number of patterns for dealing with this type of problem including data-driven approaches that would reduce the number of actual services running. However, variations would still likely occur and need to be managed.

Another difference between single system SCM and product line SCM is that in single system SCM each product or system is managed separately. With product lines such separation

is not feasible due to the reuse of the core components/assets across all the products in the line. As shown in Figure 3, all three systems depend on the Products component. This is typical of product lines wherein many, if not all, of the products will depend on a core set of components that encapsulate key functionality. Changing one of these will likely impact many of the products in the line. Therefore, careful analysis of the impact must be undertaken. If the change is common to all products then the change can be made to the core asset. If, however, variation is required, refactoring of the assets may be necessary. This type of effort would need to be coordinated across the product line.

Solution delivery using services is similar. Mature IT organizations implementing SOA across their infrastructure using a coordinated set of services do so to both a) create a loosely coupled architecture, and b) reduce redundancy (increase reuse). Business rules are implemented only once and changes tend to be more isolated. Figures 4 and 5 show an example of an implementation model and the corresponding configuration item dependencies, respectively, for a portion of the core assets shown in Figure 3. Figure 4 uses UML 2 to illustrate the OrdersService and

Figure 2: Configuration Management for Multiple Related Services



the ProductsService being used by OrderFulfillmentManager implementation.

The result of this type of architecture is a significant increase in reuse. With that reuse, however, comes increased dependency on the core services. Luckily, the dependency is only on the service specification (including the interface syntax and functional and non-functional specifications), not the implementation itself. The service implementation (the Managers shown in Figure 4) and location can be changed independently as long as the specification does not change. That said, the fact remains that if one solution requires a change to a core service, the service cannot change without potentially impacting other dependent services. This results in the same refactoring scenario identified above for product lines and hence illustrates the potential need for coordinated configuration management across an SOA infrastructure.

The obvious question is whether this type of coordination is required in all cases. And the (hopefully) obvious answer is no for a couple of reasons. First, some services are not critical to business operation. They provide functionality that is convenient to the end user but will not cause business to stop if the interface breaks. An example of such a service

might be a “Recent News” service that is plugged into a user portal. If this interface were not available for a period of time or if the service specification changed so as to make it incompatible with the service consumer business would not be affected to any significant degree (unless, perhaps, it was a news service). In this case, coordinated CM may not be called for.

Second, depending on an organization’s sourcing strategy, some services may be provided by third party organizations. Like other services, third party services may change over time driven by changing regulations, a changing market landscape, or by changes required by other consumers of the service. Again, as stated above, changes to the service implementation will not affect the service consumer. It is the service specification that is of concern. These third parties are very unlikely to allow another organization to control their CM environment. SLAs should be put in place to ensure plenty of advanced notification should the service specification be required to change.

In addition to the obvious development issues involved in managing the various releases of related products in a product line or services in an SOA, once a system or service

Figure 3: Sample Dependency Diagram for a Product Line


is deployed user support also requires sophisticated build and release management within the CM tooling. As problems are reported by end users, the support staff must be able to recreate the specific version in use in order to track down the cause of the problem. In the contract management example above, support personnel were not authorized to see live data from service users. If a problem could not be resolved by level one or two support, a separate support environment was created to allow level three support to recreate as closely as possible the production environment using dummy data. Issues could then be diagnosed without impacting production.

Again, not all services require this level QoS. It may be feasible to stop a service for a period of time depending on the criticality of that service. However, more and more organizations are creating mission critical systems using SOA. Downtime can mean thousands of dollars in lost revenue or increased cost. When such is the case, sophisticated testing and support environments must be established and SCM is an integral part.

Finally, as mentioned above, single system CM involves only one development team, product lines often have multiple teams using the components/assets developed by another

team, usually the core asset development team. Since these teams are often not co-located, a very sophisticated SCM repository must be employed to allow for replication of configuration items and parallel development.

When distributed development is in place, accessing a central repository from remote locations often causes significant delay due to the high network bandwidth required to support the check-in/check-out process. Therefore replication of the items is a key feature and is built in to the higher end tools. Further, parallel development may well result in multiple versions of core assets being modified simultaneously by different groups for different purposes. The CM system must therefore allow multiple branches of work to proceed unhindered and then provide merge and conflict resolution capabilities when joining the branches back into the main stream.

Figure 4: Order Fulfillment Implementation Model

�0 cbdi journal © CBDI Forum Limited, May 2006


SummaryThe potential benefits of SOA are tremendous. But as the saying goes, “With great power comes great responsibility”. Vendors talk about how easy it is to just wire services together into complex systems that can run your business. The examples shown, however, are toy problems that do not represent real world of solution development for most organizations. I was recently at a technical conference where a presenter gave yet another presentation of the stock quote example for a service. He talked about how the developer had just looked at the XML for the services and “wired it up” thereby incorporating the service into his solution. This type of example is useful for the neophyte as a way to understand how the underlying technologies work. Unfortunately, this is like comparing building a dog house to building a sky scraper. While one might just start sawing wood to build a new home for Fido, a skyscraper requires a tad more planning and engineering in order to complete safely.

Figure 5: Configuration Item Dependency Example

Service Engineering ServicesIntroducing SOA requires systematic approaches that span technology and application architectures,

processes and organization. CBDI are specialists in this entire topic area and are actively assisting major organizations to understand and embrace this thinking.

CBDI has deep and practical experience gained from our research and numerous consulting engagements and can guide organizations in this complex area.

Service Engineering – An Integrated Set of Methodologies

CBDI provides a comprehensive set of services for managing change including:• Roadmap Planning Workshops• Strategic Planning for Business and IT• Methodology Introduction and Customization• Business Design

Contact CBDI by email at [email protected] by telephone at +353 28 38073

www.cbdiforum.com

Subscribe to the CBDI Forum

The CBDI Journal is published monthly. In addition to the

Journal, subscription includes electronic access to current

and all back numbers that now represent a significant resource

library. There are individual and corporate subscription

schemes. Corporate subscription includes access

to Powerpoint libraries and our workshop materials.

For more details and to subscribe see:

www.cbdiforum.com

CBDI Raison d’etreWe aim to provide unique insight on component and service oriented technologies and processes for the software industry and its customers. To provide high quality analysis and other information resources on best practice in business software creation, reuse and management. To maintain the highest level of independence.

Modus OperandiThe CBDi Forum has a number of channels:

• Subscription services – provision of continuous commentary and information.

• Workshops and seminars – providing indepth briefing and guidance on advanced architectures, processes and practices.

• Consulting – including Adoption Roadmap workshops, methodology customization, architectural guidance and reviews, business design advice, strategy development.

How we compare with othersWe are not a mass market, media oriented organization. All material published by the forum is unique. The majority of material is published by our own analysts, or commissioned from others, and under strict editorial control to ensure accuracy. We rigorously exclude spurious marketing.

We provide depth insight which covers a narrow topic footprint in a deeper way than the other analysts, and in particular cover not just the technology, but also the architectures, usage, practices and processes.

Also we are unusual as analysts; we do not simply echo what the vendors say, we are a think tank, identifying new ideas, opportunities and providing stimulus for thinking. We are thought leaders providing ideas generation and a rich source of conceptual thinking based on practical, real world feedback.

Who Reads the CBDI JournalTechnical leaders including Technical and Application Architects, Business Analysts, Consultants, CTO’s, Designers, Product Strategists, Senior Developers, Project Managers, CIO’s etc. Subscription is split roughly 40% USA and 50% Europe.

Contact UsFor further information on any of our services contact us at: [email protected] or +353 28 38073 (international)

IMPORTANT NOTICE: The information available in CBDI publications and services, irrespective of delivery channel or media is given in good faith and is believed to be reliable. CBDI Forum Limited expressly excludes any representation or warranty (express or implied) about the suitability of materials for any particular purpose and excludes to the fullest extent possible any liability in contract, tort or howsoever for implementation of, or reliance upon, the information provided. All trademarks and copyrights are recognised and acknowledged.

Independent Insight for Service Oriented Practice

may 2006everware-cbdi.com/public/downloads/pURv0/journal2006-05.pdf · capabilities of the ESB and...

Documents

Transcript of may 2006everware-cbdi.com/public/downloads/pURv0/journal2006-05.pdf · capabilities of the ESB and...