issn 1745–1884 journal - cbdi forumeverware-cbdi.com/public/downloads/9yh9a/journal2005-12.pdf ·...

CBDIJournal3 Editorial

On SOA Maturity Models and Swimming in the Shallow End

4 Best Practice ReportThe SOA Maturity Model

Adopting SOA is a medium to long term program for any enterprise. There are many different strategies that can be adopted and the right approach will be specific to every organization. However there is a high level of commonality in the generic capabilities that are applicable to every enterprise and a maturity model can provide guidance in both planning and monitoring progress. CBDI first published a Web Services and SOA Maturity Model in 2003. Since then we have learnt a lot and in this report we update our maturity model to consolidate the experience of working with numerous early adopting enterprises. We also take a look at other maturity models

that have been published recently.David Sprott

18 Market Trends ReportDirections and Diversions

As we rapidly approach the end of 2005 it’s a good time to take stock and consider where the world is heading in 2006 and beyond. We look past the infrastructural issues to the next major phase of activity as the industry moves to commoditize and deliver application

and content services.David Sprott

23 Best Practice ReportSOA in the Public Sector

Many governments are very active in adopting SOA. This is because SOA may address some of the major issues that governments face, particularly the complexities of highly federated organizations that need to present a coherent business process face to citizens and businesses. In this report, we review the

opportunities and challenges.Richard Veryard

Independent Insight for Service Oriented Practice

DeCemBer 2005

ISSN 1745–1884

Seasons Greetingsto all

CBDI Members

This year CBDI has decided that instead of sending

Seasons Greetings cards we will make a donation

to charity. We have decided to support The Asian

Earthquake Appeal by the Red Cross.

http://www.redcross.org.uk//standard.asp?id=49880&cachefixerhttp://www.redcross.org.uk//standard.asp?id=49880&cachefixerhttp://www.redcross.org.uk//standard.asp?id=49880&cachefixerhttp://www.redcross.org.uk//standard.asp?id=49880&cachefixerhttp://www.redcross.org.uk//standard.asp?id=49880&cachefixer

http://www.redcross.org/news/ds/profiles/disaster_profilei-sasiaearthquake.htmlhttp://www.redcross.org/news/ds/profiles/disaster_profilei-sasiaearthquake.htmlhttp://www.redcross.org/news/ds/profiles/disaster_profilei-sasiaearthquake.htmlhttp://www.redcross.org/news/ds/profiles/disaster_profilei-sasiaearthquake.htmlhttp://www.redcross.org/news/ds/profiles/disaster_profilei-sasiaearthquake.htmlhttp://www.redcross.org/news/ds/profiles/disaster_profilei-sasiaearthquake.htmlhttp://www.redcross.org/news/ds/profiles/disaster_profilei-sasiaearthquake.html

http://www.redcross.ca/article.asp?id=014928&tid=001http://www.redcross.ca/article.asp?id=014928&tid=001http://www.redcross.ca/article.asp?id=014928&tid=001http://www.redcross.ca/article.asp?id=014928&tid=001http://www.redcross.ca/article.asp?id=014928&tid=001http://www.redcross.ca/article.asp?id=014928&tid=001

Editorial

www.cbdiforum.com

On SOA Maturity Models and Swimming in the Shallow End

Ihave been meaning to update the CBDI SOA Maturity Model for months. The original model has worked well but there have been a lot of things that needed updating. The primary changes have been to create a clear differentiation between the maturity model and the roadmap, and to create a clearer view of capability at each level and to establish the technique of capability dependency.

This capability concept is a useful device, which I attribute fully to CMMI. However whilst I considered adopting the CMMI levels I decided on reflection that these are less useful than our original maturity level structure. The CMMI levels are actually quite specific and very appropriate to process improvement, whereas SOA adoption encompasses a broader set of concerns including organization and management issues, and really underpins a massive shift in the way IT solutions are created, delivered and managed. In fact it was this line of thought that led me to rename the final maturity level to Cultural Integration.

What I see happening today is that SOA is being adopted in a manner that ignores this profound transformation. I see widespread evidence of SOA being adopted at project level with little or no consideration of the wider issues. I frequently ask the question, “do you think a city plan can be tried out on the neighborhood block, and then progressively evolved to cover the concerns of the surrounding suburbs and then and only then to cover the concerns of the entire city?”

But amazingly this approach is being actively encouraged by many vendors, and in the Maturity Model report I look at the various models that have been published recently and surprise, surprise they all guide that SOA adoption commences at the project level, and enterprise concerns are only required at a much later stage. Wow! In my second report this month, in which I am discussing the current state of the market, I advance some theories about this worrying state of affairs.

In this same market report I make the comment that in the wider scheme of things we are really only at the start of a long term transformation. This transition to SOA is something that is going to take years, particularly for larger organizations. So even if 2005 has been “the year of SOA” it has really only been the year of “SOA in the shallow end”, and in 2006 we will see many more organizations starting to try to swim out of their depth, but my guess is that most of them will be keeping their butterfly wings on or secretly keeping one foot on the bottom of the pool, even if they are trying to make it look like they are swimming out of their depth.

David Sprott, CBDI December 2005

The SOA Maturity Model encompasses a broader set of concerns including organization

and management issues, and really underpins a

massive shift in the way IT solutions are created, delivered and managed.

Best Practice Report

�� cbdi journal�©�CBDI�Forum�Limited,�December�2005

by david Sprott

The SOA Maturity Model

Adopting SOA is a medium to long term program for any enterprise. There are many different strategies that can be adopted and the right approach will be specific to every organization. However there is a high level of commonality in the generic capabilities that are applicable to every enterprise and a maturity model can provide guidance in both planning and monitoring progress. CBDI first published a Web Services and SOA Maturity Model in 2003. Since then we have learnt a lot and in this report we update our maturity model to consolidate the experience of working with numerous early adopting enterprises. We also take a look at other maturity models that have been published recently.

IntroductionA maturity model is a guide for process improvement. The nature of any generalized maturity model is that there is no right or wrong approach, rather the model is a framework that provides a set of benchmarks which may be helpful to an organization in developing it’s own approach. The maturity model is a basis for planning and managing change. It suggests areas where capability can be measured in a systematic manner so that the appropriate level of trust can be vested in the organization at a given point in time, tempering the optimism of the over enthusiastic with practical assessments of actual capability.

A good way to think about this is that the maturity model focuses on the what not the how. It identifies what the capabilities are at various levels of relative maturity.

In updating the CBDI Web Services and SOA maturity model� we have continued our original approach of taking a very broad perspective. We recommend that a good maturity model will be strongly process based, and have a scope that is much broader than simply technology usage capability. We believe this is important because SOA and CBD (component based development) are long term transformation programs which will eventually have a very profound impact on existing organizations. In offering a revised SOA maturity model we aim to provide a framework which encompasses many different stakeholders, and encourage others to further develop and specialize the model.

Over the past few years we have used the original CBDI model as the foundation for our numerous roadmap workshops. The concepts of phases and streams have been really useful planning devices. What happens in practice is that the maturity model provides the generalized framework that can guide the development of an organization specific roadmap.

1CBDI�Report�–�A�Web�Services�Maturity�Model.�http://www.cbdiforum.com/secure/interact/2003-05/maturity.php3

cbdi journal�©�CBDI�Forum�Limited,�December�2005� 5

In this report we commence by commenting on several recently published models that have some direct relevance to SOA and then develop our earlier models further.

A Clutch of Maturity Models!I am not sure what the collective noun is for maturity models, but given the recent spate of activity, it seems we need some way to describe the phenomenon.

In the IT world the CMMI2 Capability Maturity Model Integration is well known as a frame of reference for IT process improvement and variants have been developed for many disciplines such as software engineering, systems engineering, software acquisition, systems security and more. Not surprisingly therefore some of the published maturity models reuse the CMMI ideas.

The CMMI maturity levels, illustrated in Figure �, are very useful insofar as they provide a reference model of mature practices in a specified discipline. But as yet the CMMI has not addressed architecture. While there is guidance in moving processes from a project focus to an organization focus, there is no coverage (yet) of architectural control and governance. This certainly raises some interesting questions because architectural process integration is an area of considerable importance and complexity.

Vendor CollaborationIn September the vendors AmberPoint, BearingPoint, Sonic Software and Systinet announced� the publication of a collaborative effort to define the SOA Maturity Model reproduced in Figure 2. This model is based on the CMMI framework. I like what the group has done in relating the

