Planning_and_Impleme.. - didier beck weblog

Technology Management and Strategy Report 

www.butlergroup.com 

Butler Group 

a Datamonitor Company 

Planning and 

Implementing 

SOA 

Ensuring the Successful Deployment of 

a Services-based Approach 

December 2006 

Analysis without compromise



SECTION 1: 

SOA Deployment 

Butler Group 

a Datamonitor Company


Planning and Implementing SOA 

ADOPTION OF SOA BY ENTERPRISES 

CATALYST 

Service Oriented Architecture (SOA) has become one of the latest buzzwords propagated by the IT industry. 

Most enterprises have now heard of SOA – at least to some extent – but how are they responding to it? Adoption 

rates vary enormously across various studies and this Section examines the evidence so far on adoption rates. 

With the promise to deliver flexibility and agility to the enterprise by dramatically cutting development 

times and costs, SOA has become a ‘hot topic’ in enterprise IT departments. The adoption of SOA has 

already become reality for a number of enterprises with the following key trends emerging: 

SUMMARY 

SOA adoption rates vary significantly across enterprises. 

Staffing issues, security concerns, and a lack of awareness of SOA are inhibiting SOA 

adoption. 

Enterprises expect cost savings to come from SOA deployment, though these will be 

in the long term. 

ANALYSIS 

SOA adoption rates vary significantly across enterprises. 

News articles during 2006 have quoted wildly different rates of adoption for SOA, ranging from figures indicating 

some 80% of organisations are working on SOA projects to rather more realistic adoption rates of less than 30%. 

Any new paradigm is bound to take time to get a widespread understanding, and it will often depend on where 

an organisation is currently in its IT adoption as to what their level of interest is in SOA. 

A recent survey of 90 end users in the US and in Western Europe (UK, France and Germany) conducted by 

Datamonitor provides insight into enterprises’ reaction to SOA. Some 30% of the respondents said that they were 

beginning to embrace a SOA infrastructure. Within the survey group, size of organisation also appeared to be an 

important factor on adoption rates. For example, Figure 8.1.1 illustrates that adoption rates in larger 

organisations were significantly higher than in smaller ones. 

Figure 8.1.1: SOA Adoption by Size of Organisation (Source: Datamonitor) 

December 2006 Section 1: SOA Deployment 3



Large organisations tend to have a greater need for integrating applications and services across their 

businesses. They are also more often challenged with unforeseen and changing dynamics created by M&A 

activity, new partnerships, expansion, and new customer requirements. SOA promises to deliver the ability 

to change and modify enterprise processes to match such changes 

As might be expected, 

Technology and 

Financial Services are 

the dominant verticals 

in terms of SOA 

adoption. 

dynamically to business processes and activity. Smaller organisations may 

either be less mature in their usage of technology, or may simply have fewer 

business drivers that are forcing a review of alternatives such as SOA. 

As might be expected, Technology and Financial Services are the dominant 

verticals in terms of SOA adoption. They are heavily dependent on IT and are 

sophisticated in terms of their IT adoption. Enterprises within these verticals 

usually run a large number of applications and their operations are often 

spread across various locations, meaning that the need to integrate processes 

across platforms is a constant priority. They also have large, knowledgeable IT-departments and are 

consequently less inhibited by new technologies. Other verticals, such as Healthcare, Manufacturing, and 

the Public Sector, currently have lower SOA adoption rates, largely due to a more risk-averse approach to 

the adoption of the latest technologies, but also likely to be related to other business drivers taking 

precedence, and a lack of understanding. 

Figure 8.1.2: SOA Adoption by Vertical (Source: Datamonitor) 

Across different regions, the Datamonitor survey backs up discussions with various infrastructure and technology 

vendors that implied that there is little difference in adoption rates, at least between the US and Europe, Middle 

East, and Africa (EMEA) regions. Some 48% of positive respondents were based in the US and 42% in EMEA. 

Vendor discussions imply that adoption rates are marginally higher in the US than in Europe, but most agreed 

that adoption was probably lower than might be expected from the volume of hype that surrounds SOA. 

The Web site eBizQ (www.ebizq.net)– which covers many integration-related issues – published a survey of 

just over 300 of its members in October 2006. This indicated a rather more bullish uptake of SOA, with 

28% of respondents claiming to have some services deployed, with another 21% considering themselves 

to be in the pilot stages. A further 24% are currently exploring SOA. In most cases, of those organisations 

that had deployed some services, there were fewer than ten in production, with Web services being the 

most widely adopted service type; here there were a few respondents that had significantly more than ten 

deployed services with some 10% having more than 100 in use. Again, Financial Services, Telecoms, and 

Technology companies were at the forefront, backing up the Datamonitor findings (some 21 different 

industries were represented in the response group). The main drivers for adoption were increased business 

agility, IT reuse, business process optimisation, and composite application development (multiple responses 

were permitted in the survey). This response did imply that the business was driving much of the adoption. 

4 Section 1: SOA Deployment 

December 2006



Quocirca, a UK-based market research company, paints a rather less rosy picture. In a rather larger sample 

(some 1,500 respondents) that was surveyed in research sponsored by Oracle earlier in 2006, around 30% 

claimed that they did not understand what SOA was. A further 25% said they had minimal knowledge of 

it, and only 20% stated they had a fair understanding or a good working knowledge of what SOA is all 

about. The respondents in this research were a mixture of technical and 

business people, which may explain the low levels of understanding to an 

extent – but the lack of SOA awareness is worrying given that for SOA to be a 

successful strategy, it must have business sponsorship. 

The Quocirca research shows that less than 10% of respondents’ 

organisations already had a SOA infrastructure, and 17% had no plans at all 

to look at one. Nearly 30% saw the move as being too difficult based on their 

existing infrastructure – indicating that where there is understanding, the 

concern is that there will be significant infrastructure requirements. This 

implies that the vendor-centric emphasis of SOA to date is turning people off 

the idea, and there is a limited understanding of the benefits of SOA. 

...research shows that 

less than 10% of 

respondents’ 

organisations already 

had a SOA 

infrastructure, and 

17% had no plans at 

all to look at one. 

A final survey, which has the benefit of indicating changes in responses over time, comes from Evans Data 

Corporation, conducted during the spring of 2006 across almost 400 managers and developers. This was 

focused on Web services development, and indicates that from 2005 to 2006 the percentage of functioning 

SOA implementations has almost doubled. The survey showed that 24% of respondents claim to currently 

implement SOA, an 85% increase over 2005. It also indicated that the number of Web services in use is 

also rising, with 30% of respondents anticipating that they will be using more than 20 services in the next 

year, a 58% increase from today. Performance, especially relating to reliability and availability, was seen as 

a serious concern here. 

Staffing issues, security concerns, and a lack of awareness of SOA are 

inhibiting SOA adoption. 

Given the varied adoption rates across the market, a number of common reasons emerge as to why adoption 

has not taken off in reality as much as some pundits are claiming. 

Figure 8.1.3: Obstacles to SOA Adoption (Source: Datamonitor) 




The Datamonitor survey already mentioned indicated that a lack of technical in-house expertise (27%) is 

the main reason for not adopting SOA. This factor was particularly significant as a barrier to deployment in 

the Public Sector and Manufacturing vertical markets. 

However, there are a number of other reasons why SOA is not seeing a wider uptake, with security concerns 

a significant contributor. For many end users (and rather more so, the IT department that is tasked with 

ensuring security), the idea of having their applications exposed as services to all comers on the Web signals 

increased vulnerability. There is a concern that the flexibility of SOA may come at the expense of reduced 

security. The Evans Data survey also found that authentication of on-line identities is the greatest security 

challenge to Web services, with one in four respondents saying that the inability to confirm the identities of 

on-line users and services is the biggest problem. 

Whilst there are many security initiatives under way, gaining better understanding of the issues and how they 

may be overcome (for example, by supporting encryption once messages travel outside firewalls) will help. 

A basic lack of awareness is also limiting adoption; the Datamonitor survey showed that 13% of the 

respondents had not heard about SOA, whilst another 17% could see no need for SOA, or had not looked 

at SOA yet. This was most prevalent in those verticals with low adoption rates, in particular the 

Manufacturing sector. 

The Evans Data survey highlighted another important issue – 25% of respondents stated that the leading 

problem in implementation of Web services was either a lack of industry standards or changes in standards, 

a 67% increase from the previous survey on this issue. Certainly, standards around SOA are still maturing, 

and it is interesting to see that this is seen as a barrier to adoption. 

Enterprises expect cost savings to come from SOA deployment, though 

these will be in the long term. 

In the Datamonitor survey, only 5% of the surveyed enterprises saw cost issues as a reason for not adopting 

SOA. The majority (67%) of the surveyed organisations that are adopting SOA do not expect their overall 

IT spending to increase as a result. As SOA impacts all areas of an enterprise’s IT structure (and therefore 

its spending), it also suggests that enterprises believe that SOA will help them to save costs. 

Implementing SOA certainly requires investment in its early stages, in areas such as planning, setting up a 

roadmap, assessment of business processes, and re-design of the IT structure. One of the main concerns is that 

Implementing SOA 

certainly requires 

investment in its early 

stages, in areas such 

as planning, setting 

up a roadmap, 

assessment of 

business processes, 

and re-design of the 

IT structure. 

new infrastructure and new ways of working will be needed to make SOA work. 

This implies that pilot and early adopter projects will have a net cost to the 

organisation, and will therefore require very careful justification. Converting to 

SOA is a fundamental change that will require the restructuring of many existing 

applications, in order to use the available resources in an optimal way. 

Potential cost savings will drive the adoption of SOA. If one can reuse services 

that have already been built, less time and money is required when developing 

new applications, driving costs down by eliminating duplicate systems. 

However, where many of the benefits are likely to be realised most quickly are 

where new projects allow access to new markets, by enabling loosely-coupled 

yet automated interactions to existing systems. 

As well as infrastructure, an area that is likely to require greater spending is 

IT services – in part, with technology vendors but also with services providers 

that have already assisted in successful SOA implementations. Learning from others’ success is a major 

benefit to the ‘second wave’ of adopters – as is understanding where projects have gone astray. 

A piece of valuable insight from the Quocirca survey showed that those survey respondents who had gone 

fully down the SOA route saw major benefits for their organisations. These organisations are more 

competitive, due to the flexibility of their optimised environments. Often it is new functionality that is being 

implemented in a service-oriented manner, although there is also an element of re-architecting existing 

infrastructure to be more service oriented. 


December 2006



SOA ROADMAP 

CATALYST 

SOA is not something that will happen overnight. It is much more likely that an organisation will take a 

number of years to achieve a true SOA. Understanding this, and planning how the organisation will move 

towards that goal will be facilitated by the creation of an organisational-specific roadmap that helps it 

understand where it is now, and where it needs to work next in order to best achieve the goal. 

SUMMARY 

Planning a strategy across several domains provides visibility. 

SOA may not be the appropriate architectural model for all systems. 

The move to SOA will take many years for the majority of organisations. 

Careful strategy can help to future-proof SOA developments. 