2Capability�Maturity�Model®�Integration�(CMMI)�is�a�process�improvement�approach�that�provides�organizations�with�the�essential�elements�of�effective�processes.�http://www.sei.cmu.edu/cmmi/adoption/pdf/cmmi-overview05.pdf3AmberPoint,�BearingPoint,�Sonic�Software�and�Systinet�Collaborate�on�Model�to�Assess,�Guide�and�Establish�Vision�for�Maximizing�the�Strategic�Benefits�of�SOA�investments;�http://www.systinet.com/pr/1�5;�http://www.sonicsoftware.com/solutions/learning_center/soa_insights/movin_soa_on_up/index.ssp

Figure 1: CMMI�Maturity�Levels�(Source�Carnegie�Mellon�University)

�� cbdi journal�©�CBDI�Forum�Limited,�December�2005

The SOA Maturity Model continued . . .

CMMI based levels to SOA benefits – Functionality, Cost Effectiveness, Responsiveness, Transformation and Optimization. This is a nice way to characterize the evolving interest areas. In the early stages SOA activity is driven by project functionality, and cost effectiveness. Then at Level � the focus on business and collaborative services enables responsiveness. However at Level 4 it comes clear that Transformation is not about business transformation but about process measurement and Business Activity Monitoring in particular. This is further reflected in Level 5 where Optimization is defined as automatic response to events.

This is all good stuff but essentially it is a maturity model about types of services, and not altogether surprisingly, focused on the technical infrastructure and management tools capability in particular, to deliver services with different characteristics. This is a perfectly valid perspective but represents merely one strand of a broader enterprise maturity model. So this model should perhaps be renamed a Service Maturity Model.

IBMAlso in September IBM published a report on DeveloperWorks describing their Service Integration Maturity Model4 (SIMM). The SIMM describes seven stages of maturity on the path to SOA adoption:

�. Silo (data integration)

2. Integrated (application integration)

�. Componentized (functional integration)

4. Simple services (process integration)

5. Composite services (supply-chain integration)

6. Virtualized services (virtual infrastructure)

7. Dynamically reconfigurable services (eco-system integration)

This list attempts to do something similar to the platform vendors’ model, it provides a maturity model for types of services, which spans silo based data integration and proprietary application integration in Levels � and 2, then legacy transformation at Level �, with what the authors refer to as embarking on the early stages of SOA at Level 4. This makes sense in context with IBM’s customer base that spans a wide range of technologies and architectures.

Interestingly the IBM authors suggest that at level � the organization componentizes and modularizes major or critical parts of its application portfolio. This is a little different to what I normally expect. In my experience componentization generally happens after a functional integration stage based on wrapping and harvesting existing systems, because in the early stages there is generally little justification for this major effort. The IBM maturity model therefore doesn’t help us to understand the dependencies between the capabilities at the various stages of maturity. In this example the capability to componentize depends on the capability to cost-justify componentization which in turn depends on the size and success of the previous harvesting effort.

The IBM paper then goes on to describe their experience that “the process of adopting Web services and SOA starts in many cases at the ad hoc stage on projects. This gradually evolves into a general technology adoption . . . Once the technology adoption stage achieves some level of maturity, the results start trickling into the lines of business. They see the value in sharing services across lines of business to eliminate redundancy and having a single point of access to existing functionality that reduces complexity and cost and increases flexibility.”

There’s nothing intrinsically wrong with this, it’s actually a perfectly valid scenario – we might refer to it as “SOA by stealth”. In reality this is more like a roadmap – a directional plan than a maturity model. The problem with this is that any enterprise view will be delayed, and more worrying the early architectural work will probably not be reusable or more widely applicable. I discussed this scenario recently with IBM Global Services architects, and they admitted that for them this approach seems to be prevalent because their customers are generally not yet ready to adopt a more proactive strategy. This is illustrated by the IBM SIMM in Figure � which shows very clearly the softly, softly approach. A stronger capability driven approach would highlight that this situation is occurring because the maturity of the technology organization is ahead of the maturity of the line-of-business (LOB), and then put in place actions to develop and align the LOB capabilities.

�IBM�Maturity�Model�Paper�–�Increase�flexibility�with�the�Service�Integration�Maturity�Model�(SIMM)�http://www-128.ibm.com/developerworks/webservices/library/ws-soa-simm/

Figure 2: Service�Maturity�Model�from�AmberPoint,�Bearing�Point,�Sonic�Software�and�Systinet

cbdi journal�©�CBDI�Forum�Limited,�December�2005� �

Stop Press – IBM has just published a Part II of their Maturity Model5 which maps CMMI levels to characteristics and impacts.

BEA SystemsBelieve it or not, in September BEA also published a nice article by David Groves6 which includes a maturity model. BEA has some excellent advice which is summarized here:

• Think strategically, execute tactically

• Think from the top down.

• Think from the bottom up.

• Consider infrastructure services: Identify common supporting functionality requirements.

• Expand slowly.

• Build an Application Catalog: On a project-by-project basis, harvest and reuse service modules.

• Focus on benefits: Phase projects in order of ROI

BEA show a good understanding of maturity models, they recommend a three stage approach that moves through

Exploring, Expanding and Exploiting, which is very similar to our original Learning, Integration, Reengineering path. They then map these three stages to the CMMI levels as shown in Figure 4. However the content of each level does seem to be more like a roadmap than process capability.

Where I worry however about this model is that, like the IBM model, it encourages the delay of enterprise architecture. Leaving Enterprise SOA Adoption issues until Level 5 suggests that project architectures can grow up to be enterprise architectures. This is not credible.

Consider if you start city planning by concentrating on a few blocks, then gradually expanding this to cover some suburbs. Do you think the shared services and policies developed piecemeal will be easy to bring together? SOA is inherently an enterprise level approach. That doesn’t mean that everything has to be sorted out for the entire enterprise from the outset, but it does mean that core policies and reference architectures need to be developed in such a manner that they are coordinated and consistent. SOA needs to consider the enterprise at least at the minimum necessary level from the outset. Otherwise the overall goals of SOA will be unattainable. Which brings us nicely to the discussion of “where are we going?”

Figure 3: IBM�SIM�Scopes�of�Adoption�(Source�IBM�DeveloperWorks)

5IBM�Maturity�Model�Part�II.�http://www-128.ibm.com/developerworks/webservices/library/ws-soa-method2/�Successfully�Planning�for�SOA.�http://dev2dev.bea.com/pub/a/2005/11/planning-for-soa.html

8� cbdi journal�©�CBDI�Forum�Limited,�December�2005


SOA VisionBefore going too far it’s important to have a vision – to understand what maturity means. If you know where you need to get to, you can plot a course. Further you need to have a view of SOA that reflects your situation, which we will assume is an enterprise. Note there are other domains and they will have different visions. For example the enterprise application vendor or ISV will have a very different vision, as will the BPO supplier, the communications intermediary and so forth.

So first let’s just recap briefly.

• SOA is as much a business modeling approach as it is a software engineering paradigm. Today SOA might be mostly about technology, but by the time we are finished business and IT will share the service perspective in business processes, products and in planning.

• Service-oriented architecture is a design approach to standardize business processes and software functions, or services, so that numerous

dissimilar value chains and technologies can share them – both inside and outside the company. The standardization however is also balanced with the capability to assemble differentiated business processes that can support innovation and strategic goals.

• Our fundamental objective with SOA is to achieve broad sharing of services in new runtime contexts in order to deliver an inherently agile business environment. We do this by decoupling solutions from providing resources supporting both business and infrastructure services.

These goals are about profound and radical change in the way enterprises organize their information solutions. They will eventually impact business and IT in equal measure. As an industry we are being driven to this restructuring simply because we have no alternative. Many members report their ability to respond to change is deteriorating year on year because without appropriate architectural foundations everything becomes increasingly complex and unmanageable.

Figure 4: BEA�Maturity�Matrix�(Source�BEA�Systems�Inc)

CBDI Journal © CBDI Forum Limited, December 2005 9

It’s vital therefore to keep these long term goals in sight, because without vision we will surely drift and compromise at every step along the way.

SOA Maturity Model Framework

Level/Phase StructureThe original CBDI SOA Maturity Model identified maturity levels based on the predominant type of activity required to move an organization to a higher maturity state. The underlying concept is that pretty much every enterprise needs to go through a process of exposing and publishing services from primarily existing systems, as a precursor to the phase of activity in which the IT and business organizations capitalize upon the service view. The original levels, which map directly to the CBDI Roadmap are:

• Early Learning

• Integration

• Reengineering

• Maturity

We have found these Levels/Phases really useful, but we also like some of the BEA terms, so on the basis that imitation is the sincerest form of flattery, we will adopt a dual naming for the first three phases; they are not entirely synonymous and provide a richer picture of the phase activity.

Considering the vision statements above it is very clear that the transformation (sic) to SOA is fundamentally a cultural change. It’s about moving from an environment where

architecture was an optional extra to an essential foundation. Moving from “architecture by persuasion” to architecture by policy. Accordingly we are strengthening the original concept of maturity by renaming it Cultural Integration.

Naturally we considered the CMMI phases. We can understand fully why it might be attractive to align with this axis. However the CMMI levels are not ideal. Level 1 is immaterial. Level 2 focuses on project characterization

which is not a good place to start. This is an SOA model, and in our opinion it’s

really important to start off from the outset by taking “some” enterprise level decisions. So while a project characterization level might be useful to “measure” non compliance or lack of progress, it is essentially the same as the initial stage in the SOA context. More generally we feel the CMMI framework is strongly focused on project process improvement, and while the SOA model needs this, it equally needs a broader perspective.

SOA Capability Maturity ModelAs discussed the various maturity models considered earlier in this report are really not directly comparable with the CMMI approach, even though they may use the same or a derived Level structure.

In reviewing and (attempting to) improve the CBDI maturity model we saw the identification of the levels as less critical than the characterization of the level content.

The maturity model needs to provide guidance on what process capabilities are necessary to have established at

The business organization reflects the service structure both in terms of business services offered and business components

The entire organization is inherently loose coupled. Definition of services, components and articulation points is a crucial aspect of organizational design.

There are mandatory policies governing the usage and customization of standard services and business processes

Business change is implemented on a continuous basis. Impact of change is a key metric which is defined before a service or solution is implemented. The impact of different types of change are well understood and there are pre-defined responses with well understood costs and response time parameters.

There is a formal definition of standardized and differentiated services, business processes and software components

Shared services are primarily sourced as commodities. However in the core areas of the business the shared service are customized to ensure innovation and strong competitive differentiation.

Definition of business flexibility requirements is a joint responsibility between business and IT. The requirements are articulated formally as functional and non functional requirements

Table 1: Possible Enterprise SOA Vision

which is not a good place to start. This

We recommend that a good maturity model will

be strongly process based, and have a scope that is

much broader than simply technology usage capability.



Architecture Level

Capability Enabling

1 Architecture recovery & reconstruction Development of canonical models, evolutionary migration plan

1 Basic minimum technical standards Basic consistency of approach, avoiding period of uncontrolled activity, Technical interoperability

1 Basic minimum semantic standards Early deliveries to be reused, Semantic interoperability

2 Canonical Business Type Model Basis for common understanding , Identification of stable core business services

2 Layered architecture, design patterns, dependency, standardization, customization

Initial policy set

2 Partial Service Portfolio Plan Sharing of Core Services , Project coordination

2 Service contract templates Consistent contracts

2 Rich Service Specification templates Consistent specifications, Provider/consumer separation, Best sourcing, Basis for service lifecycle asset management

2 Governance compliance reviews Management of policy exceptions, evolution of policy

2 Defined requirements for business standardization and differentiation

Appropriate sourcing decisions, direction of investment $

2 Enterprise Taxonomy Internal Semantic interoperability

3 Completed Service Portfolio Plan

3 Mature policy set evolved from level 2 experience and fully customized to enterprise needs

Consistent approach to policy implementation

3 Industry sector taxonomy Semantic interoperability across partners/ecosystem

4 Resource Virtualization architecture Focus on core, Best sourcing, Demand driven scalability

Operational Infrastructure Level

Capability Enabling

1 Basic minimum operational infrastructure Unsupported services with little or no guarantees

1 Basic minimum management infrastructure Knowledge of what services exist and who’s using them

1 Transport Level Security Point to point security

1 Basic permissions Control use of services

2 Basic ESB Message-level mediation

Platform neutral service interoperability

Service enablement and integration of existing non-service based applications

2 Service Orchestration Process Automation

Service assembly/aggregation/composition

2 Basic Service Management Health Monitoring and alerts

Auditability by Logging

2 Message Level Security Fine-grained encryption and signing of message content


2 Tool-dependent policy management Policy-based Service execution

2 Contract-based permissions Access use of services based on usage and commercial contracts

Message/content level permissions

3 Common delivery platform Standardization of enterprise ESBs and operational infrastructure services

3 Advanced ESB Policy-based mediation

Dynamic mediation based on status and notifications

Distributed, platform neutral interoperability

3 Service-based Workflow Management Integration of workflow and service orchestration

All activities represented as Services

3 Advanced Service Management Run-time governance and policy compliance checking

3 Combined Service and System Management Correlation of service and resource events

Manage to SLA

3 Tool-independent policy management Consistent Policy execution across Services

3 Business Activity Monitoring Business dashboard

Correlation of business and service events

3 Federated security Multi-hop for external collaboration support

Secure processing by intermediaries

3 Use of Infrastructure Service Providers Specialised capability

3 Use of Infrastructure Intermediaries Managed ecosystems

3 Infrastructure Resource Planning Managed resource base

4 Infrastructure is SOA Virtualization of infrastructure resources

4 Business service console Business requirements manage resource allocation

Service Lifecycle Infrastructure Level

Capability Enabling

1 Service aware IDE Service creation

Service delivery and usage

2 Registry Stage 1 Indirect service usage (proxy), governance and usage, Internal publication and discovery

2 Tool-dependent Policy Management Abstraction of policies from implementation

Policy-based lifecycle

2 Service modeling Improved communication of requirement/specification

2 Process modeling Process-driven Service identification

2 Asset management Stage 1 Service to Artifact dependency management Governance compliance recording



3 Registry Stage 2 Versioning

Consumer notifications

External publication and discovery

3 Metadata-based approach Consistency across service lifecycle

Automation of service lifecycle

3 Asset management Stage 2 Populated existing assets, comprehensive service lifecycle governance and change impact analysis

3 Tool-Independent Policy Management Consistency across lifecycle, services and usage

Organization Level

Capability Enabling

1 Cross organization SOA coordination committee Consensus development of policy, standards,, practices and shareable services

1 EA organization with SOA remit Enterprise level standards and policy development

1 Coordinated cross organizational learning Effectiveness of educational activity

1 Centralization of integration Rationalization of existing EAI contracts; governance over integration activity, transformation to services

1 Governance review RAEW Effective compliance checking

2 Appointment of SOA-specific roles Assignment of responsibility and ownership

2 Ownership of service separated from solution ownership Shared services

2 Business analyst/architect function have responsibility for short and long term demand for business process change

Services in advance

2 Organizational separation of provider and solution delivery Specialization of skills for core business services, governance of encapsulation, Role consolidation, solution developers code to the service specification

2 Organizational separation of resource and service ownership Service Provisioning

2 Different reward mechanisms for solution and shared service developers

Improved productivity

2 Experiment with organizational alternatives to traditional project organization.

3 Transform IT organization into primary service-oriented roles and responsibilities.

Align the structure of the development organization to service-oriented thinking

Process Level

Capability Enabling

1 Existing architecture rationalization & transformation process Phased adoption

1 Basic knowledge management & social networking Shared learning and communication

1 Business process driven approach to Service Identification Limited reuse benefits

1 Basic training Skills


2 Train-the-trainers Expansion of skills

2 Mentoring & coaching Customization of skills

2 Service Portfolio Planning methodology Repeatable process

2 Long & short term supply/demand process Services in advance

2 Governance compliance process Stage 1 Reviews

2 Defined business requirements for flexibility Architectural response to change

2 SOA Project profiles Repeatability

2 Slipstream projects Project dependency at component and service level

2 Outsourcing based on rich service specifications Greater separation between provider and consumer

2 Defined Service Lifecycle Governance over state change

Compliance testing relative to state

3 Formalized knowledge management and best practice More efficient and effective dissemination of best practice and organizational learning

3 Advanced training Deepening skills

3 Governance compliance process Stage 2 Automated checking of usage

3 BPO integrated using SOA