ANALYSIS 

With the level of hype around SOA, one could be forgiven for thinking that it is a concept that organisations 

should be able to ‘do’ rapidly and move on. However, evidence indicates that a more realistic timescale for 

SOA is at least five years from the start – and probably significantly longer. The challenges of SOA, 

compounded with the lack of genuine understanding, mean that this could even be quite optimistic – the 

changes required to the way organisations work may mean that early attempts do not deliver the expected 

benefits, unless carefully managed and controlled. 

Planning a strategy across several domains provides visibility. 

Successful SOA will require that all areas of an organisation need to understand the impact of SOA, and 

what it is likely to do for them. In order to achieve the goal, as with setting any organisational change target, 

understanding the different areas that need to be involved, and setting objectives for each area at each 

Successful SOA is 

about the process of 

change – 

understanding how it 

may affect the 

organisation and 

what the organisation 

is aiming for. 

phase looking forward will be a valuable exercise. Successful SOA is about the 

process of change – understanding how it may affect the organisation and 

what the organisation is aiming for. SOA requires highly cross-organisational 

focus – it is about getting the organisation to come out of its departmental 

‘silos’, and developing an awareness across the organisation. The rise of 

shared services is a business-centric start for this process – understanding that 

a particular competency can be provided as a service to other areas of the 

organisation. In some respects, the business is already ahead of IT here! 

Often viewed as a type of maturity model, the objective of defining a high-level 

roadmap is to ensure that progress is made in each of the main areas before 

moving on to the next phase. If any of the individual areas has not progressed, it 

is likely that any move to SOA will be less effective than anticipated. Each organisation should develop its own 

roadmap as part of the planning process, but may be guided by the model we provide here as Figure 8.2.1. 

A number of vendors have developed maturity models for SOA (including Amberpoint, BEA Systems, IBM, 

Sonic Software, and Systinet (now Mercury)). However, a maturity model would probably align best with 

an independent body like the Software Engineering Institute (SEI), which has developed the Capability 

Maturity Model Integration (CMMI). The Butler Group SOA Roadmap has been formed by reference to 

several of these models, together with discussions with early adopters and systems integrators. 




Phase 1 – 

Investigation and 

Discovery 

Phase 2 – 

Development and 

Deployment 

Phase 3 – SOA 

Transformation 

Phase 4 – SOA 

Maturity (The 

Service Oriented 

Enterprise) 

Business Vision 

Define Business 

Case 

Education 

Business Model 

Development 

Business metrics 

Optimisation 

Process stream 

analytics 

Business networks 

Architecture 

Develop 

architecture 

competency 

Business and 

technical 

architecture 

Data and 

application 

architecture 

Common service 

architecture 

Data 

Management 

Service to 

information 

mapping 

Develop 

information 

architecture 

competency. 

Master Data 

Management 

Content in 

processes 

Business Activity 

Monitoring 

Dynamic process 

optimisation 

Develop corporate 

data dictionary 

Control and 

Governance 

Roles and 

responsibilities 

Organisational 

structures 

Change 

management 

Dynamic 

governance 

Policies 

Infrastructure 

Messaging 

infrastructure 

ESB 

Services registry 

and repository 

Rules 

Service 

management 


Autonomic service 


Development 

methods 

Acquire serviceoriented 

expertise 

Service 

development and 

re-use 

Composite 

application 

development 

Rapid application 

assembly 

Business Vision 

Figure 8.2.1: SOA Roadmap 

During the discovery phase, it is vital to define the business case – to understand why SOA is needed for 

the organisation and to establish what is trying to be achieved. Even in an organisation where business 

management is already pushing for change, it will still be valuable to focus on 

During the discovery 

phase, it is vital to 

define the business 

case – to understand 

why SOA is needed 

for the organisation 

and to establish what 

is trying to be 

achieved. 

the desired business objectives. Parallel to this is the need to educate, 

particularly at the higher levels. A large amount of material exists on SOA, and 

distilling this into usable and inspirational value can be a challenge – some of 

the more business-focused publications here include Enterprise SOA (Dan 

Woods and Thomas Mattern, O’Reilly), and Mashup Corporations (Andy 

Mulholland, Chris S. Thomas, Paul Kurchina, and Dan Woods, Evolved 

Technologist Press). 

At the development and deployment phase, the business needs to develop its 

business models – to understand where it is heading. This will include an 

understanding of where it fits in a supply chain or similar extended enterprise, 

and what it could expect partners and customers to demand. 


December 2006



The SOA Transformation stage will involve establishing the business metrics (or Key Performance Indicators 

– KPIs) that work for the organisation. Whilst there may be some generic KPIs, it is important that the 

organisation understands what metrics are important to them, and subsequently identifies how to measure 

and use the information that is then generated. By this phase, alignment should be significantly improved 

and business and technology working together in partnership. The 

organisation will be implementing both internal and external processes and 

services, and working towards optimisation of those services. 

By the time the organisation has evolved to SOA maturity, it will be receiving 

feedback from all aspects of the enterprise and can look to using this feedback 

on an ongoing basis in order to continually optimise business processes. 

Process optimisation is an ongoing concept, not an end point in itself. 

Architecture 

Butler Group has discussed the importance of enterprise architecture many 

times, and believes that when moving to SOA, the ‘A’ – architecture, as in the 

fundamental organisation of a system embodied by its components, their 

relationship to each other and to the environment and the principles guiding its design and evolution (IEEE 

P1471/D5.3) – becomes critical. This has to include the business (people) side as well as the technology 

aspects, and may extend outside the enterprise, particularly in collaborative environments. 

During the discovery phase, an organisation may need to develop an architecture competency if one does 

not exist – gaining an understanding of architecture concepts and benefits can clarify both business and IT 

objectives. 

The development and deployment phase should see this competency then being put to work to define the 

business and technical architecture for the organisation – and will need to work closely with the business 

to understand how the business needs will drive the underlying technology structures. 

The SOA transformation phase will see the full fleshing-out of more formal data and application 

architectures, as architectural awareness grows and the organisation itself evolves. 

When an organisation moves into the SOA maturity phase, it will be developing a common service architecture, 

where reuse of existing services is a given, and new services evolve easily as needs become apparent. 

Data Management 

Data is an undervalued area in these days of distributed computing, but developing a corporate data model 

will be vital in making sense of how data can best be reused in SOA. When Enterprise Resource Planning 

(ERP) systems were developed, little attention was paid to how information would be used – they were 

designed to be optimised for transactions but not for information and 

In the investigation 

and discovery phase, 

the organisation 

should develop an 

information 

architecture 

competency, and start 

defining a service to 

information mapping. 

The SOA 

Transformation stage 

will involve 

establishing the 

business metrics (or 

Key Performance 

Indicators – KPIs) that 

work for the 

organisation. 

reporting. There is a risk with SOA that the data services needed to deliver 

adequate information and intelligence will be an afterthought as well. 

In the investigation and discovery phase, the organisation should develop an 

information architecture competency, and start defining a service to 

information mapping. This should help clarify what data is stored, where it is 

duplicated and potentially redundant, and where there may be gaps in 

corporate data that are filled by personal sources. At this stage, it will be 

valuable to develop a corporate data dictionary – complete with semantic 

definitions so that there is a common understanding across the organisation. 

During the development and deployment phase, master data management will 

become a necessity. Organisations today have multiple versions of common 

data items, and whilst this may be necessary in a distributed (both technically and geographically) world, 

it will also be a major challenge. Understanding where data originates, who the owner should be, and 

developing a policy for ensuring that master data is rapidly propagated to where it needs to be used, must 

be addressed during this phase. At this stage, the organisation will need to develop an understanding of 

where and what content is used in its various processes. 




At SOA maturity, the 

organisation will start 

to be able to 

dynamically optimise 

processes based on 

the visibility of data. 

By the SOA transformation phase, a deeper understanding of data 

requirements will become apparent. Business Activity Monitoring (BAM) 

should be starting to be used in this phase so that the organisation can see, 

on an up-to-date basis, where there may be performance issues. 

At SOA maturity, the organisation will start to be able to dynamically optimise 

processes based on the visibility of data. New data sources and types may 

need to be introduced, but the architecture will have been defined to enable 

swift incorporation of new data services that can then be used in conjunction 

with existing ones. 

Control and Governance 

At the investigation phase, most organisations will want to pay scant attention to control and governance 

issues, but although a heavy handed approach is likely to be unnecessary, a degree of governance will be 

required early on. The right organisational structure to mandate and govern the development of services will 

need to be worked out, including establishing ownership of services. Without good governance, there is a 

risk that services will be created to satisfy whims that are not genuine business needs. 

By the development and deployment phase, organisational structures including roles and responsibilities 

must become more clearly defined. Understanding what is expected of the various parts of the organisation 

– and this is not only the IT function – will be important to ensure adequate 

control is there. Policies should start to become visible by this stage, 

Change management, which will already have started to become an issue, 

needs to be resolved during the SOA transformation stage. Whilst in an ideal 

world services should be carefully defined up-front to avoid change, in the real 

world change may be needed, and will need to be managed and governed. 

Tools to assist will have developed in maturity by this time (there are already 

many available today). 

Once an organisation moves into the SOA maturity phase, the concept of 

dynamic governance will start to become real. For this to happen, it must be possible to examine what 

messages are being routed through the organisation, measure response times, and take corrective action 

dynamically if there are any issues. 


During the investigation and discovery phase, organisations will need to look at their infrastructure and 

modernise it to put certain basic elements in place. It may be possible to reuse an existing messaging 

infrastructure, and layering Enterprise Service Bus (ESB) technology on top is likely to be a route that many 

organisations will already be investigating. An area to watch here is the growth of the open source 


requirements will 

evolve during the 

move to SOA, and by 

the SOA 

transformation phase, 

it will be necessary to 

develop a 

comprehensive 

service management 

infrastructure... 

Change management, 

which will already 

have started to 

become an issue, 

needs to be resolved 

during the SOA 

transformation stage. 

technology stack, which may provide a useful way of testing out options with 

lower investment. 

In the development and deployment phase, organisations should start to use 

the idea of a services registry and/or repository. This will help with some of 

the governance issues, as well as ensuring that all participants understand 

what services are already available. Here it will also be valuable to develop an 

understanding of the business rules that are already present, but that are 

embedded deep in multiple business systems. These must be separated from 

those core systems to enable business users to make modifications to them 

easily. 

Infrastructure requirements will evolve during the move to SOA, and by the 

SOA transformation phase, it will be necessary to develop a comprehensive 

service management infrastructure that overlaps with, and reflects the 

business services that are in use. By this phase, SOA infrastructure tools must 

be merging with the other IT service management tools and techniques that are in place today; for example, 

there is likely to be significant overlap between a Configuration Management DataBase (CMDB) and service 

registries that should be resolved during this phase. 


December 2006



By the SOA maturity phase, the real dynamism that SOA can offer should start to become feasible, with an 

autonomic service infrastructure allowing services to be identified and accessed on-the-fly. Forecasting how 

infrastructure is likely to change so far into the future is like gazing into a crystal ball, but a policy-based 

solution is likely to support this model the best. 

Development Methods 

One of the key needs of the investigation and discovery phase will be to acquire service-oriented expertise. This 

may be easier said than done, since it requires a move from functionality and application-oriented thought and 

design processes to a service-oriented one. It will also be vital to have a broad understanding of current systems 

and technologies; it is unlikely to be wise to buy external SOA skills at the expense of upgrading internal skillsets. 

This change of emphasis will need a significant human change management effort. 

During the development and deployment phase, we would expect organisations to be moving on from pilot 

projects towards a reasonable degree of service development and reuse; this is where it will be apparent 

that the different domains are inter-related, since without the other horizontal areas keeping up, it would 

be all too easy to develop runaway services that do not suit business needs. Essentially, a service serves; 

the questions to be resolved at this phase are how, where, why, when, to whom, and if it is needed at all? 

Although a few composite applications exist today (for example SAP, together with some of its partners, have 

created what they refer to as X-APPS, which link together several services both from within SAP’s 

application and external to it), Butler Group does not see a significant move to this paradigm until 

organisations are ready to move to the SOA transformation phase. Here, it is anticipated that composite 

application development will become much more commonplace, and large, single-purpose applications will 

gradually reduce. 

In the SOA maturity phase we will start to see rapid application assembly, where composite applications 

are the norm – in fact they are created and then overtaken by new ones from the underlying services which 

become available. This will need service creation to be fully understood throughout the organisation. The 

IT function will need to support the composition paradigm fully, with graphical composition tools in the 

hands of business-facing experts. 

SOA may not be the appropriate architectural model for all systems. 

Whilst SOA holds the promise of flexibility, agility, and potential for future cost savings, it may not be the 

most appropriate architectural model for all systems. Where complex transactions are involved that need 

tightly coupled links between the various phases of the transactions, a SOA is unlikely to be a suitable 

model, particularly if very high volumes of transactions are involved with high performance requirements. 

Stateful, long-running, orchestrated business conversations are not well-suited to a SOA approach, as the 

management of such complexity is beyond SOA, certainly at the moment. 

Where an application is very self-contained and structured, and components have been designed to be 

tightly coupled, there is little advantage in breaking it down into services that are insulated from each other. 

Additionally, where an organisation has recently implemented a new enterprise application, such as an ERP 

system, which is in widespread use throughout the organisation and is starting to meet its transactional and 

informational needs, there is little relevance in even considering SOA. However, the vendors of most of the 

major enterprise applications are certainly paying serious attention to SOA – they are facing many of the 

problems, such as rigid processes, that SOA can address. It is therefore likely that future versions of such 

applications will be service-enabled, and permit choice in how the individual services are assembled in the 

future. 

Where only one or two applications are in use in a homogeneous IT environment, and they are not likely to 

change, imposing a SOA would add unnecessary overhead at this stage. Organisations may want to start 

investigating SOA within the next year or two, to establish if it is likely to have any benefits for them – and 

even so, there may be no apparent need to change for the foreseeable future. In cases such as this, service 

orientation might be an appropriate model for new functionality, particularly when external partners and 

collaborations may be relevant. The book ‘Mashup Corporations’ has some examples illustrating this usage 

of SOA for new projects. 




The move to SOA will take many years for the majority of 

organisations. 

It is all very well establishing a roadmap, but a question that is often asked is how long will SOA take to 

be a normal business/IT paradigm? As with any other forecast of the future, this is a challenging question. 

Certainly, some large organisations are starting to understand that things are unlikely to stay as they are, 

and the benefits of service orientation imply that it will be a good model to follow. 

The four phases that we discussed are likely to take a number of years for any organisation, even the most 

flexible and agile out there. Some organisations are already starting to work on phase one – educating 

themselves about SOA; in fact this has already been underway for two or three years now in early adopters. 

Where SOA is likely to gain limited uptake for a number of years to come is in the mid-market – here, we 

are still seeing a continual shift away from standalone applications that only cover a small part of the 

business, enhanced by a ‘sticky tape and string’ collection of applications, spreadsheets, and e-mail, 

towards more integrated ERP systems. For these organisations to then be told they need to break up these 

applications into services seems like a backward step. Mid-market companies and other medium-sized 

organisations (for example, in the Public Sector) are far less likely to be even thinking about what SOA might 

mean for some time yet – and when they do they will not appreciate being pushed into making decisions 

by the vendors. Not all organisations will either want or be ready for SOA. 

Careful strategy can help to future-proof SOA developments. 

As with any new technology idea, the suspicion is that hype is rather more than the content, and it will 

soon be replaced by ‘the next big idea’. Butler Group believes that the terminology, SOA, might be 

superseded, but that the concept of a service-oriented organisation is very much the model of the future. 

Having said that, there are steps that organisations can take to ensure that any work they do on SOA 

projects will still be relevant as technologies and business challenges change in the future. 

Process Discovery and Modelling 

The way that organisations have evolved has frequently been very hit-and-miss, as management structures 

grew to cope with the changing business environment. Developing a thorough understanding of what the 

business processes are within an organisation will be valuable, whatever happens in the future. 

Adoption of Technical Standards 

Standards are often seen as an invention by vendors that can lag a number of years behind what the vendors 

themselves are offering – witness the number of vendors that add ‘extensions’ to standards in order to 

provide specific capabilities. What is probably as important as understanding the wider technical standards 

is at least picking what works for the organisation, and promoting the use of those within the organisation. 

De facto standards can be as relevant in the real world as those that are formally ratified by the various 

standards bodies, as this indicates widespread adoption. Participation on standards bodies may be a major 

commitment but will at least provide end-user perspectives directly to the standards process, and should 

be considered by organisations that can afford such commitment. 

Maximising the Level of Abstraction 

Whenever business-relevant information is buried within technology and tools, it becomes harder to change, 

requiring the relevant skills and knowledge to do so. Wherever possible, this needs to be abstracted to the 

highest level possible to make it much easier to change, and reduce the skills required to make that change. 

This approach is highly consistent with SOA. 

A Solid Architectural Framework 

There is a myriad of tools and technologies on the market for SOA-enablement, and organisations need to 

take care to understand the underlying architectures within them to avoid lock-in wherever possible. 

Creating a solid architectural framework for the organisation, based on its own needs, skills, and future 

plans, will help to ensure that work done for SOA projects is relevant to these internal requirements. 


December 2006



The Role of Business Rules 

Business rules is one of those phrases that is reasonably understood, even if not always well-defined. 

Separating out such business rules from the tangled web of code where they are usually buried, is a valid 

exercise that will repay efforts whatever architectural style is the current trend. Rules should be visible, 

manageable, and therefore under the control of business people rather than technologists. 

Creating Generic Interfaces 

The major problem with many older technologies is that the interfaces to applications were often hardcoded 

with those applications, making it necessary to amend significant amounts of code any time a change 

was needed. Separation of interface from application is already a feature of n-tier architectures that is still 

valid in a SOA approach, and will still be relevant in the future. Future-proofing SOA can be achieved by 

continuing to create generic interfaces to older applications. 

SOA MANAGEMENT AND GOVERNANCE 

CATALYST 

Once services start to be deployed, the joint issues of SOA management and governance will demand 

attention. It is wise to plan for this early on in a SOA project, otherwise there is a risk that SOA will not 

deliver its expected benefits. 

SUMMARY 

Left unmanaged, services can rapidly degenerate into a tangled mess. 

Run-time management and governance of SOA will converge with traditional 

systems management. 

A clear definition of SOA roles and responsibilities supports good governance. 

Standards for SOA governance are beginning to emerge. 

ANALYSIS 

Governance can be regarded as the discipline of managing desired outcomes through structured 

relationships, policies, and procedures. Good SOA governance should make it easier for organisations to do 

the ‘right’ things and harder for them to do the wrong ones. Governance can be achieved by creating and 

then enforcing machine enforceable policies across the service lifecycle, from design time through to run 

time, and especially when services need to be changed. 

Left unmanaged, services can rapidly degenerate into a tangled mess. 

The key difference that Butler Group has identified between successful SOA projects and ones that fail to 

deliver benefits is in the area of good management and governance. Without a good human management 

infrastructure, even the best technology solution is likely to allow services created on it to degenerate into 

a confused set of services that do not get well used. 

Thomas Erl, in his book “Service-Oriented Architecture: Concepts, Technology, and Design”, lists a number 

of common pitfalls in adopting SOA: 

 

Building SOA in the way that distributed architectures have been built – this can introduce problems 

such as a proliferation of Remote Procedure Call (RPC)-style service descriptions, the creation of services 

that cannot then be composed with others, and the creation of non-standardised services. 




 

 

Not standardising SOA – this is especially relevant for larger organisations, where a number of different 

projects running in parallel could result in very differently designed services that cannot then be 

integrated or composed in the future. A way to overcome this would be to have a single proof-of-concept 

project to establish good practices that can then be spread throughout the organisation on future 

projects. Similar services may be developed in different regions of the organisation because information 

is not being shared. This will occur for organisational and political reasons but should be minimised by 

good governance. 

Not understanding SOA performance requirements – SOA is likely to introduce multi-layered processing, 

and certainly when Web services are used, there is a deep dependence on XML data representation. This 

can cause performance issues unless hardware is scaled appropriately and performance is considered at 

design time. 

One of the first 

essentials will be to 

set up the 

organisational 

structures in people 

terms to ensure good 

management and 

governance. 

Some of these issues can be overcome by good design, but a sound 

management and governance capability should be planned in from an early 

stage to avoid these issues. 

One of the first essentials will be to set up the organisational structures in 

people terms to ensure good management and governance. Who (as in ‘what 

department’, as well as ‘what role’) should be responsible for monitoring, 

defining, and authorising changes to existing services that will exist within an 

organisation? Some kind of internal governing body should be set up to take 

on this responsibility. However, there are alternative models – central and 

distributed. 

With central governance, the body should have representation from each of 

the areas that are affected by services (both technical and business, including 

subject matter experts), and it will be wise to have an independent arbitration 

function as well to help resolve issues. This governing body will then review 

proposed new services, approve the removal of unused services, and where 

appropriate, changes to existing services. 

A distributed 

governance approach 

would involve each 

business unit having 

its own body to 

monitor services that 

are relevant to that 

business unit. 

A distributed governance approach would involve each business unit having 

its own body to monitor services that are relevant to that business unit. This 

is likely to be more appropriate for a highly distributed organisation that 

already has autonomous management. Whichever model is suitable (and a 

mixed model may be appropriate), the role of the governing body is to define good practices and standards 

for services, including the architectural and procedural guidelines for their use, and to oversee their 

deployment. 

Some of the key questions that arise around SOA management and governance include: 

Who has access to services? 

Who is allowed to create them? 

How do you write new versions of that same service? 

What happens when they are updated? 

What are the rules and polices around upgrades? 

Good metadata management is also a key part of successful SOA. Defining the standards to be used, for 