3 Managed process variation Ability to handle a broad range of non-standard projects and other activities.

4 Process Innovation Continual process improvement and organizational learning

Projects Level

Capability Enabling

1 Proof of concept Business case

2 Key shared services 360 degree services

2 Technical gateway or bus projects Technical integration

2 Portal or service gateway projects General purpose abstraction layer

2 Separation of application and process assembly projects Greater opportunity for independent evolution of process and applications

2 Enterprise Application service integration Reuse of acquired commodity services

2 Service Enablement Projects Harvesting existing systems to be used as Underlying Services, loose technology coupling

2 Domain service projects Realignment of conventional project scope to deliver shared services

3 Collaborative projects Have more than one organization collaborating

3 Commodity services support context areas of business Cost optimization

3 Customized services support core business areas Better focus of IT spend to support mission critical and innovation activity

4 Slipstream project organization Multiple concurrent projects with smaller scope, Component and service level project dependency,

Table 2:�CBDI�SOA�Maturity�Model

1�� cbdi journal�©�CBDI�Forum�Limited,�December�2005


cbdi journal�©�CBDI�Forum�Limited,�December�2005� 1�

Figure 5:�Capability�Dependency�Diagram


each level in order to be successful in delivering a certain class of service and solution support.

In his Blog7, Richard Veryard suggests – “Part of the problem is a failure to understand the difference between a maturity model and a roadmap. While a roadmap is (or at least should be) a practical template plan, based on a consolidation of experience from many organizations, a maturity model is a more theoretically grounded framework, based on a logical analysis of capabilities and their dependencies. The essential tone of a roadmap is supportive, helpful. It gives you permission to tackle things in a manageable sequence. Start here, it says, and feel free to defer these more advanced matters until later.”

As discussed the CBDI model, shown in Table 2, is not intended to be complete, it is a starting point for development and we welcome comments and feedback on this.

Dependency AnalysisAs discussed earlier the key to creating a balanced roadmap is to ensure the building blocks of capability are put in place in an orderly manner that ensures that at any stage the entire organization is in a state of readiness to deliver on a certain class of requirements.

A useful technique here is to use dependency analysis to understand the relationship between the capabilities. In Figure 5 we present an example of the dependency analysis technique showing how the development of service based business models and business processes can be traced back to several core capabilities that underpin the integrated business service capability. This includes the need to understand the existing architecture, and indeed to recover some aspects of this for inclusion in the SOA.

Roadmap ScenariosIt’s clear that a good maturity model will support a wide variety of scenarios. CMMI is actually a good example – it’s designed to provide status assessments and measurements, NOT as a one size fits all process.

It is also important to differentiate between a maturity model and a roadmap. The maturity model is the generalized view of the endpoint vision together with an assessment of how capabilities need to evolve over time to support that endpoint vision. The maturity model is likely to be more widely useful in its general form. The roadmap in contrast is an enterprise specific device which is derived by assessing what a specific organization needs to do to move towards the mature state. We use the term roadmap because at this level of planning we are working with pretty coarse

grained things, and the term roadmap seems to adequately represent the directional nature of the plan, which will be subject to many twists and turns along the way, all the while keeping the overall destination in sight.

The following scenarios are certainly not exhaustive, but they are intended to show how the maturity model map to the roadmap perspective.

1. Strategic Enterprise initiativeCharacteristics:

• Organization prepared and able to commit to enterprise wide program.

• Early development of Service Portfolio Plan provides basis for coordination of policy

• Allows more rapid move into formal adoption

• Strongly data centric – establishing core business services that manage consistent data and business logic across the organization. Platform for rationalization of data management and business processes

Maturity Model Level Roadmap Phase

Early Learning Early Learning

Integration Integration

Reengineering Reengineering

Cultural Integration Cultural Integration

2. IT TransformationCharacteristics:

• Componentization of the existing portfolio as a means to improve response to business requirements

• Interface with business largely unchanged in early stages, focus on business needs for standardization and flexibility at business process level.

• Alignment of business model addressed only when componentization and service publishing process largely complete

• Strongly data centric – establishing core business services that manage consistent data and business logic across the organization. Platform for rationalization of data management

�Veryard�Soapbox�on�Maturity�Models.�http://www.veryard.com/so/2005/11/soa-maturity-models.htm



3. Project based developmentCharacteristics:

• LOB focused

• SOA is embraced by individual projects – can deliver better structure and reuse within a large project. Need to undertake broader domain analysis if the services are to be useful more broadly. However unless the project is large and has it’s own self contained organization, there is likely to be a lack of cross organizational commitment, which will mean shared services will not be widely accepted because the required support structures are not in place to allow others to depend on them.

• May be strongly process driven, in which case rationalization of data will need to be addressed at messaging and schema level

4. Product developmentCharacteristics:

• Self contained services, providing complete support organization in which the raison d’etre is to create services and support mechanisms that make it really easy for others to use them.

• Strong business involvement

• May be strongly domain centric, in which data and processes are tightly coupled and under control of the product development team

• Shared infrastructure

5. Managed EcosystemCharacteristics:

• Government departments, Supply chains with dominant partner,

• Shared policy, potentially shared support infrastructure – government depts

• Strong focus on funding, shared benefits, schema and policy alignment in early stages

6. Loose EcosystemCharacteristics:

• Collaborating companies

• Supply chains

• Information networks

• Strong focus on interface and schema alignment in early stage, plus selected policies that relate support and QoS



Integration Reengineering

Reengineering Cultural Integration

Cultural Integration Customer Transformation



Integration Alignment

Reengineering Common process




Integration Project Reuse

Reengineering Inter-Project Collaboration

Cultural Integration Common process

Componentization

Reengineering

Cultural Integration



Integration Alignment

Reengineering Process integration

Cultural Integration Business model optimization



Integration Integration

Reengineering Componentization Reengineering



7. Key servicesCharacteristics:

• Very similar to product development – however may not necessarily have same level of business involvement, which will require strong IT sponsorship

• For example core business services such as �60˚ view of customer or product; utility services such as rules service.

SummaryThe maturity model is a general view of how to undergo transformation to a mature SOA environment based on process capability. We found the various reviewed models helpful, but conclude that even through they have all adopted the basic CMMI level structure, they don’t illustrate a capability based viewpoint. Rather they mostly take a somewhat narrow view, which reflects the perspective of the originator.

A generalized maturity model is a framework which can be used to develop a company specific maturity model and then a company specific roadmap. A roadmap that has been developed from a well thought out maturity model will resolve the key dependencies that are essential to manage organizational change and maturity in a coordinated manner.

More worryingly the converse is true – that without a well defined maturity capability model an organization will probably make inappropriate investments that may compromise the integrity and trust relationship with its customers.

We believe the maturity model is an essential communication tool. We observe many, if not most organizations are finding it difficult to move to enterprise level adoption, even though they know the default – LOB or project, option is at best sub-optimal. The maturity model will help to communicate the lack of alignment between organizational units and to show what needs to be done to deliver solid SOA capability.

CBDI doesn’t claim to have thought through all the capabilities and dependencies. We plan to continue extending this model and in particular to develop the capability dependency viewpoint to assist our members in improving their change management. We welcome feedback and input and will continue to report on this topic area. We have made the point that some of the reviewed models have particular perspectives and we envisage that plug in models would be a good extension and development strategy and will be pleased to get feedback in this area.



Integration Componentization

Reengineering Integration



Market Trends Report

by david Sprott

Directions and Diversions

As we rapidly approach the end of 2005 it’s a good time to take stock and consider where the world is heading in 2006 and beyond. We look past the infrastructural issues to the next major phase of activity as the industry moves to commoditize and deliver application and content services.

IntroductionYou would be forgiven for thinking that 2006 has been the year of SOA. It’s been hard to avoid. The vendors have certainly been putting their money into the SOA marketing bucket, yet there’s few organizations that will say they are fully mature in their use of SOA. So what is going on?

SOA ContextIn this relatively early stage of adoption enterprises have not modified their funding and budgeting practices and are simply adopting SOA as an extension to regular project activity. We have seen many examples of duplicated project specific infrastructure, data and service models. There is little thinking about policy yet. While this approach will bring some benefits – of better project structure and maintainability, it is unlikely to evolve to more widely shared services. We again make the analogy that you don’t evolve a city plan from block level to precinct to the entire city.

Consequently this year has been a period in which many enterprises have been adopting SOA technologies and architecture in a predominantly ad hoc fashion. While there are organizations that are taking a strategic enterprise view, most have been in an early learning phase.

What’s rather strange is that most of the vendors promoting SOA have been encouraging this project based approach. In our article this month on SOA Maturity Models, we report on a worrying trend by significant vendors who are advising their customers to delay thinking about enterprise level SOA. We conclude that the vendors find it too hard to change their customers’ buying behaviors and are taking the line of least resistance by aligning with existing organizational practices. The fact that this potentially compromises investments is unfortunate.

Not surprisingly this commercial behavior reflects what the vendors have to sell. As shown in Figure �, SOA platform and tool capabilities are going to take some considerable time to mature. Right now vendors have infrastructure and tools to sell. So rather then be good citizens and advise enterprises to establish a common shared infrastructure (I think that’s a fundamental part of an SOA) they are perfectly happy to sell the same product to all the customer’s projects.

This situation will change in 2006/7. The platforms and tools will gradually mature. Larger vendors will see strategic sales as being more and more important and


will have the integrated platforms to deliver on the broader SOA vision.

Major PlayersSOA is a transformational trend. It will change enterprise organizations and buying patterns. CIOs who can think longer term than 6 months get very interested in SOA when they realize they can make serious inroads in their cost base and deliver higher quality faster to their business customers.

It will also change the shape of the market by putting more power in the hands of the vendors that can deliver integrated enterprise level capabilities – at both infrastructure and application levels. Conceptually SOA might better facilitate best of breed strategies, but this is unlikely to happen on a broad scale. Enterprises want to simplify vendor support arrangements and will use SOA as a mechanism to rationalize, collaborate and customize, rather than mix and match. Vendors

of course will deliver products that enable this strategy and the long term trend of stack consolidation and reduction in number of serious vendors will continue apace.

While all the talk right now is about infrastructure, the really serious SOA adoption will only start to happen as the enterprise application vendors get their act together.

In our opinion SOA makes enterprise applications increasingly viable business platforms because it allows higher levels of customization and adaptation within a standard framework. We envisage (and are advising in our methodology) that all enterprises will adopt commodity services for the 80% of their business that is essentially undifferentiated. For the remaining 20% SOA can be highly effective in either customizing commodity services or creating a collaborative architecture with custom or third party services. This will make it increasingly important to understand what the major enterprise application providers are doing.

Figure 1: Market�Maturity�Model

20 CBDI Journal © CBDI Forum Limited, December 2005

The SOA Maturity Model continued . . .Directions and Diversions continued . . .

SAPThe original SAP ESA announcements suggested that moving SAP to SOA was a profound shift to componentization – that would break up the monolithic ERP application and allow enterprises to pick and choose. The SAP share price dropped as analysts saw a long term threat to SAP’s revenue as their customer base implemented components from multiple vendors.

This announcement was way off the mark.

The ESA is essentially a shell surrounding the existing applications. The ESA will allow greater flexibility in deployment of SAP modules and business process design. Also we presume easier upgrade as product dependencies will be managed largely by service interfaces (yet to be fully validated). Customers will be able to resolve application integration issues more easily using service interfaces. However the underlying application structure is largely unchanged. Eventually SAP may reengineer the underlying core, but this will be a long term process. SAP has been trying to componentize the base modules for years, and has largely failed because of the huge complexity. A SAP customer may choose to introduce new components and will potentially be able to introduce them more easily as the interface structure will be markedly improved beyond the existing (proprietary) BAPI structure, however the customer will almost certainly need all of the SAP components they required previously because of intra (SAP) application dependencies which we anticipate will be largely unresolved.

The primary change with ESA will be the increasing influence of the business process design and specification. The SAP environment will be driven by integrating business process design in a new range of tools that will provide good end to end value chain support. There will be strong motivation to use the SAP business process design tools, and not to compromise these by integrating with other tools environments.

SAP is also increasing it’s coverage of the application stack to include middleware. The Netweaver product directly competes with IBM, BEA, Microsoft et al. SAP insists that Netweaver will be fully interoperable with other leading SOA infrastructure products, a claim that’s not substantiated right now in terms of Java extension support. However it’s reasonable to expect that SAP will provide full interop with other leading platforms at a protocol level. There are two issue areas for customers:

a) the vertical (inter stack layer) relationships between the SOA middleware, BPM and management infrastructure will be tightly integrated on all platforms (not just SAP). To get the maximum flexibility at the point of delivery to the business process, there will be a very strong incentive to keep a homogeneous environment. So over time all the vendors are pushing to increase stack integration.

b) the horizontal relationships between disparate ESB and infrastructure products will require coordination of policy (SLA, management, exceptions etc) which will introduce a significant level of complexity. While management protocols (WSDM etc) are being standardized, (this work is proceeding very slowly)

there is strong political pressure from the major vendors to protect their interests.

CBDI expects that enterprise customers will increasingly choose to reduce the number of enterprise application vendors. The increased flexibility of the SOA and BPM based applications will make the application products increasingly undifferentiated and standardized. CBDI is advising its customers that the key issue for

enterprises is to decide where it’s processes need to be standardized

and where they need to be differentiated and to establish architectural solutions that deliver this. Differentiation (or customization) can be enabled using SOA techniques by:

a) wrapping packaged services in specializing layers. This is sometimes referred to as Composite applications, although a better way to think about this is as a fractal architecture.

b) custom build (or alternative supply components). However this approach is situation specific, and it is very hard to generalize. When we know more about SAP ESA is may be possible to provide generalized advice.

Bottom line: SAP ESA brings benefits but it is not going to markedly open up the environment to create a heterogeneous application environment as was called out in the original ESA announcement. In fact the exact opposite will happen, while the technology architecture will allow easier inter-connectivity, the integration at platform and business process level will persuade customers that a largely homogeneous environment is in their best interests. SAP will of course also be quick to point out that having clarity of vendor support is a major advantage also.

enterprises is to decide where it’s

CIOs who can think longer term than 6 months get very interested in SOA when they realize they can make serious inroads in their cost

base and deliver higher quality faster to their business customers.


Final comment ESA is very new. One of our customers has sight of the initial release of services and is reasonably happy with the outline, but there are MANY questions that remain unanswered. This is a long term project for SAP and it’s going to be a slow transition for their customers.

OracleIf you think the SAP position is confusing – you ain’t seen nothing yet! Driven by huge application acquisition issues (JD Edwards, Peoplesoft, Siebel . . .) Oracle is adopting SOA under the umbrella Project Fusion� as a core strategy to integrate and rationalize the acquired portfolios.

For the past year the primary external focus for Oracle has been on establishing their operational infrastructure as a direct response to SAP’s Netweaver platform. The string of acquisitions include:

• Collaxa, for web service orchestration

• Oblix for identity and access management, as well as policy management

• Thor Technologies, a provider of identity and access management solutions.

• OctetString, a provider of virtual directory software

While an SOA is supposed to be a federation of service capabilities, it’s stretching credibility to imagine that this collection of disparate products will easily develop into a coherent architecture where there is a common approach to specification tools, policies and console operation. Even the vendor friendly commentators have been making comments such as the SOA equivalent of Frankenstein!

Oracle’s response to this has been to emphasize the open architecture they will employ moving forward, but from a company with a strong history of not partnering, it sounds suspiciously like a holding strategy. Oracle has come late to a party where there has been serious investments over the last five years, and it will take more than marketing hype to compete directly with IBM, SAP, CA and to deliver the point and integration capabilities developed by the likes of Cape Clear, Amberpoint and Actional.

However while the operational infrastructure is in some disarray, the delivery infrastructure (tools) is in much better shape, as Oracle had a reasonably competent set of Java based tools that will be core to the SOA effort. Compared to SAP this should be seen as a significant advantage.

However this flurry of operational and delivery infrastructure activity is merely the prelude to the main event, which will be focused on using SOA to migrate its acquired customers onto a merged (Fusion) platform. First it must be said that, like SAP, there is very little real information available. However from the mess of public information it seems that Oracle is very strongly mirroring the SAP strategy, with a heavy emphasis on business process driven applications and automation. Also Oracle is moving towards what it calls data hubs – in which core data subject services are available to all processes. What is less clear is the place of the data hub in the SOA and it’s ability to support genuine �600 services. We anticipate that the data hubs eventually be similar to SAP’s Master Data Management, forming a stable core business service layer, which can support many variations of process behavior.