example for different data elements (such as in identifying a customer, which may have a customer ID for 

internal use to uniquely identify a customer, and a customer login ID which is used by the customer to 

access a service) is important. The data dictionary concept beloved by mainframe systems is actually a 

highly beneficial model – providing clear and accessible information about what data is, and how it should 

be used within the organisation. Where services cross organisational boundaries, it will be necessary to then 

use agreed standards (such as Electronic Data Interchange (EDI) standards, Interactive Financial Exchange 

(IFX) standards, and so on). 


December 2006



The Role of the Registry 

One of the problems that arose with early Web services was around service identification, with frequent 

stories of services being ‘discovered’ through discussions around the coffee machine or in passing in the 

corridor. Services could rapidly become far more popular than anticipated and performance may become an 

issue. Equally, services could have been created that served no business need, 

and were therefore not used. It is vital to define a common central store for 

information about services – often called a registry. A registry can be used for 

much more than simply keeping basic information about services – it can be 

used both at design time and run-time so that policy-based information can 

be dynamically accessed at run-time for detailed control. 

The service registry 

can support 

sophisticated 

dependency and 

impact analysis. 

The service registry can support sophisticated dependency and impact 

analysis. Even though a service should be self-contained, it may still impact 

another when used in a composite application. In addition, it will be valuable to identify which services 

interact with one another when the need to modify a service arises – if too many services might depend on 

it, this could be an occasion when it is appropriate to create a new service that has some similar 

functionality, rather than create a new version. 

An area that will be interesting to watch over the coming months will be what happens in the area of 

CMDBs. Today, these are used in the IT service management arena to maintain and manage information 

about various IT-related assets – and services can equally be regarded as assets, just as applications and 

systems are at the moment. 

The Service Contract 

When two parties agree to do business with one another, it is very wise to set up a contractual agreement 

that covers what the provider will deliver, and what the consumer expects. The same applies within a SOA; 

it is sound practice to define the contract and obligations between consumers and providers, and these will 

be interdependent. Often the service definition (as given in the Web Services Definition Language (WSDL) 

for a Web service) is regarded as sufficient, but in practice rather more will be necessary. There are a 

number of other things that need to be documented about a service’s agreement with its consumers, such 

as run-time performance expectations, who to call if the service breaks, charging models (if any), etc. 

SOA Lifecycle Management 

Within the applications area, we are seeing the emergence of the concept of Application Lifecycle 

Management (ALM), which covers the lifecycle of applications from origination through to deployment and 

on to retirement. Services will need a similar degree of control throughout their lifecycle; something will 

trigger the creation of a service, and eventually it may need to be removed from service as it is no longer 

needed. Within ALM, change management is a particularly complex area. 

In SOA, version control is a highly contentious issue. Delegates at a recent Butler Group Masterclass on SOA 

had some robust discussions on whether a service should be able to have multiple versions or not. The 

conclusion of the debate was not unequivocal – most services are likely to change over time, and the change 

should be reflected by the creation of a new version. However, a service that could be used in a very longrunning 

business process might need to be kept stable. The important thing is that the service interface 

should not change unless the version changes – minor details of how the service operates could, in theory, 

be accommodated without a version change. 

Lifecycle management issues cover service development, testing, staging, and production. Moving from one 

phase to another can be a complicated challenge, and the move for mainstream application management 

vendors to acquire the more specialist SOA management vendors is likely to prove beneficial here. 

Design-time Management and Governance 

A building relies on having good foundations – no matter how good a quality the bricks, doors, windows, 

and the construction itself, if the foundation is not sound then there is a risk that the building will collapse 

if the strain becomes too great (for example, if there is an earth tremor). The same metaphor can be applied 

to services – if a really ‘cool’ service is developed and proves highly popular, overuse of that service could 

cause the whole infrastructure to grind to a halt. Some of this will be down to the platform but the majority 

comes down to good governance and management. 




Governance can be split into design-time governance and run-time. Design-time governance covers service 

assets within a registry and/or repository. Such assets can include the service description (WSDL), 

documentation, schemas, namespaces, taxonomies, Business Process 

Execution Language (BPEL), and so on. 

One of the key 

aspects of designtime 

governance is 

the need to control 

what is developed, 

which should always 

be driven by the 

business need. 

One of the key aspects of design-time governance is the need to control what 

is developed, which should always be driven by the business need. One 

organisation found that when it identified a particular business-relevant 

service, and then investigated what existed that could be mapped to that 

service, it found that there were already some 20-odd versions of that service 

in existence – requiring significant re-design to consolidate. However, good 

governance must not stand in the way of innovation; it should seek to de-risk 

it. This will be one of the greatest challenges to the IT function – how to 

manage SOA carefully without restricting the organisation. 

Run-time management and governance will converge with traditional 

systems management. 

Standard IT systems management usually covers applications that operate on one platform, although of 

course there are already technologies that enable common management across several platforms. However, 

as an organisation starts to deploy SOA-based applications, management of an operational SOA will require 

additional thought and preparation. 

The major challenge for management of SOA is that the services may not all be within the same domain. 

Service management consoles are used to monitor and manage performance issues within an organisation’s 

infrastructure, but when a service could be running externally to the 

organisation, it is necessary to then establish performance metrics about that 

service in a standards-based manner. 

Run-time governance usually concerns the messages flowing across the 

message transport system, and usually relates to SOA policy and security 

management. However, run-time governance can also control elements such 

as routing and transformation – capabilities that can be performed by an ESB 

but could also be carried out by policy management. 

Run-time governance 

usually concerns the 

messages flowing 

across the message 

transport system, and 

usually relates to SOA 

policy and security 

management. 

The run-time management aspects cover logging (auditing), performance 

management, monitoring, and alerts. Such run-time management may be 

particularly relevant if a service fails to run as expected, allowing a request to 

be routed to a back-up or alternative service that is available, but which may have a different cost. An 

example of this might be a credit-check service. Usually the organisation might use a low-cost service, but 

if this is not available for some reason then it may be appropriate to access a more expensive alternative, 

or it may be preferable to wait until the cheaper one is available. Policies may need to be accessed here to 

help make the decision. 

Routing of messages may be used to perform load-balancing functionality in order to improve performance. 

For example, if some services had a very high service level defined, then it may be necessary for the SOA 

management infrastructure to hold back services with a lower Service Level Agreement (SLA) to enable 

critical services to be performed first in order to meet the required SLA, and also to send alerts if the critical 

SLA is breached. Many organisations will require the ability to define quality of service requirements for 

individual services, creating a graded service structure. 

SOA governance tools usually include the ability to define and maintain policies for service management. 

Some products on the market allow different qualities of service to be made available; for example, IONA’s 

Artix Enterprise Service Bus can be extended to provide quality of service capability, but is also available 

without this if service level monitoring is not required. 

One issue that is particularly likely to arise where a service is used by many third parties is the potential 

for it to become over-used, and here the SOA management offering will need to have the ability to ‘throttle’ 

services to restrict them in order to prevent it impacting others adversely. 


December 2006



Management of SOA will need a console-style capability that crosses all the platforms that the services are 

operating on. Managing external services has to be included in this, and this is where standards for 

management will become necessary. We foresee that run-time service management and monitoring will 

become part of the whole IT Service Management area, but one that must be directly related to the 

business. 

Accountability within SOA must be driven by the presence of a sound audit trail indicating all interactions 

with a service. Service management tools need to be able to produce metrics which can then be analysed 

to provide feedback into the service lifecycle. This area is still in the early stages of development, but to 

enable a fully mature, service-oriented enterprise, the feedback loop provided by such analysis will illustrate 

where services can be improved and optimised. 

A clear definition of SOA roles and responsibilities supports good 

governance. 

Various roles will be needed within a successful SOA project. The governing body has already been 

discussed, but at a more detailed level, there will be a range of different roles that may be necessary, such 

as system administrator, operations, security officer, and business analyst. 

At a recent Webinar organised by the EbizQ Web site, participants were asked what formal governance roles 

were in use within their organisations. The results indicate that, whilst a number of organisations have not 

yet defined formal roles, many see that this is an increasingly important point. 

Role 

Percentage of respondents 

(multiple responses allowed) 

None 39.94% 

SOA Governance Officer 17.89% 

IT Governance Officer 31.31% 

Compliance Risk Officer 24.92% 

Security Policy Expert 40.58% 

Figure 8.3.1: SOA Governance Roles (Source: EbizQ) 

Security is currently seen as the most important formal role, with almost a third having an IT Governance 

Officer as well. The same survey then asked who was responsible for defining governance policies, with 

more conventional job titles as the selected options. 

Role 

Percentage of respondents 

(multiple responses allowed) 

Other 13.42% 

Policy Experts 52.08% 

Architects 63.90% 

Developers 14.38% 

Figure 8.3.2: Who Defines Governance Policies (Source: EbizQ) 

The role of the architect is clearly seen as an important one, with the majority of respondents seeing 

architects as having a significant role in the establishment of governance policies, with policy experts 

coming a significant second. 




It is clear that different organisations will have different needs, but Butler Group would recommend that 

governance roles are considered during the planning process for SOA projects, identifying what is the most 

relevant for the organisation, and then empowering (and skilling up) the relevant people. 

Standards for SOA governance are beginning to emerge. 

One of the key areas that will support management and governance is the emergence of standards that will allow 

interoperability across heterogeneous platforms. 

Web Services Distributed Management (WSDM) is the main standard for management information for Web 

services. It is an Organisation for the Advancement of Structured Information Standards (OASIS) standard, with 

version 1.0 approved in March 2005, and a revised version 1.1 delivered in August 2006. It incorporates two 

elements; Management Using Web Services (MUWS) – which covers the use of Web services as a means to 

manage distributed infrastructures, and Management Of Web Services (MOWS). As such, the standard is highly 

focused around Web services issues, and may well need to evolve with the growth of SOA embracing rather 

more than just Web services – although the use of Web services to provide interoperability is of value. 

Java Management Extensions (JMX) technology is a Sun-sponsored Application Program Interface (API) that 

provides the tools for building distributed, Web-based, modular solutions for managing and monitoring devices, 

applications, and service-driven networks. It is suitable for adapting legacy systems, as well as implementing 

new management and monitoring solutions, and has been designed to support future management issues as far 

as possible. 

The various registry standards to date include Universal Description, Discovery, and Integration (UDDI), ebXML 

Registry Repository interfaces for Repository (an OASIS standard again), and Java API for XML Registries (JAXR), 

which provides an API for reconciling UDDI and other XML registries. The latter can be used to allow registry 

client programs to be portable across different registry types. 

SOA Link (www.soalink.com) is a body working on end-to-end SOA governance, to ensure interoperability of 

different offerings on the market. Its members agree to use standards wherever possible (for example those from 

the World Wide Web Consortium (W3C), OASIS, International Organization for Standardization (ISO), Internet 

Engineering Task Force (IETF), and ECMA), and by joining, the various technology vendors indicate a willingness 

to interoperate with one another. SOA Link members include AmberPoint, Composite Software, Forum Systems, 

HP, Infravio, Intalio, IONA, iTKO, JBoss, Layer 7 Technologies, LogicBlaze, Mindreef, NetIQ, Parasoft, Reactivity, 

SOA Software, Solstice Software, SymphonySoft, and webMethods. Butler Group 

Service Component 

Architecture aims to 

provide a model for 

the creation of service 

components in a wide 

range of languages, 

and a model for 

assembling service 

components into a 

business solution... 

applauds the setting up of such a body, but wonders whether the competitive 

nature of the industry (and ongoing consolidation) will allow it to remain active, 

especially since the initiator, Infravio, has since been acquired by webMethods. 

OpenSOA (www.osoa.org) is an informal alliance including vendors and end-user 

organisations. It does not regard itself as a standards body, but is looking to define 

a language-neutral programming model that meets the needs of developers of 

SOA-style software. It is working on two main projects, Service Component 

Architecture (SCA) and Service Data Objects (SDO). 

Service Component Architecture aims to provide a model for the creation of 

service components in a wide range of languages, and a model for assembling 

service components into a business solution – activities which are at the heart of 

building applications using a SOA. 

SDO aims to provide consistent means of handling data within applications, whatever its source or format may 

be. SDO provides a way of unifying data handling for databases and for services. SDO also has mechanisms for 

the handling of data while detached from its source. 

SCA and SDO can each be used on their own – there is no requirement to use both of them in the same 

application. SCA and SDO used together provide a powerful and flexible way of building applications around a 

SOA. 

As with many of these vendor groupings, it appears that the world is still divided into two camps – the Java 

world and Microsoft. Although Microsoft is actively involved in many of the interoperability issues, it still appears 

to have the objective of providing the most flexibility by using the .NET framework as the overarching governing 

infrastructure for its customers. 


December 2006



POLICY AND SECURITY IN A SOA ENVIRONMENT 

CATALYST 

As the concept of services becomes more widely accepted, it will become increasingly important to 

consider some of the security requirements surrounding them – especially to gain wider acceptance of 

SOA. Simply restricting access to authorised personnel via standard access control mechanisms becomes 

impossible in a service-oriented environment, and new standards are starting to evolve here. 

SUMMARY 

The use of policies allows abstraction of concepts to a higher level, simplifying 

creation and maintenance. 

Security issues for SOA are more complex than in older architectures. 

Standards for SOA security and policy are starting to mature, and interoperability is 

improving. 

ANALYSIS 

In static architectures and application development, one of the key aspects is that it is possible to hard-wire 

the security. In creating a SOA with loosely-coupled components, it will be necessary to look at how security 

needs to be defined and managed for that type of architecture. The same applies for other policies – in the 

older architectural styles, there is the ability to implement policy at the design level. That ability is not there 

within a SOA. Here it will be necessary to ensure that the message flows that pass through those 

architectures actually access and interact with the declared policies at the right points within the 

architecture. This is a far more complex management infrastructure, but one that is balanced by a far more 

usable and far more relevant application infrastructure. 

The use of policies allows abstraction of concepts such as security to a 

higher level, simplifying creation and maintenance. 

Policies help to ensure compliance with organisational objectives; at the highest level these are likely to be 

highly business-related, and tend to cover people-related issues such as “projects must comply with internal 

design and architecture guidelines”, or generically, that all IT projects are subject to reviews for security and 

regulatory compliance. 

Today, policies are already there in most computing infrastructures, it is just 

that, where relevant, they tend to be hard coded and explicitly defined. An 

example of a security-related policy is ‘passwords must be eight characters 

long’ – this implies that there must be code embedded in each application to 

check that this is the case. This is not practical in SOA – policies must be 

specified and managed at the infrastructure level. Policies can relate to other 

areas including management and monitoring. 

Policies could represent more specific regulatory compliance issues; for 

example, in the healthcare industry patient’s personal identifiable information 

must be communicated and stored securely (in order to comply with the US 

Health Insurance Portability and Accountability Act (HIPAA) legislation). In the 

business sector, all financial transactions must provide traceability and 

tamper-proof mechanisms for mandatory audit records (to meet with 

Sarbanes-Oxley and Basel II regulations). 

Policies could 

represent more 

specific regulatory 

compliance issues; for 

example, in the 

healthcare industry 

patient’s personal 

identifiable 

information must be 

communicated and 

stored securely... 




Policies must be able to change, based on their usage over time. An example of this might be that a policy 

has been defined stating that e-mails to ‘Gold’ customers must always be checked by a manager, to ensure 

that they are polite, and follow guidelines for customer interactions. But how many times does the manager 

actually change the e-mail when it is checked? Can a customer service representative (or automated 

process) be regarded as sufficiently trusted to cut out this checking step altogether? The policy could be 

applied to untrusted or new people or services, but not once trust has been established. 

Policy is thus not always static. Some elements of policy are likely to be immutable (due to compliance 

requirements); others are more flexible, as illustrated by the e-mail checking example above. It will be 

necessary to report on policy usage and provide audit trails over time in order to provide the feedback into 

an iterative improvement process. The end result is that policy specification must be separable from policy 

implementation. SOA policy is an area that has seen a number of providers coming to market with products, 

and then establishing relationships with, or even being acquired by the bigger infrastructure players. 

When reviewing requirements for policy management and implementation, the following points should be 

considered: 

 

 

 

Policies should not be hard coded. 

Policies need to be enforced in a distributed manner. 

Actions and tasks should be checked against policies at run-time. 

Standards in this area are still developing, but again there is a likely candidate – the WS-Policy framework, 

which describes the rules, capabilities, and constraints of a Web service. The framework covers three 

A policy description 

can be made up of 

one or more policy 

assertions; examples 

include service 

requirements, 

preferences, 

characteristics, 

capabilities, and rules. 

specifications; WS-Policy, WS-Policy Assertions (which covers the service 

properties expressed by a policy description), and WS-Policy Attachments. It 

is a part of the WS-Security framework. A policy description can be made up 

of one or more policy assertions; examples include service requirements, 

preferences, characteristics, capabilities, and rules. Each assertion may be 

required or optional – for example, a preference is likely to be optional, 

whereas a rule will be compulsory. It is possible that a different policy should 

apply to a service depending on where and when that service is deployed – 

an example of this might be in the Financial Services sector, particularly in 

securities trading, where depending on where the trade request is placed, 

different legislation may apply to commissions and payment terms etc. 

When assembling services into a composite application, it is necessary to 

protect the whole extended ‘application’ via a policy managed solution, without altering the existing 

services. Policy and security therefore need to be separately managed outside the ‘application’ layer. 

Security issues for SOA are more complex than in older architectures. 

When developing any application, the issue of security is one that must be carefully considered. In an 

application-centric world, developers must consider security carefully, and may well need to spend a 

significant part of development time within each application on this. Security within a SOA world is different 

from the tightly coupled world in that security information needs to be shared, passed around, and 

understood across multiple services. 

A service provider does not know who or what will be accessing the service – this is the essence of decoupling. 

Securing the perimeter of an organisation with firewalls, Virtual Private Networks (VPNs), or 

security appliances will not work in a service-oriented environment that needs to set up new external 

relationships quickly and flexibly. Even internally, a service-oriented approach still needs security issues to 

be extrapolated out of the service and into the infrastructure. For this to then work across a heterogeneous 

architecture, standards will be vital. 

Secure access to business applications and to support integration between different applications is vital. 

There are five common security requirements – identification, authentication, authorisation, confidentiality, 

and integrity. On top of this there must always be an audit trail to prove conformance. 


December 2006



Identification 

Identification covers the means by which a service requester proves its origin, and this is referred to as 

making a claim or assertion. Such information in the Web services world is represented in the identification 

information stored within the service’s SOAP header. The WS-Security specification (which will be covered 

in more depth later) provides a standard header block, or token, which stores this information. There are a 

range of different tokens available. 

Authentication 

Authentication means that the user of an application or service is recognised and can prove that the service 

request message has, in fact, come from the sender that it claims to have. 

Authorisation 

Once an authenticated message has been received, the recipient service might need to establish what the 

requester is allowed to do, referred to as authorisation. 

Confidentiality 

Confidentiality, or privacy, covers the need for information being passed from one service to another to be 

inaccessible to unauthorised parties. This can apply to all or part of a message, and will be especially 

relevant if messages are likely to be transmitted outside the firewall, but even internally it may be important 

to ensure that personal information is kept private. 

Integrity 

The final aspect of security is integrity. This means ensuring that a message has not been modified in any 

way in transit. Security issues that can arise from a lack of integrity include SQL injection (where malicious 

code could access data that it is not authorised to) and buffer overflows. 

As soon as we move outside the organisation, issues of identity, authentication, and authorisation become 

significantly more complex because it will be necessary to share information between parties (whilst 

maintaining privacy and confidentiality) – and the element of trust comes in. The core requirement here is 

that trust needs to be built dynamically, with the security context being transported so that authentication 

and authorisation can be distributed and/or federated. 

Federated authorisation is a process by which multiple parties agree that a specified set of users can be 

authenticated by a given set of criteria. This approach sets up a Federated Identity Management System, 

or a pool of authenticated users. The SOA security solution can verify a user by checking with the Federated 

Identity Management System. A federated system is basically Single Sign-On (SSO) between different 

security domains, and currently is likely to require specialist third-party infrastructure, as support for this 

concept within application servers is currently limited. 

Validation of identity is usually covered by authorisation and access 

mechanisms, which can already be deployed across a wide range of 

architectural styles. At the entry point, most organisations moving to SOA will 

have at least two alternatives – Internet browser and portal-based for people, 

and Web services. The same set of identity information, such as SSO or 

federated identity attributes and access control mechanisms need to be 

applied in a consistent manner across both methods. It will be important to 

use Identity and Access Management technologies, including directories for 

Web services. 

Validation of identity 

is usually covered by 

authorisation and 

access mechanisms, 

which can already be 

deployed across a 

wide range of 

architectural styles. 

In many architectures, the way that the presentation and user interface layers 

are handled (including challenge and response protocols for authentication and SSO) is via a portal or 

portlet. A range of different user credential schemes have been deployed over the years including 

passwords, tokens, smart cards, and X.509 certificates. Within a Web services or SOA framework, it will 

be desirable to reduce the number of types of credentials used, and we are seeing Security Assertion Markup 

Language (SAML) and Kerberos tokens as the emerging leaders here. SAML has advantages in that its 

flexibility and extensibility allows support for secondary authentication credentials that might be needed to 

interact with legacy applications. 




Ideally, security should not even be part of many of the infrastructure elements, such as the ESB; it should 

be a capability that can be used as required by whatever infrastructure pieces are in use. 

Solving SOA security issues is likely to require the implementation of specialist security tools or 

infrastructure – examples come from SOA Software, Layer 7, and Amberpoint, as well as the main SOA 

infrastructure players. An interesting extension to this argument comes from the networking layer, with Cisco 

starting to provide some elements of security. 

During the summer of 2006, Cisco announced its Service Oriented Network Architecture (SONA) strategy. 

Currently, this is a mixture of its AON product combined with services, which sees the network as rather 

more than a transport layer – it is becoming a platform. SONA allows specific services to be provided as 