We wait with interest to see more details and plan to report in depth as the strategies develop into products.

MicrosoftIt must have been three years ago when I met with one of the Microsoft applications architects and we were discussing how SOA approaches would allow Microsoft to rationalize the disparate base they acquired from Great Plains and Navision. However events tell us that this has been a troubled area for Microsoft and they have failed to grasp the nettle and rationalize these products.

Earlier this year it was reported that Microsoft Corp. is slowing down development work on the new family of its business applications known as “Project Green” and was instead focusing on the current products. The report indicated that because the first new products would not be shipped until 2008 at the earliest, the number of developers assigned to Project Green was being reduced from 200 to 70. Microsoft Senior Vice President Doug Burgum said “. . . Microsoft originally had planned to ship the first results of Project Green as early as late 2004. We have made a decision to move resources off Green and back on the core product lines to strengthen those product lines because we realize now that it is going to take much longer.”2

Microsoft evidently now plans to build completely new business applications on a single code base that will eventually replace its existing offerings, which of course will be based on the Longhorn code base, shipping in 2008.

1CBDI�News�Report:�1�th�January�2005,�Oracle�Outlines�Converged�Future�With�Project�Fusion.�http://www.cbdiforum.com/public/news/index.php3?id=1�33�2This�information�was�put�into�the�public�domain�when�Burgum�told�a�federal�court�in�testimony�in�the�U.S.�Department�of�Justice’s�case�to�block�Oracle�Corp.’s�takeover�of�PeopleSoft�Inc.


The SOA Maturity Model continued . . .Directions and Diversions continued . . .

Microsoft, Google, Yahoo etcBut while the Microsoft applications SOA strategy seems to be moribund, there are other significant moves in the area of software as a service. Very recently we heard that an internal Microsoft email has been leaked to the media�. Bill Gates has once again written to all Microsoft staff to exhort them to redirect their energies to focus on Internet Software Services.

I look back in the archives and see it was in March 200� I wrote pretty scathingly about Microsoft’s Hailstorm program4. Remember Hailstorm – infrastructure services including identify, address, profile and authentication that were to be provided by a single supplier – Microsoft, together with a developer platform called MyServices that was designed to stimulate an entire market of application, content and consumer oriented Web Services. Of course the Hailstorm program crashed and burnt – in the face of overwhelming hostility based on lack of trust in Microsoft. So what’s changed four and a half years on?

We’ll actually not much in the core of Microsoft’s new product plans. The ambition is remarkably similar, albeit a lot broader encompassing Web Service enablement of what looks like the entire range of Microsoft products ranging from platforms and tools to the Xbox. What has changed is that Microsoft is supposedly facing stiff challenges from unconventional quarters and just as with previous 90 degree turns at Redmond on the Internet and Security, external pressure is causing the software giant to respond – late as usual.

Let’s examine that competition. Google is a very rich company, doubling its revenues year on year. They have a great search engine. Right now their product line includes software for searching personal computer files; an e-mail service; maps; satellite images; instant messaging; blogging tools; a service for posting and sharing digital photos; and specialized searches for news, video, shopping and local information. This is way beyond the basic search engine, but it’s a million miles away from platforms and developer tools. What is going on is a clever marketing campaign of leaks.

Wal-Mart is supposedly worried because by making information available everywhere, Google might soon be able to tell Wal-Mart shoppers if better bargains are available nearby. Similar disruptive presence is forecast in real estate and auto sales. In telecommunications, the company has made a number of moves that have grabbed the attention of industry executives. Recent purchases of fiber-optic cable

capacity in the United States and high-speed Internet access over power lines has sparked (sic) rumours of a national (US domestic) free GoogleNet paid for by advertising. Telecommunications executives are skeptical that Google could seriously eat into their business anytime soon. Still, they are said to monitor Google’s every move.

It is clearly in Google’s interests to keep the market speculating, but it’s plain that their core business is search – they will keep building off that and focusing on their core mission to “organize the world’s information and make it universally accessible and useful.” We should expect Google to use that core platform to get involved in transactions – because it’s in leveraged transactions that advertising demand is maximized.

As for Microsoft it pays them to seem to be running scared of Google and co. Microsoft strategists will assess they are entering a period when they are:

�. no longer public enemy numero uno!

2. they have pretty much cracked the security problems and

�. they need to be focused on Web 2.0 or Internet 2 whatever you want to call it

So hey guys, go and dust off those plans for MyServices, our customers all have broadband now and the timing is great. Let’s get the developer community energized. Let’s leak an internal Bill memo so that we can get everyone focused on the search engine competition, and on pain of death don’t mention the code word Hailstorm.

No one talks about trust – it seems Microsoft has been rehabilitated. They have successfully diverted attention and become the underdog. The media commentary is all about can they survive? Will Google and Yahoo trample them into the ground? That suits them very well!

Concluding ThoughtsIn 2006/7 we are entering a new phase of the SOA market. The infrastructure and standards are not complete but they are good enough. Now we will start to see real value as the content providers deliver commodity services which will allow enterprises to adopt more flexible architectures with lower levels of constraint at the business process level.

This is not going to happen overnight, but the writing’s on the wall.

3http://www.scripting.com/disruption/mail.html�CBDI�Commentary:�21st�March�2001�–�Commentary:�Insight�on�Microsoft’s�HAILSTORM.�http://www.cbdiforum.com/public/news/index.php3?id=5�0

Best Practice Report


SOA in the Public Sector

Many governments are very active in adopting SOA. This is because SOA may address some of the major issues that governments face, particularly the complexities of highly federated organizations that need to present a coherent business process face to their citizens and businesses. In this report, we review the opportunities and challenges.

Introduction

What makes the public sector different?Traditionally, public sector services have been subject to some different requirements as compared to commercial services. However, some of these differences may be being eroded by SOA, and commercial services will increasingly take on the characteristics of public sector services, and vice versa. (This potentially means that public sector organizations may be further advanced in some aspects of SOA than most commercial organizations.) For example …

� Public services are typically expected to be either universal or selective by need. Commercial organizations will often choose to refuse customers with special needs, high risks and/or low returns, but a government organization (or regulated monopoly) is often required to pay special attention to service users with these characteristics.

However, there is a growing strategic agenda for commercial organizations to pay attention to the so-called Long Tail. These are low-value, infrequent customers, which many commercial organizations have traditionally ignored, but which governments have always had to satisfy.

2 As a consequence of (�), electronic services must be provided with a complete set of user interfaces, providing access to citizens with disabilities, as well as versions in minority languages. This generally forces a strong decoupling between the user interface and the underlying capabilities.

Decoupling between the UI and the underlying capabilities is a widely adopted and generally approved architectural style. However, governments have traditionally been forced to exercise this kind of flexibility much more rigorously than commercial organizations, and so we should be able to have higher confidence in the robustness of their decoupled architectures.

� The public sector does not have a general mandate to compete with the commercial sector, although there may be specific mandates in some areas for some duplication or overlap. The general preference is to define a reasonably clear boundary between the public sector and the private sector, and to encourage the private sector to provide services that interoperate with the public sector services. For example, public tax collection services may interoperate with commercial tax calculation software.

An important aspect of SOA portfolio planning is to define the services that you are NOT going to provide, and to identify and support independent suppliers to provide these services to your customers in a way that is maximally aligned to your own services. Besides governments, this is reasonably well understood by the large IT vendors, which typically have partner programmes designed to create a healthy service ecosystem.

by Richard Veryard


SOA in the Public Sector continued . . .

Benefits

Within government improved business process coordination

improved collaboration among government agencies on a wide range of policies and practices that potential to establish greater consistency and repeatability,

shared infrastructure and business services have potential to decrease overall spending

greater flexibility and faster response to implement legislative change

With other governments

larger and tighter collaboration to help facilitate the work with other regional administrations

greater flexibility to rationalize central and local (federal and state) government business processes

opportunity to align key data between administrations

Services to citizens converged inter departmental view allows single point of contact with local administration

choice of channels for accessing services

extended seamless services

Process improvement

accelerate the implementation of procedures

creation of homogenous file processing systems

roll-out of flexible processing workflows

Table 1: Technical�Uses�of�SOA�within�Government

SOA Feature / Opportunity Benefit

Shared services – Services can be shared between many consuming departments and agencies.

Efficiency Shared services potentially generate economies of scale – especially if these services are properly architected.