part of the network, such as identity, VPN services, and presence services from mobility, so that they can 

then be used within applications and composite applications. 

Standards for SOA security and policy are starting to mature, and 

interoperability is improving. 

As with many standards, the issue in the SOA arena is the sheer volume of them, which many organisations 

find confusing, and tends to muddy the water around SOA rather than provide clarity. A glance at Figure 

8.4.1 will give an indication of the scale here. One of the key positive elements is the formation of the Web 

Services Interoperability Organisation, WS-I.org, which is working to at least ensure that different models, 

products, and platforms can work together. 

Web Services – * 

XML 

Identity 

WS-Security 

WS-SecurityPolicy 

WS-Trust 

WS-Secure Conversation 

WS-Federation 

WS-Federation Active Requester Profile 

WS-Federation Passive Requester Profile 

WS-Policy 

WS-PolicyAssertions 

WS-PolicyAttachment 

eXtensible Access Control Markup Language (XACML) 

XML Key Management (XKMS) 

eXtensible Rights Markup Language (XrML) 

XML-Signature 

XML-Encryption 

.NET Passport 

Liberty Alliance 

Security Assertion Markup Language (SAML) 

Figure 8.4.1: SOA Security Specifications 

The WS-I is made up of a number of software vendors, both from technology and applications backgrounds, 

including BEA Systems, Fujitsu, HP, IBM, Intel, Microsoft, Oracle, SAP, Sun, and webMethods. Its objective 

is to promote interoperability across platforms, operating systems, and programming languages. The WS-I 

is not a standards body as such, but incorporates standards from a number of bodies such as the IETF, 

OASIS, and W3C. 


December 2006



The most important consideration currently is the existence of the Web Services Interoperability Basic 

Profile. This defines a mechanism for interoperability for the core standards used in Web services 

implementations, and covers SOAP, WSDL, and UDDI as well as some lower-level standards and protocols. 

The Basic Profile version 1.0 is not fully compatible with version 1.1 – guidance here is that usage of the 

standard should be at the same level to ensure interoperability. 

The Web services security (WS-Security) specification that has been developed and ratified by OASIS 

provides security for SOAP messages in transit, and can be regarded as an extension to SOAP. Originally 

developed by IBM, Microsoft, and Verisign, where messages need to pass across an untrusted intermediary 

structure, standards such as WS-Security provide a degree of trust, covering authenticity, integrity, and 

confidentiality of messages. Security can be applied at transport level (for example Secure Sockets Layer 

(SSL) secures the HTTP layer on which various requests and responses are transmitted). However, where 

a message is sent via an intermediary, the transport layer no longer has control over the message when it 

is at the intermediary, and therefore it may also be necessary to implement message-level security – like 

keeping a message within a sealed, tamper-evident envelope. 

The WS-Security standard is already reasonably mature – version 1.0 was approved by OASIS in April 

2004, and version 1.1 was approved in February 2006. 

The WS-Security family specifications cover the use of various different tokens, such as Kerberos, X.509, 

and SAML. An example of a signed security token is an X.509 certificate; this asserts a binding between 

the requester’s identity and a public key. Security tokens like this can be carried in a message, or expressed 

by a reference so that the receiving service can ‘pull’ the claim from the relevant authority. To ensure 

interoperability, adapters and common algorithms for signatures and encryption will need to be agreed 

upon. 

The WS-Security model is extensible, and allows a service to specify the type and degree of security 

required. The WS-Interoperability Basic Profile includes Security. 

Web services gateways, message brokers, and ESBs may provide the trust required themselves, and 

services that interrelate only within an ESB may not need to consider security. However, if they are to be 

exposed beyond this, then security will be needed. 

RUN-TIME OPTIONS FOR SOA 

CATALYST 

When most people think of SOA they automatically assume that Web services will be the way that services 

interact, and have concerns about the efficiency of such deployments. However, a SOA can have a number 

of deployment alternatives which can help get around some, but not all, of the performance issues. 

SUMMARY 

There is a trade-off possible between performance and long-term agility, and this 

needs consideration before committing to a course of action. 

Network appliance alternatives to traditional server/software implementation can 

offer cost/performance benefits. 

Run-time deployment of SOA-based applications does not always mean using Web 

services. 

High-performance SOA need not be an oxymoron, but good understanding of issues 

is needed. 




ANALYSIS 

There is a trade-off possible between performance and long-term 

agility, and this needs consideration before committing to a course 

of action. 

We need to be quite clear about the purpose of SOA: it is to provide improved utilisation of business 

functionality as delivered by application programs. This improved utilisation may take the form of better 

integration, creation of composite applications, automation of business processes, and the ability to allow 

The purpose of SOA is 

not to improve 

performance, and 

adding extra layers of 

software will 

inevitably have a 

performance impact. 

each of these to evolve over time as the business model changes. Because 

SOA is layered on top of application resources, it is never going to increase 

performance above the capabilities of the underlying systems. (Note, though, 

that end-to-end times could be reduced through the ability to execute multiple 

tasks in parallel instead of sequentially.) 

The purpose of SOA is not to improve performance, and adding extra layers of 

software will inevitably have a performance impact. However, everything has 

its price, and IT must continue to meet the processing workload and 

performance expectations of the organisation, SOA or not. 

Much of the performance overhead of SOA stems from the use of Web services. The role that Web services 

plays is to isolate the SOA control and run-time environment from the physical properties of the underlying 

services. With Web services, the ESB neither knows nor cares what physical platform a service executes 

on, what operating platform is used, or which language has been used to create the application. This 

virtualisation is the source of the overhead with which we must contend. 

Web services itself is built on top of XML, this being the commonly-accepted standard for technology-neutral 

messages. The message body itself may become quite large, since a common way of exploiting SOA is for 

the same basic message to be passed to each service in turn, with each enriching the message with the 

results of its own activity. (In this way the message itself retains the context 

required for subsequent operations.) Hence, in a complex multi-step process 

the body gets larger and larger. Additionally, the SOAP envelope contains 

information necessary for the routing of the message plus optional extensions 

such as the style of messaging needed (e.g. guaranteed once-only delivery), 

privacy requirements, public and private key tokens for encryption, and 

potentially many more. 

Thus the Web services message load can add significantly to the network 

traffic, and particularly where encryption is needed, to the server overhead for 

processing the message. For any but trivial use of SOA, encryption is likely to 

be mandatory, even inside the firewall. Web services standards provide for 

encryption of just sensitive parts of the message, and this option should 

always be used to reduce the processing overhead. 

We need to consider whether to compromise the logical design to accommodate the performance needed by 

the business – but first there is a general rule in IT (which is re-learned in every new generation of technology): 

The golden rule: Do not optimise unless you have to! 

Thus the Web services 

message load can add 

significantly to the 

network traffic, and 

particularly where 

encryption is needed, 

to the server 

overhead for 

processing the 

message. 

In this case, Web services plays a major role in delivering the adaptability we seek from SOA. By abstracting 

away the physical details of an application we gain great freedom to replace applications piecemeal, 

outsource to a hosted service provider, provide hot-standby facilities for critical services, and many other 

important capabilities. If we discard Web services in favour of more compact technology-specific messaging, 

we lose these capabilities. Therefore, the best advice is to carry out performance modelling for the projected 

system capacity and decide if it is truly necessary to optimise. 


December 2006



Network appliance alternatives to traditional server/software 

implementation can offer cost/performance benefits. 

As described earlier, the ESB is really a suite of functionality that provides the means of moving the right 

message, in the right format, to the right recipient, in the right sequence. Commercial ESB suites are themselves 

built on SOA principles so that functionality can be added without a major reconstruction of the environment. 

This is important for the ability to add governance features and other ‘optional’ properties to a live SOA 

environment. The architecture also means that services provided by the ESB can be removed or replaced by 

functionally-equivalent alternatives. This has enabled a sub-market of ESB 

features deployed as network appliances rather than as software on a server. 

This idea is a logical extension of several mainstream security features commonly 

implemented as appliances. In particular, firewalls were originally implemented as 

software on conventional servers. but have been implemented as network 

appliances as the mainstream deployment mechanism for many years. It is 

simply more cost-effective to deploy firewalls in this way. 

By the same logic, several services provided by an ESB might be more costeffective 

if removed from a general-purpose server and implemented instead as 

network appliances. Potential candidates for this treatment are XML firewall, XML 

schema parsing, XML encryption/decryption, content-based message routing, and 

possibly other functionality also. This approach offloads tasks from the server to 

free its resources for business-related work, and moves the network-centric logic 

down into the network itself. Several vendors provide products that are well-worth evaluating as part of an overall 

strategy for dealing with SOA performance. Again, because of the adaptability that SOA offers, these appliances 

can be retrofitted to an established SOA environment. 

Although the use of network appliances implies an additional expenditure, their use can defer the need for extra 

server capacity. The main advantage, however, is that they can make a significant difference to performance and 

throughput without having to compromise the SOA agility. 

Run-time deployment of SOA-based applications does not always mean 

using Web services. 

Any discussion of SOA tends to start out with the assumption of the use of Web services throughout. Wherever 

services are to be integrated that are outside of the corporate environment. it is still advisable to use Web services 

as the underlying mechanism. This is because security concerns can be dealt with more directly through the 

common standards provided by Web services, and because any use of proprietary interfaces will leave the parties 

unable to change their services without impacting their partners. An exception to this would be where a particular 

industry has already established standards that pre-date Web services (and 

preferably use a private network for communication rather than the public Internet). 

At the outset, it is 

worth pointing out 

that both .NET and 

J2EE are suitable 

deployment 

infrastructures for SOA. 

...several services 

provided by an ESB 

might be more costeffective 

if removed 

from a generalpurpose 

server and 

implemented instead 

as network 

appliances. 

For internal deployment, there are several alternatives to the Web services paradigm. 

At the outset, it is worth pointing out that both .NET and J2EE are suitable 

deployment infrastructures for SOA. Within a .NET only or J2EE only environment, 

there are few adaptability compromises to be made, in return for which significantly 

reduced overheads can be expected. The objects natively exposed by Java and .NET 

may still take part in an orchestrated sequence of events as part of composite 

applications or automated business processes. However, security issues must be 

managed in the traditional way rather than letting ESB products be guided by the Web services policy statements. 

Greater constraints will be experienced if it is subsequently required to replace a native .NET or J2EE service with 

hosted software as a service. Common Object Request Broker Architecture (CORBA)-based applications have 

similar properties to J2EE and .NET in terms of their use within SOA. However, there are few substantial IT 

environments where it would be possible to implement a wide-reaching SOA solution within a single technology. In 

a mixed environment, without the use of Web services, the ESB has to be made aware of the physical properties 

of the services. This may be of little consequence in the initial deployment, but will be a constraint of future 

adaptability when the time comes to replace legacy applications. 




There are also successful SOA deployments using Z/OS IBM mainframes (albeit using a Web services 

mechanism), ‘green-screen’ UNIX applications that pre-date client/server, and even very elderly proprietary 

operating environments. However, we should differentiate between enabling these legacy platforms for use in a 

SOA, and deploying a non-standards-based approach. Using adapters to expose the underlying service 

functionality of legacy applications is part and parcel of the SOA model, provided that the adapters offer a Web 

services messaging interface. Adapters might be Commercial Off-The-Shelf (COTS), customised COTS, or entirely 

custom-built. Technology that bears a striking resemblance to the screen-scraping used by early client/server 

deployments can be used to obtain access to applications for which no other mechanism is available. 

Many vendors that support legacy products are very happy to provide Web services adapters to their 

applications, or connectors to the underlying platform. For example: 

 

 

 

IBM’s CICS transaction server can operate in a SOA environment in a number of different ways. First of 

all CICS directly supports Web services interactions, but can also work with WebSphere application 

server clients via Java Connector Architecture (JCA). It can also operate with an ESB, as well as a Web 

services gateway, providing considerable flexibility to those organisations that need to continue to use 

their legacy CICS systems, but want to enable reuse within SOA projects. 

During 2006, BEA Systems announced that it was enhancing its legacy Tuxedo infrastructure with SALT 

– Service Architecture Leveraging Tuxedo. BEA’s SALT is a way of service-enabling its Tuxedo platform 

by providing a native Web services layer on top of Tuxedo. Tuxedo is built on BEA’s Application-to- 

Transaction Monitor Interface (ATMI) architecture, allowing both C and COBOL programming. It is a 

transaction server built on UNIX, comparable to the IBM mainframe CICS transaction server, suitable for 

complex, transaction-based applications such as billing. What SALT brings is like an ‘ESB for 

transactions’ – it implements an XA standard, so that transactions either happen or not – there is no grey 

area (in other words one part of a transaction is automatically undone if the overall transaction fails to 

complete). It offers two-phase commit capability. 

Oracle is introducing the idea of Service Beans in its next version of the Oracle E-Business Suite. These 

will allow the underlying services within the suite to be deployed in a range of different ways – as EJB 

Session Beans; as Web services; or as co-located Java API. The service bean encapsulates the 

implementation details, and provides a consistent and easy-to-use interface, allowing them to be used 

as building blocks within a SOA. Such services are then available for BPEL process management, and 

they can consume and output Service Data Objects (to the JSR 235 specification). 

High-performance SOA need not be an oxymoron, but good 

understanding of issues is needed. 

This Section has outlined some of the performance challenges and some of the potential solutions. The 

question now is how to achieve the best compromise between agility and performance. The natural 

inclination within IT (charged for many years with squeezing a growing workload into a diminishing 

technology budget) is to look for the high performance solution. However, this 

is not the best approach in these new circumstances. 

The challenge here is 

to model the services 

that are meaningful 

to the business and 

then map these to the 

underlying 

application(s) that can 

support the service. 

Since SOA is architecture, we should be able to separate the logical design 

from the physical. The logical service architecture should be designed only 

considering the business requirements to ensure the maximum reuse of 

services. The challenge here is to model the services that are meaningful to 

the business and then map these to the underlying application(s) that can 

support the service. This may not be a one-to-one mapping – in order to 

satisfy the requirements of a business service it might be necessary to 

integrate several applications. Equally, each application is likely to provide a 

range of functionality that is best divided between logical services. 

The scope of this analysis should be constrained to the project in question, but using the business analyst’s 

experience and insight to determine where reuse will be possible in subsequent projects. 

The next step is to form a model for the likely performance characteristics of each service, and to use 

capacity planning tools to determine the infrastructure requirements to support the anticipated workload. 

The market for SOA capacity planning is maturing well, with a variety of competent products now available. 


December 2006



The capacity planning exercise will show where there is a need to apply optimisation. The minimum 

optimisation to meet targets is a more appropriate target than reducing the run-time overhead to the 

absolute minimum. The first targets for optimisation should be the situation where a number of small, lowlevel 

services are aggregated to create a widely-used service, and where there is little or no requirement for 

direct use of the low-level services. In this instance, direct native calls to the low-level services can be made 

with little adverse impact. In fact, this interchange could bypass the ESB entirely, with the high-level service 

making direct RPC calls to the required applications. 

The important step in this optimisation is that the original logical model should be retained, and the nature 

of the optimisation, together with the reasons for the decision to optimise should be recorded. The Chief 

Architect should review all such cases to ensure the best compromise has been reached. 

Other optimisation considerations include: 

Ensuring that encryption is truly necessary, and only applying encryption to the sensitive portions of a 

large message. 

 

 

 

Consider breaking multi-function services down into several simpler single-function services (as the 

simpler service will have simpler and smaller message requirements). 

Consider using alternative messaging protocols to HTTP for inside-the-firewall deployment. 

Consider the use of Binary XML or compression to reduce the size of XML messages. 

Consider physically relocating services to minimise network overheads. 

Whatever trade-offs are made for the sake of performance, it is important that it is not treated as a one-person 

decision that is the responsibility of a technical architect. The impact on agility and the ability to meet the 

forward plans of the business must be considered, alongside each compromise of the ideal architecture. 

SERVICE-ORIENTED DEVELOPMENT 

CATALYST 

A key challenge to organisations when getting to grips with SOA is in the development area. It is no longer 

about application development, it is about service development, yet understanding the impact on the 

development function can be complex. 

SUMMARY 

There is a SOA lifecycle in the same way as there is an application development lifecycle. 

Planning the infrastructure for SOA will require careful thought. 

Services within a SOA may be combined in unforeseen ways. 

SOA and Agile can be complementary. 

ANALYSIS 

There is a SOA lifecycle in the same way as there is an application 

development lifecycle. 

Development pressures in the past have always meant that applications are developed with little thought 

for reuse, change, or integration. This mindset will need to change in a SOA environment. However, it is 

clear that there is a lifecycle for SOA just as there is for earlier types of application development. 




Requirements analysis needs to establish what the service needs to do, its scope, and potential usage 

patterns. Given the much closer alignment of business needs that SOA demands, services will usually be 

business-relevant – however, there may also be infrastructure services needed to support a SOA. 

Infrastructure vendors in particular are identifying this need – for example, BEA Systems has coined the 

Requirements analysis 

needs to establish 

what the service 

needs to do, its scope, 

and potential usage 

patterns. 

phrase Micro Services Architecture to cover the way it sees the need break up 

its infrastructure tools into smaller pieces that can then be assembled to meet 

the diverse requirements of its customers in the future. 

The design and development phases may require platform-specific issues to be 

taken into account, such as the choice of programming language, and the 

development environment to be used. A number of the platform vendors provide 

SOA development tools (such as JDeveloper from Oracle), and there are 

additional vendors such as Skyway Software that offer specialist tools here. 

Developing composite applications in a SOA should, of course, focus heavily 

on reuse of existing services wherever possible, and this mindset must be 

encouraged from the outset. Sometimes it may not be possible to serviceenable 

an existing application, and it will need to be re-written in a new way. 

In addition, there will always be the need to create some completely new 

services. The mantra should always be to reuse first, then potentially recycle… 

and only finally develop new services from scratch. 

At the service deployment phase, a number of considerations come into play 

such as installing and configuring distributed components, service interfaces, 

and the necessary middleware products; and all of this from development to 

test to staging to production environments. 

Once services are 

deployed, ongoing 

administration will be 

required to include 

service monitoring 

and auditing, and to 

control the whole 

change management 

process. 

Packaging of all the artefacts required is unlikely 

to be fully present, given that the full breadth of 

the SOA paradigm is still evolving. 

The design and 

development phases 

may require platformspecific 

issues to be 

taken into account, 

such as the choice of 

programming 

language, and the 

development 

environment to be 

used. 

Once services are deployed, ongoing administration will be required to include 

service monitoring and auditing, and to control the whole change 

management process. Whilst it may not be highly desirable to allow a service 

to change over time, in practice it may be impossible to avoid this. The OASIS 

SOA Reference Model allows for versioning of services. Doing this helps to 

manage any interface changes. Clients of a service then have to be able to 

make a decision about which version of the service (with the older or the 

newer interface) they need. 

An iterative process to the development lifecycle will be necessary – it is unlikely that any organisation will 

get it all right the first time, even if they use the services of the most experienced vendors and services 

providers. It will be valuable to get a widespread understanding up-front so that not too much time is wasted 

doing things the wrong way. 

Not all services will be created in-house – in fact, it may be that the skills required at first are not available 

in-house. All the major Systems Integrators are investing heavily in SOA training and development, and 

many have already assisted in successful pilot projects. 

The optimal way to proceed with service-oriented development is to combine a top-down and bottom-up 

approach together. An imbalanced approach could risk ‘paralysis by analysis’ if too top down, and service 

creation for the sake of it can be too far the other way. 

Roles 

A complex SOA project is likely to entail a wide range of different skills that will require an understanding 

of the different roles needed when developing services within a SOA. A lot of this comes down to basic 

people issues – to ensure that there is an understanding of services at the right level. Service-oriented 

development can be a major challenge if developers do not understand the concept, and reuse will be 

minimal unless the services are designed in the right way. 


December 2006



IBM recommends that the development phase of a SOA project will require a number of roles, such as 

Software Architect, Developer (this may include application developer, component developer, and 

integration developer), Test Engineer, Test Architect, and Test Implementer. Whilst this may appear overkill, 

and sometimes these roles could be filled by one or two people, the identification of the different roles 

needed may help assemble the best project team. 

Planning the infrastructure for SOA will require careful thought. 

Planning for a SOA deployment will require capacity planning and hardware planning where estimates of 

service volumes need to be considered, as well as usage patterns. Such planning will not be straightforward; 

a SOA infrastructure is made up of many components, such as middleware, mediation and orchestration 

brokers (which may be part of an ESB), infrastructure integration services (such as for security, monitoring, 

and exception management), as well as BPM engines, and of course, the underlying network infrastructure. 

This may itself have many components that impact performance and capacity 

including routers, switches, traffic load balancers, and encryption (such as 

SSL) and transformation XML Stylesheet Language Transformation (XSLT) 

accelerators. 

When carrying out capacity planning for SOA, performance is probably one of the 

easier aspects to measure, yet even that can be a challenge given the distributed 

nature of SOA. Estimating the number of transactions that are likely to occur, the 

number of users accessing a service is also quite measurable. 

Composite applications may be made up from a number of services, and these 

may not all have the same SLA (especially over time), which may of itself lead 

to interesting decisions as to how to scale up the required infrastructure. 

A common approach would be to over-engineer the infrastructure – and certainly it would be wise to allocate 

budget to hardware at the outset of a SOA project. But some of the infrastructure elements can be very 

expensive if under-utilised (BPM engines are a particular example here). A pattern-based approach to 

capacity planning is one good option, taking into account a range of access patterns to the services that 

encompass simple and complex scenarios. 

A simple pattern might cover a validation service (using a schema, for example), a transformation from one 

format to another, and then publishing a message onto a queue. A more complex pattern might add in lookups 

and process management capabilities. The capacity planning process should then test the various 

scenarios and record results in order to then extrapolate based on peak load estimates. This peak should 