Typical opportunities for very significant cost savings include security, infrastructure, case handling and document management.

Architecturally articulated services – enable faster response to change at lower cost

Competition / deregulation. Opening up inbound service provision (B2G, with positive effects on B2B and B2C), and requiring service providers to expose unbundled services for external consumption.

Adaptability

Exposed, composable services – allow common services to be used by multiple departments with appropriate specialization for departmental use

Citizen Value

Joined-up government – new channels linking, and new points of connection between, the many different elements of government: from policy-making through operations to service provision

Government transformation – aligning the structure of Government to the structure of the demand for services

Table 2: Potential�Benefits�of�SOA�to�Government


Current EmphasisMuch of the current SOA effort within government organizations is focused on effective communications, data sharing and the creation of agreed XML schemata. While this is undoubtedly a vital element of eGovernment SOA, it is far from being the whole story, as we shall see below.

Interoperability

BreadthThere are two dimensions of interoperability that can be (and often are) pursued independently – breadth and depth. Breadth refers to the (organizational) scope of interoperability. eGovernment often addresses intra-departmental aspects of integration and interoperability, before tackling inter-departmental or inter-governmental aspects. Broader still are questions of interoperability with non-governmental organizations, including the commercial and voluntary sector. In some cases, as we have seen, government agencies need to collaborate with non-governmental bodies to deliver composite services to citizens.

While there are some obvious short-term organizational advantages in tackling intra-departmental SOA before going broader, the risk is that this may simply reinforce the existing functional silos within Government (especially the larger departments), and make future interoperability across Government more difficult.

DepthMeanwhile, there are different types of interoperability that imply different levels of capability. Some sources define interoperability simply in terms of the ability to communicate and share data, while others define interoperability in terms of consistent use of the data. Simply sharing technical protocols and syntax is a relatively shallow form of interoperability, while sharing semantics is deeper (and perhaps harder). Many SOA initiatives have focused on achieving broad but relatively shallow interoperability, agreeing protocols and schemata across a wide community of interest within and beyond the public sector.

• Common technical protocols

• Common data model / XML schema / semantics (document-level integration)

• Shared data

• Shared identity

• Unified user interface

• Inter dept process model

• Common process model

Box 2: Depth�of�Interoperability

While this is of course relevant to all kinds of organization, not just to the public sector, it forms the basis for a thoughtful critique of some key government initiatives – especially to the extent that many government initiatives (as well as vendor initiatives directed at eGovernment) are specifically focused on XML schemata.� Governments rightly take a leadership position in the formulation of many relevant interoperability standards, but this is clearly not the whole story.

As a contrast, we can mention the Irish government’s Public Sector Broker initiative, which is an integrated set of electronic processes, systems and procedures based on a service-oriented architecture (SOA) approach to e-government infrastructure. This kind of initiative can be regarded as being at a higher level of SOA maturity than simple XML.

Problems

Planned interoperability between new systems is often scaled back in order to maintain compatibility with older systems that cannot be upgraded without major rework.

Strict specification of standards proves insufficient for achieving desired levels of interoperability, because organizations constructing “compliant” systems interpret specifications in different ways, thus creating different variants of the links.

Policies promote a single point of view at the expense of other points of view. For example, policies that enhance the levels of interoperability that can be achieved in one domain are generalized to additional domains, where they unduly constrain organizations trying to produce interoperable systems.

Funding and control structures within the DoD are not providing the incentives necessary to achieve interoperability. For example, even though there is increased emphasis on the joint nature of many systems, funding for most programs still flows through service sponsors.

Tests constructed to verify interoperability frequently fail to identify interoperability shortfalls. In other cases, systems are approved for release in spite of failing interoperability tests.

Even when interoperability is achieved by systems of systems, it is difficult to maintain as new versions of constituent systems are released. New system versions frequently break interoperability.

Box 1: Interoperability Problems (source: SEI)

�See�for�example�http://europa.eu.int/idabc/en/document/31�8/35�



Although maturity is often defined in terms of both breadth and depth, it is worth noting that there is an important difference in terms of SOA capability. Increasing breadth generally involves scaling up a given SOA capability, but increasing depth involves introducing new types of SOA capability.

Enterprise ArchitectureTo achieve interoperability across a large and complex federation of public sector organizations, we need some formality in defining the federation, together with multiple levels of enterprise architecture (departmental and public sector), showing different potential levels of sharing. Large sectors (such as Health and Transport) themselves typically involve multiple organizations.

TrustBreadth and depth both involve questions of trust. Interoperability requires trust; successful interoperation (especially if it involves deeper levels of interoperability) builds trust. So a roadmap for eGovernment needs to consider this carefully.

Typically, there is a trust gradient, which depends on your

position and perspective. For example, from a central government perspective, other central government departments may be trusted more than local government. Voluntary agencies may be trusted to have the right intentions, but there may be concerns about their levels of capability and security. Commercial organizations may be perceived as having stronger capabilities, but there may be concerns about their commercial agenda. And of course where the service ecosystem extends outside the geographic jurisdiction, there will be additional concerns about privacy and liability.

What this means is that services may need to be planned from the outset to support different levels of trust and security. For example, where a government epayment service covers everything from parking tickets (probably outsourced) to corporate tax (definitely not outsourced), the service may need to allow for different levels of authentication and confidentiality as appropriate for different contexts.

Thus, like any federation, governments will be dealing with varying levels of security and trust. This makes identity management and security a particular issue that needs to be addressed early in the SOA roadmap

Figure 1: Joined-Up�Services


Shared ServicesShared services provide public service organizations with the opportunity to reduce waste and inefficiency by re-using assets and sharing investments with others.

There are many shared services initiatives in the public sector that are not directly IT-related, and may therefore be considered outside the scope of SOA. Many such initiatives involve things like collective procurement and consolidated provision. Often the primary economic benefit for the agencies using such shared services is in improved negotiations with suppliers, and the shared use of physical and human resources. However, even in these areas, there is still some potential value in linking the administration and governance of these services into a shared SOA framework.

Organizational Models for Shared ServicesA shared service cooperative is a user-side initiative to provision and manage services cooperatively, which generally provides cost savings and other benefits, to be shared between the participants. This approach is widely

used for cooperative purchasing and logistics, and this kind of cooperative sharing is often practised between local governments. Federated sharing is practised by central governments, for such functions as HR and finance.

Citizen-Centric“Services enabled by IT must be designed around the citizen or business, not the provider, and provided through modern, co-ordinated delivery channels. This will improve the customer experience, achieve better policy outcomes, reduce paperwork burdens and improve efficiency by reducing duplication and routine processing, leveraging delivery capacity and streamlining processes.” Source: UK Government, Transformational Government Enabled by Technology

What does it mean for services to be “designed around the citizen”? Consider a student who is applying for one or more university places, and also applying for a student loan. From the student’s perspective, it would be reasonable to regard these as connected instances of APPLICATION, with some important links between them. For example, it may

Figure 2: Multi-Level�Enterprise�Architecture

28 CBDI Journal © CBDI Forum Limited, December 2005


make sense for the student to synchronize the acceptance of a university place with the acceptance of the associated student loan.

But from the service provider’s point of view, we may anticipate considerable difficulties in delivering a seamless service to this student. For a start, the services are provided by several different agencies including the universities themselves, which are usually autonomous institutions. A student may wish to apply to more than one type of course or institution (such as medical school versus drama school), possibly in more than one jurisdiction, which may be subject to different loans from different funding bodies.

Public bodies often operate policies that are intended to simplify service provision, but have the effect of complicating matters for the citizen – especially if she wants to do anything out of the ordinary. For example, let’s imagine that the student loans body offers several different types of loan for different types of course, but only allows you to apply for one loan at a time. And let’s imagine that the student doesn’t always know for certain what type of course she is going to be able

to do. So the student is forced to take a risk – either applying prematurely for a loan, or accepting a course without having the finances in place.

Obviously the details vary from one jurisdiction to another, but the experience of having to do things in an inefficient

and sometimes uncertain way – because the services have been optimized purely for the convenience and efficiency and security of the service provider – is an almost universal one.

And we may note that the provider-centric optimization of services isn’t always very clever either. Consumers and citizens are often prevented from doing anything out of the ordinary because the service providers are afraid that this might lead to inefficiency or fraud. But often these constraints merely cause unnecessary inconvenience for honest citizens – since the