then be projected forward over time to forecast where additional capacity might be required in the future. 

Another part of infrastructure planning is to consider failover and disaster recovery – establishing how 

alternative infrastructure can be utilised and what the service failover options should be. In any serious 

project, failover should be designed in, and then tested to ensure that it works. 

Services within a SOA may be combined in unforeseen ways. 

When carrying out 

capacity planning for 

SOA, performance is 

probably one of the 

easier aspects to 

measure, yet even that 

can be a challenge 

given the distributed 

nature of SOA. 

A key issue in testing within a SOA is that it is not always clear, when designing a service, how it is going 

to be used. A service could be reused and combined with other services in ways that are not foreseen at 

the development phase, so services will therefore need rigorous testing to ensure that when the 

unpredictable happens, they cope. Testing in a SOA will encompass the ability to test Web services but also 

other types of service. 

As with any type of application or service, one of the first tests should be whether the service does what it 

is intended to do, in terms of the capabilities that it is intended to deliver. Such functional testing will also 

need to be carried out but issues such as unit testing, system testing, load testing, and overall performance 

all need to be addressed when testing is carried out, and where a service may have multiple bindings, each 

will need to be tested. 




From a functional perspective, where a service has a user interface, then usability testing may also be 

appropriate. Testing may also involve using the same types of communication infrastructure (for example an 

ESB) as would then be used in production, and here there may be issues with licensing, where development 

and testing can be carried out within the terms of a licence, but it may require additional payment for 

production. 

Performance testing will be another area that should have careful attention paid to it – especially where 

significant use is made of XML messaging. Although performance is improving over time, and various 

technologies exist to speed up XML parsing, XML is still highly verbose. One method might be to enable the 

message to be parsed in phases, so that the first part of the message can be acted upon whilst the rest of 

it is still being processed. However, recent benchmarks indicate that performance may be less of a major 

issue than it used to be. 

A number of test tools are starting to emerge, and the well-known testing vendors are all starting to work 

on testing for SOA, including Parasoft and Mercury. Another aspect for testing within a SOA will be 

simulation, which will be especially relevant for services that have not yet been created or are not currently 

available. The automatic generation of tests will also be valuable within a SOA project. 

SOA and Agile can be complementary. 

Agile software development first started to take off during the late 1990s, when Kent Beck promoted 

Extreme Programming (XP); a set of values, principles, and practices for planning, coding, designing, and 

testing software. Agile software development approaches tend to have a number of common values, such 

as frequent inspection and adaptation, frequent delivery (with some proponents advocating nightly build 

programs), collaboration and close communication with business users, and the emergence of requirements 

(incremental), technology, and team capabilities rather than defining these up-front. 

Developing SOA applications might appear to be an area where design all needs to be conducted up-front, 

and therefore more compatible with a traditional ‘waterfall’ methodology rather than a more agile, iterative 

approach. 

However, in practice the two approaches are quite complementary. In a SOA the interfaces of a service will 

need to be carefully planned and designed – and should then remain relatively stable. However, Agile 

methodologies and software engineering practices can still be applied to the development of applications 

that expose external service interfaces. It will be necessary to think very carefully about interfaces that are 

being exposed at the end of any particular iteration. If, after a few iterations, a client needs one of these 

interfaces to be changed, then it may well have to be changed, ensuring that the change has minimal 

impact through techniques such as mediation and versioning. 

IBM’s Developerworks Web site has some valuable articles illustrating how Agile can complement Web 

services development in particular, and SOA on the whole. 

A guiding principle of SOA is that services should ideally follow the same design philosophy, and once 

created, assembling them should require less skill than other development models – assembly is often seen 

as within the capabilities of a business analyst. Hence, service-oriented development will facilitate a much 

more agile business in the future. 


December 2006



SECTION 2: 

SOA in Action 

Butler Group 

a Datamonitor Company



SOA CASE STUDIES 

CATALYST 

Studying the practical experiences of organisations that have embarked upon a Service Oriented 

Architecture (SOA) strategy is a useful way to gain information about the methods employed, the 

outcomes achieved, and the lessons learnt. 

SUMMARY 

IBM – Standard Life. 

ANALYSIS 

IBM – Standard Life 

Standard Life is an assurance company headquartered in Edinburgh, Scotland. It employs over 12,000 people 

and manages more than UK£105 billion in assets for over seven million customers worldwide. Its portfolio has 

expanded to include investments, banking, and healthcare offerings that are delivered through four 

independently operated organisations within the UK: Standard Life UK, Standard Life Investments, Standard 

Life Bank, and Standard Life Healthcare. Standard Life also has international operations in Canada, Germany, 

Ireland, India, and China that contribute approximately 30% to the company’s worldwide new business. 

Business Challenges 

Standard Life has seen the speed and complexity of operating its business increase. The majority of its revenue 

is now delivered from Independent Financial Advisors (IFAs), many of whom use industry-sponsored portals to 

obtain product and price comparisons from multiple providers on behalf of their customers. Pressure from 

competitive aggregators, which can provide IFAs with a comprehensive, single view of customer holdings, is 

on the rise, as are customer expectations for faster service and on-line access to personal financial information. 

Whilst Standard Life has always enjoyed a good reputation for customer service, it recognised the growing need 

to be even more responsive to its customers and to drive loyalty within its many business channels. 

Standard Life was looking for ways to make working with its business channels simpler and to improve 

customer service, but reducing costs was also a priority. For Standard Life, cost reduction had implications that 

went beyond contributing to its own bottom line, with cost-cutting also potentially improving its standing with 

IFAs. If Standard Life could lower its cost of doing business, IFAs would have an opportunity to lower theirs, 

helping IFAs improve their margins, which could foster IFA loyalty and gain a competitive edge. 

SOA Strategy 

To address these challenges, Standard Life looked to establish a new, more flexible architecture that would 

enable it to leverage its existing business process and technology assets. In 1995, Standard Life had 

standardised its data access and catalogued its reusable data services. Then, between 1999 and 2001, 

Standard Life defined its application development architecture and the framework that would support it. 

This became the blueprint for what is now the company’s SOA approach, which provides the foundation for 

Standard Life’s implementation of Web services. 

The technology framework componentises business processes and the IT functions that support them in order 

to extend those processes to constituents, both internally and externally. Web services are used to provide selfcontained, 

modular applications that are designed to work together without relying on custom-coded 

connections. They can be combined and recombined to meet the changing needs of the business. This 

flexibility and reuse leads to shorter development cycles with less effort expended, resulting in substantially 

lower costs. The list of Standard Life’s reusable business services includes verify identity, provide life cover 

information, and create an outgoing document. 

32 Section 2: SOA in Action 

December 2006



In 1999, Web services standards were just emerging. Therefore, to best meet its internal needs, Standard 

Life developed internal XML standards that are analogous to today’s Web services standards. Standard Life 

continually evaluated Web services standards as they matured, and is now beginning to implement these 

new standards as XML-enabled reusable services that are available over a messaging layer to agents and 

business partners. 

Standard Life’s service-oriented approach has allowed the company to exploit its existing IT assets and 

applications, and to align technology with its key business objectives. Today, Standard Life’s SOA has been 

implemented across all of the major UK operations in the Standard Life Group. At the core of the SOA is 

IBM WebSphere Message Broker, a standardised messaging technology that allows Standard Life to 

integrate its various hardware, software, and platform systems. Web services are enabled by IBM Rational 

Application Developer for WebSphere and IBM WebSphere Application Server. 

Outcomes 

Standard Life has seen significant benefits as a result of implementing SOA and reusing business services. 

Over 300 business services, such as the ability to provide agent details, produce statements, and maintain 

addresses, are available for reuse by IFAs, agents, and customers. The company can easily deploy new 

combinations of services, thereby simplifying the process of working across its various business channels, 

and as Web services employ common standards, anyone, regardless of technology environment, can make 

use of the services available. 

Standard Life has also seen a significant decrease in client application development times. To date, the 

company has been able to reuse nearly 51% of its services, contributing to savings in excess of UK£10.4 

million in development costs. With so many services available for reuse, Standard Life’s IT department can 

combine services to develop and deploy composite applications more quickly, and as the business needs 

them. This makes Standard Life more agile and able to respond to new business opportunities with greater 

speed. 

By exploiting its catalogue of reusable services and making them available to business partners, Standard 

Life has been able to improve customer service. This, in turn, differentiates Standard Life from its 

competitors in the eyes of IFAs and customers using aggregate sites to evaluate and select providers. As a 

result Standard Life has been voted ‘company of the year’ by UK IFAs for the past five years. 

Since Standard Life has implemented a SOA using Web services, its transaction rates have increased 

without the need to increase operations staff, and by sharing business functions with key constituents, the 

company can ensure the consistency of information that its customers receive, whether that information 

comes from an IFA portal, Standard Life’s Web site, or from a conversation with one of the company’s 

customer service representatives. This consistency strengthens the Standard Life brand across multiple 

products and channels. 

Standard Life’s SOA has evolved over a 10-year period. During that time, the company has learned an 

important lesson – an effective SOA combines technology with business processes and people. Standard 

Life made the important shift from having a technology-centric culture to having a service-oriented one, and 

enhanced the skill sets of its employees, for example, by training them in XML, to support this culture shift. 

It also exploited and revitalised its existing IT and application assets to support its business processes, 

enabling Standard Life’s IT function to both support the organisation and contribute to the bottom line. 

Key outcomes included: 

Reuse of nearly 51% of existing services, resulting in savings of more than UK£10.4 million in 

development costs. 

 

 

 

 

Increased transaction rate by 900% without increasing operations staff. 

Improved responsiveness to market change and customer needs. 

Better customer service. 

Ensures consistency of information that customers receive, strengthening company brand. 

December 2006 Section 2: SOA in Action 33



This Report reveals: 

The essential considerations when planning and implementing 

SOA. 

How to use SOA to transform the way the organisation operates. 

The pitfalls to avoid when deploying SOA. 

Why becoming a process-centric enterprise complements SOA. 

How to separate the hype from the reality of SOA. 

A roadmap for the deployment of SOA. 

The importance of taking into account the impact of SOA on the 

wider IT environment. 

The challenges of developing data architecture to support SOA. 

How early adopters are gaining advantage from SOA. 

Butler Group 

a Datamonitor Company 

Analysis without compromise 

Headquarters: 

Europa House, 

184 Ferensway, 

Hull, East Yorkshire, 

HU1 3UT, UK 

Tel: +44 (0)1482 586149 

Fax: +44 (0)1482 323577 

Australian Sales Office: 

Butler Direct Pty Ltd., Level 46, 

Citigroup Building, 2 Park Street, 

Sydney, NSW, 2000, 

Australia 

Tel: +61 (02) 8705 6960 

Fax: +61 (02) 8705 6961 

End-user Sales Office (USA): 

Butler Group, 

245 Fifth Avenue, 4th Floor, 

New York, NY 10016 

USA 

Tel: +1 212 652 5302 

Fax: +1 212 202 4684

Planning_and_Impleme.. - didier beck weblog

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?