electronic processing cost of extra applications is trivial, and

since modern real-time systems should be able to detect duplicate applications downstream, it really doesn’t seem necessary to prevent a citizen having multiple applications in a pre-acceptance state – while being generally ineffective against determined fraudsters.

Style Advantages Issues

Internal sharing – sharing services within a single large department or agency

“For the very largest organizations the first challenge would be to create a shared service capability within their own boundaries, before considering downstream whether further advantage can be gained from joining with others.”

Dealing with internal interoperability first, which leaves unaddressed the (potentially larger) architectural risks of external interoperability.

Federated sharing – sharing services between multiple departments or agencies, based on some common “joined-up” view.

Only as flexible as the common view on which it is based.

Agreeing a common view that supports sufficient variety.

Cooperative sharing – sharing services between small independent organizations (possibly public, private and voluntary), operating as a club.

Highly flexible. Participants can usually opt-in or opt-out on their own terms.

Can suffer from a lack of leadership. Excessive opt-outs may result in loss of critical mass.

Table 3: Organizational Models of Shared Services

To achieve interoperability across a large and complex federation

of public sector organizations, we need some formality in defining the federation, together with multiple levels of enterprise architecture

(departmental and public sector), showing different potential levels of

sharing.


So the citizen-centric approach leads naturally to a notion of joined-up government from the citizen’s perspective – the one-stop shop. We shall discuss this in the following section.

From One-Stop Shop …If instead of analysing processes from the government’s perspective, we analyse them from a citizen’s perspective, we can identify opportunities for linking eGovernment services in innovative ways. For example:

• One stop shop for citizens that provides integrated view of health, social services, tax and disability resources. For example providing integrated support for a disabled senior citizen requiring state funding for wheelchair or home help support.

• Or the various integrated processes to arrange and manage maternity leave provision, or special needs assistance, or child care etc covering the needs of all the stakeholders including children, parents, teachers, carers and employers

While such initiatives have obvious benefits for the citizen, they also may deliver improvements in efficiency and effectiveness for the service provider. This is particularly true when isolated services are optimized around the short-term needs perceived by a single agency (for example acute

healthcare), which makes them sub-optimal from a longer-term or broader perspective (for example, chronic long-term healthcare).

… to Government TransformationIn the UK, conflicts between different healthcare organizations are widespread, and much of these can be traced to this cause. The winner of the 2004 “Joined-Up Government” award was a collaboration between hospital and local government to provide more seamless patient experience2. There are many such opportunities to synchronize services between multiple agencies, in order to create win-win improvements to eGovernment services – benefiting service recipient and taxpayer alike.

Because of the ubiquitous departmental organization in governments worldwide, there are many areas in which public sector can benefit from greater integration and data sharing, promoted by web services and SOA.

For example, an SOA law enforcement system has been implemented in Alabama USA, using web services. This system links 22 different data systems to deliver driver’s license photos and integrate arrest records with court records. (There has been a considerable push towards SOA in the American Justice system, supported by the so-called Global Justice Information Sharing Initiative.)

Joined-Up Government

There are several different notions of Joined-Up Government in play.

Technological Focus on the wiring that connects different parts of Government, as well as providing electronic services to the citizen. E-Government. Seen as a cost-saving and efficiency measure.

Accountability Focus on joined-up information and reporting

Policy Focus on formulating and implementing cross-cutting policy.

One-Stop Shop Focus on connecting services from the citizen’s perspective

Holistic Government A combination of joined-up tactics including

• joined-up budgets for areas, client groups and problems;

• joined-up policy-making;

• joined-up data management, standards, and use of digital signatures; and

joint training of officials and ministers

Box 3: Notions of Joined-Up Government

2http://society.guardian.co.uk/publicservicesawards/story/0,1��5,135��02,00.html



Holistic IntelligenceShared data can be used to spot patterns in an individual’s or an organization’s behavior or circumstances that may not be evident, unless looked at in a holistic way. For example, it can be used to identify children at risk or undergoing difficulties because of family, health or other problems. Shared data can help identify fraud, and improve the effectiveness of the enforcement of civil judgments, criminal court fines and breaches of community penalties.

Governance

FundingIn the public sector, it is often much easier to get funding for a single large development project, rather than ongoing operations. Procurement policies often dictate the cheapest solution, and there is no opportunity for overrun. Furthermore projects tend to be departmental in nature. These characteristics of public sector funding can be problematic for SOA in the public sector for three reasons. Firstly, it creates a preference for large monolithic projects, which is not ideal from an SOA point of view. Secondly, the ongoing operation and maintenance of services may not be properly funded, unless there is a specific revenue or cost-saving stream that can be associated with these services. Thirdly sharing of services across departments is harder to organize. SOA portfolio planning for the public sector therefore needs to make sure that the services are not only technically well-designed from an architectural point of view, but also economically sustainable from an organizational point of view.

Distributed LeadershipOne of the challenges of achieving SOA in a public sector context is that of leadership. To achieve anything like the full benefits of SOA, there needs to be strong leadership. But the public sector doesn’t always enjoy the kind of centralized top-down leadership found in many commercial organizations. Many countries have a culture of consensus and collaboration, and so a distributed leadership model is more appropriate, where strong federal policies (tighter than, say, a supply chain) can be developed on a consensus basis, including:

• shared infrastructure

• security

• SLAs

• interoperability standards and profiles

• shared services• semantics

Joined-up government has to be seen as a long term, selective and cooperative project.

• It is long term because people have to acquire new skills, build trust and overcome professional boundaries.

• It is selective because not all problems require joined-up solutions and the skills, which may be in short supply, have to be well directed.

• It is cooperative because it cannot be imposed but requires leadership and commitment.

Box 4: Challenges of Joined-Up Government (source: UK Government)

ConclusionIn the past, public sector organizations have been very different in kind from commercial organizations. But with SOA, we can see some important areas of convergence. Public sector bodies are tackling many of the same issues as commercial organizations; and in some cases they may even be tackling these issues more rigorously and far-sightedly than their commercial counterparts.

Many services can be shared between the public sector and the private sector, and we can expect further synergies to emerge, especially as the large application vendors (such as Oracle and SAP) start to expose their services in a more granular and flexible way. Each government has a dual interest here – both as user of services, and as guardian of a healthy ecosystem for companies within its jurisdiction – and we may therefore expect governments to add to the pressure which large commercial users are already putting on the software vendors.

The UK eGovernment Minister, Jim Murphy, recently stated the UK priorities for government transformation, with a strong emphasis on joined-up government and shared services to produce both cost-savings and citizen-centric services.

“The transformation to which we aspire will only occur if we adopt a new approach to joined-up service delivery across the public sector, one that will break down the silo culture of delivery. Departments that share corporate services such as HR and finance could create 20 per cent efficiency savings. Shared services also mean building more effective links between central Government and local government and the wider public sector,”4

3http://www.policyhub.gov.uk/better_policy_making/�http://www.egovmonitor.com/node/315�


References

GeneralSEI Current Perspectives on Interoperability, March 2004

Vernon Bogdanor (ed), Joined-Up Government, OUP 2005.

Governmental

EU IDABC. European eGovernment Services. http://europa.eu.int/idabc/

Denmark http://www.e.gov.dk/english/egovernment/index.html

Ireland Reach. http://www.reach.ie/index.htm

UK Transformational Government: Enabled by Technology.

http://www.cio.gov.uk/transformational_government/index.asp

Whole of Government Accounts http://www.wga.gov.uk/

USA Commission on Systemic Interoperability http://endingthedocumentgame.gov/PDFs/entireReport.pdf

Global Infrastructure Standards Working Group

NASCIO (especially Committee on Interoperability and Integration)

https://www.nascio.org/publications/index.cfm

National Task Force on Interoperability (NTFI) http://www.ojp.usdoj.gov/nij/topics/commtech/ntfi/welcome.html

VendorsBEA

Propylon. A Service-Oriented Approach to eGovernment Architecture. http://idealliance.org/papers/dx_xmle04/papers/02-06-04/02-06-04.html

CBDI ForumRichard Veryard, Joined-Up Services, Review of the Public Management and Policy Association. February 2002. Web version at http://www.veryard.com/government/services.htm

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.

Insight for Web Service & Software Component Practice

issn 1745–1884 journal - cbdi forumeverware-cbdi.com/public/downloads/9yh9a/journal2005-12.pdf ·...

Documents