6312_soa_apr10_v2[1]

8/7/2019 6312_SOA_apr10_v2[1]

1/14an IT Management eBook

Managing aSuccessul SOADeployment orYour Enterprise

8/7/2019 6312_SOA_apr10_v2[1]

2/14

2 Practical Approaches or Creating anSOA-Based Organization

4 How to Avoid Common SOA Pitalls

6 The Nine Requirements or a SuccessulSOA Deployment

9 How to Manage SOA Success

12 Making SOA Sustainable

Contents

This content was adapted from Internet.coms CIO Update Web site. Contributors: Majid AbaMukund Balasubramanian, Theo Beack, Kamran Ozair, and Lionel Carrasco.

4 6

12

2

9

Managing a Successful SOA Deployment for Your Enterprise

8/7/2019 6312_SOA_apr10_v2[1]

3/14

8/7/2019 6312_SOA_apr10_v2[1]

4/14

8/7/2019 6312_SOA_apr10_v2[1]

5/14

4 Managing a Successful SOA Deployment, an Internet.com IT Management eBook. 2010, Internet.com, a division of QuinStreet, IncBack to Contents


In a perect world, the implementation o SOA in your

organization will help better align IT services with

those day-to-day business processes in which your

colleagues, customers, and partners engage. Yet, in

order to reap the promise o SOA, the prudent CIO must

wrangle both organizational and technology oriented chal-

lenges keeping an eye out or common pitalls.

In our years tackling SOA engagements or clients, weve

learned a lot about what to watch or. Here are some o the

most common sticking points:

1. Overlooking Security Incon-

sistencies. To assume vendors

and developers security prod-

ucts will work together is to risk

the saety and security o the

corporate data around which youare building your SOA.

Case in point: in the course o

a project integrating Apaches

WSS4J with Inravios SOA gov-

ernance stack or a large client,

we were asked to enable Web

Services Security (WS-Security)

or a range o services, rom en-

cryption to signature verication.

WS-Security, as you may know, is broadly accepted amongopen source developers as a security ramework, and

WSS4J is a popular implementation o WS-Security.

We successully enorced security at the intermediary level

until we routed to a secured .NET service. It turns out the

service expected an encrypted message. While we had

the required certicate, every time we hit the service it re-

turned a ault. Why was this? Well, WSS4J, in compliance

with WS-Security, uses xmldsig in the name space bu

the .NET service expected xmlds. Its but one example

o a small inconsistency with big implications.

2. Assuming Standards Are in Place. This is anothe

gotcha. Not all open source products comply with WebServices Interoperability (WS-I), though it is the broadly

accepted industry standard. This is problematic because

the basic concept o SOA is built atop a oundation o stan-

dards compliance. Until the day

comes when true adherence is

the law o the open source land

be on the lookout or clashes.

Another example: in one o ou

SOA projects, we used IONAs

WS-I-compliant Artix AdvancedSOA Inrastructure Suite as the

SOA backbone to expose a laye

o business services to be con

sumed by other applications in

cluding the open source Sugar

CRM/Jira or bug-tracking. Note

that SugarCRM and Jira both

expose their Web services using

Remote Procedure Call encod-

ing. All well and good except

Artix neither supports nor enorces RPC-encoded servic-es. Designing a method to handle RPC-encoded services

meant we ell six weeksbehind.

Pay close attention to the evolution o SOA specications

by reading trade journals and talking with peers at othe

organizations also working on SOA implementations. Such

research will tip you o to potential problem areas.

How to Avoid Common SOA PitfallsBy Mukund Balasubramanian

8/7/2019 6312_SOA_apr10_v2[1]

6/14



talk with stakeholders

cull business users wishes or the nished solution

give all departments a chance to weigh in they know better than anyone how day-to-day processes really work, what

problems need solving, and what business services are most

essential

translate between the two sides. You or someone you tapmay need to translate business requirements into developer

speak your team can understand. Expect to serve as reeree

as business and IT strive to get the project done right

enorce application testing. Test early and oten to make surethat line o business olks wish lists are being translated into

workable code

set realistic deadlines or integration with partners applica

tions. Insist that everyone on your team adheres to them.

6. Rushing to Deployment. The best SOA projects go live

ater a period o months not when the proverbial switch

is fipped. Start within one department so you can keep

tabs on service granularity (which we guarantee will change

over time) and fush out risk along the way. Enterprise-wide

SOA enablement doesnt happen overnight, but the ben-

ets it engenders will generate many positive eects o

your organization, rom IT to business stakeholders to cus

tomers and partners.

3. Using Poorly Thought Out Naming Conventions.

Heres another one where thinking ahead can save time

down the road. In an SOA, multiple versions o the same

services are consumed simultaneously by users all over the

organization that may reer to one business process, e.g.,

one service using dierent terms. Thats why its critical

that you decide early on how you will include the ollowing

parameters in the name-space o a service and propagate

your chosen naming conventions across the development

team handling your project:

the business domain the service belongs to

the service name that explains the business unction

the major version o the service.

4. Relying on Sub-Par Data. Many o the ailures weve

observed in SOA enablement projects originate rom poor

quality data. Careul cleansing o data sources would al-

leviate many o these issues and ensure inormation is ac-

curate and standardized (one example, New York, not

NYC, ny, New York City, etc.).

5. Cutting Corners on Planning. In SOA, as in other kinds

o complex technological projects, the devil is in the de-

tails. As CIO, you need to:

8/7/2019 6312_SOA_apr10_v2[1]

7/14



S

OA is an architectural approach that should be

looked upon as a journey within an enterprise.

Dierent enterprises embark on the SOA journey

with dierent aims. However, the general goalsconsistently include creating agility, enabling aster time

to market, and encouraging reuse within the enterprise.

None o these are easy to achieve and require a set o

guidelines that we will explore

in this article.

Depending on which article

you read or which analyst re-

port you believe, the time or

developing projects using

SOA has arrived. Many enter-prises are already in the pilot

phases o SOA projects while

others have actually moved

implementations into produc-

tion and have services that are

being consumed across the

enterprise.

Either way, what Ive outlined

here are the nine essential el-

ements o a successul SOAdeployment:

1. Careful ChoicesDierent enterprises embark on the SOA journey in di-

erent ways. Some take a holistic view o their business

processes and dene a service map, whereas others take

a more incremental approach and dene services as a by-

product o the dierent applications they build. When an

enterprise embarks on the SOA journey, there may be many

non-believers among the business and IT landscape.

The initial sets o services also require extra cost and e

ort. Hence, it becomes extremely important that the rst

implementation involving SOA

is chosen with care one that

has a high chance o success

and will help create the mo-

mentum and visibility or the

SOA journey.

2. Business AgilityOne o the key mantras behind

an SOA-based methodology is

that it enables business agility

One o the key ingredients o

how such agility is achieved is

by preparing a business archi-

tecture and enabling dierent

business processes via service

implementations. The tighte

the alignment between the

business architecture and service map, the easier it would

be to keep the two in synch. It will also ensure there is a

platorm available to absorb the ever-changing business

requirements and needs, enabling the wider goal o busi-

ness agility.

The Nine Requirements for aSuccessful SOA Deployment

By Kamran Ozair

8/7/2019 6312_SOA_apr10_v2[1]

8/14



3. More Than a RegistryReuse is the Holy Grail or an SOA-enabled environment.

Most sotware vendors will talk about their registry prod-ucts and how one can achieve reuse by ensuring all the

services are visible to the enterprise via a registry. That

may be a good practice but it is not sucient. In order

to achieve reuse, each service will have to be designed,

implemented, tested, and deployed in a manner that

takes a wider view o the requirements than the particular

project(s) it may be initially implemented or. There also

have to be mechanisms or incorporating newer require-

ments into services and, at the same time, maintaining

backward compatibility.

4. Developers Are People TooMany developers like to build things rom scratch and

sometimes they dont trust things developed by others. In

addition, many eel that it is easier to build something rom

the ground up rather than spend time understanding an

existing service and its usage scenarios.

There has to be a carrot and stick approach in order or

developers to line up behind an organizational commit-

ment toward SOA and reuse. There needs to be some ex-

plicit incentive or teams in order or them to reuse existingservices. The initial developers o a service as well as initial

teams that try to reuse them will go through some pain.

They need to be aptly compensated or their extra eort.

Similarly, any team that shies away rom using an existing

service should have a lot o explaining to do.

5. GovernanceWhether it is dening the design principles behind ser-

vices, a security strategy or services, reuse incentives, or

a clear ownership structure or services, governance has

to be thought through rom the initial implementation o

services within the enterprise.

A governance model or SOA should dene guidelines

at the architecture level, initiative level, and operational

level. It encompasses best practices and policies and re-

views mechanisms, tools, and methodologies as well as

the organizational structures need to enorce the dieren

mechanisms.

6. Managing a Shared InfrastructureAs part o implementing multiple applications in an SOA

paradigm, co-deployment o applications on a shared in

rastructure is a common theme. The applications tend

to use a common set o services and are most likely to

be built on the same architecture. Application boundar

ies also become blurred in SOA because one project uses

services provided by another.

In such an environment, it is imperative that strong controlsand policies are in place. Aspects like deployment o new

services, conguration management, versioning, mainte-

nance and upkeep, and batch and update cycles have to

be thought through with a shared environment in mind

Inrastructure and policies have to be designed so they are

able to satisy the most stringent requirements across the

dierent applications.

7. Holistic SecurityA cohesive security policy and approach has to be thought

through rom the onset. Many enterprises have existingsecurity repositories they want to leverage in an SOA envi-

ronment. On the other hand, many o the products that are

typically deployed in an SOA environment come with their

own security enablement.

A holistic SOA security approach will answer questions

like:

What will be the approach or authentication?

What kinds o security standards will be leveraged?

How will existing security assets get integrated?

What approach will be taken or message-level security?

How will ne grain authorization get implemented keeping a

shared application environment in mind?

8/7/2019 6312_SOA_apr10_v2[1]

9/14



8. PerformanceApplication perormance is usually calibrated by the needs

o its distinct user community. However, when a serviceis being implemented its uture usage scenarios may not

be visible. Needless to say that services perormance

becomes a very important actor in ensuring it is used

across a wider set o applications. Each service needs to

meet the most stringent perormance requirement across

applications.

9. MetricsSuccess or an SOA initiative needs to be measured and

tied to broader business goals. Questions like the ollow-

ing need to be answered beore any level o success canbe claimed:

How much reuse actually happened due to SOA?

Was there a reduction in time to market or certain

business priorities?

How reliable was the overall SOA environment?

Were the SLAs that were dened or the servicesproperly met?

Have the perormance and scalability requirements

been met?

Some o these questions may be answered via spread

sheets, but many will require the proper deployment o

tools and processes to provide reliable answers. The suc-

cess o the SOA journey should be quantiable via metrics

rather than let to perceptions ormed due to incomplete

inormation.

While some o the above guidelines may be applicable orany sotware development liecycle, an SOA environment

imposes a new outlook given the reuse and agility guide

line requirements.

8/7/2019 6312_SOA_apr10_v2[1]

10/14



Imagine you recently completed the rst successul

phase o your Enterprise SOA Master Plan. Services

are distributed throughout the enterprise, linking leg-

acy applications with your ERP and CRM applications

and are presented to your business users via a new portal

interace.

The users love the ease with which they can access all this

inormation and conduct their daily tasks. Now that they

know what is possible, they want more, and you are ready

to give them what they want.

Ater all, you have just prov-

en that SOA is more than a

mere buzzword.

However, no one has yet

told you there is a problem.

This initial, highly success-

ul project has introduced a

new level o complexity into

your IT organization. Mono-

lithic and heterogeneous

applications running in iso-

lation or many years have

suddenly become crucial

components in a more com-

plex organism held together

by the principles o SOA.

The IT architects have very

detailed architectural dia-

grams to describe it all, the developers wrote thousands o

lines o code to make it all work, and the integration team

has congured a complex Web o message inrastructure

to ensure that every message is guaranteed to be deliv-

ered to the right application What could potentially be

amiss in this picture?

To illustrate let me pose a ew questions:

How many services are currently deployed withinthe organization?

O these services, how many are currently up and running andhow many are experiencing problems?

How well does every service

perorm its given task? Are

your end-users waiting lon

ger to achieve a given task?

How stable are these ser

vices? How are some o these

newly created business pro

cesses and applications aected when a crucial service

(or services) malunctions?

Can you conduct an impacanalysis to measure the po

tential impact o changes to

an existing service or set o

services?

By using the principles o

SOA you have been able to

solve a complex problemand by doing so introduced

additional complexity into

your IT inrastructure. The

challenge that you now have to ace is how to manage

that complexity.

How to Manage SOA SuccessBy Theo Beack

8/7/2019 6312_SOA_apr10_v2[1]

11/14



ApproachSOA Governance is a discipline that, in an ideal world,

should be established early on in the SOA liecycle. It isnever too late to implement good policies, procedures,

and technology to assist with the management o the

reshly implemented SOA project.

Consider governance a best practice whereby one trans-

orms lessons learned into sound policies, guidelines, and

procedures with the aim o establishing a mature SOA

ecosystem.

Here are ve guidelines I consider essential to good

governance:

1. Establish an SOA Competency Center. This is a cross-

unctional team o key people that represent dierent dis-

ciplines within IT. By establishing such a group you acili-

tate communication between the various groups, ensuring

that everyone is represented and that every aspect o the

SOA gets proper consideration.

Furthermore this group can be instrumental in establish-

ing organizational standards, setting guidelines, and cre-

ating blueprints. This core group can also disseminateknowledge to new groups that need to adopt the SOA

approach.

2. Experience is a good teacher. Blueprints and best

practices can be very good teaching mechanisms. They

are a tangible way in which everyone involved in the SOA

implementation can benet rom the work that has been

done beore.

Too many times development teams have to reinvent the

wheel in order to solve a particular problem. Identiy anddocument those solutions that work well and turn them

into patterns that can be used repeatedly.

By making a particular approach repeatable you are able

to reduce risk, shorten development time, and also de-

crease the cost associated with the overall project. Like-

wise, it may be just as important to document those ap-

proaches that dont work well or which may have ailed. By

documenting these so-called anti-patterns one is able to

prevent mistakes rom being repeated.

3. Use an SOA Repository. Services are by denition re

usable and sel-describing, but dont be deceived by this

oversimplied view.

I services are not properly documented and made acces-

sible in a consistent manner, they could become just as

unusable as some o those legacy applications.

Accomplishing such simple tasks as establishing the exact

nature o a service, obtaining the latest service descrip-

tion, or determining the owner o a particular service may

become quite a daunting task i services management in

rastructure is not put into place. This is where an SOA re-

pository can play an important role. It can become the o

cal point where all services can be documented, searched

and accessed.

4. Monitor Quality of Service (QoS). Bring predictability

to your SOA by implementing service management acili-

ties. What you need is the capability to maintain end-to-

end visibility into your services inrastructure via the abilityto dene SLAs (service level agreements), measure services

operation and response levels, analyze service usage and

resource utilization patterns, and proactively be alerted o

potential and imminent service ailures.

Stability is the hallmark o a mature system and through

the eective management o your deployed services (and

related inrastructure) you can bring a great measure o

stability to your SOA.

5. Manage the SOA Lifecycle. Create a disciplined andwell-managed SOA liecycle. In all other areas o IT this

kind o discipline is well established and maintained. SOA

should be no dierent.

Implement tools and procedures that will help manage

the services development, testing, quality control, deploy

ment and maintenance processes.

8/7/2019 6312_SOA_apr10_v2[1]

12/14



Acknowledging the complex nature o SOA and taking the

appropriate steps to manage this complexity is a crucia

step toward the successul development, implementation

and maintenance o an SOA. My advice is to plan or SOA

success. Plan to be hugely successul and in preparation

consider how you will govern the next generation o busi

ness applications.

As part o the liecycle create a services approval process,

ensuring that services are tested or standards compliance

and services are put through a comprehensive vulnerabil-

ity, interoperability, and regression testing process. Imple-

menting these measures will assist in elevating the overall

maturity and robustness o your SOA implementation.

Implementing an SOA entails more than just implementing

a ew services or using an ESB (enterprise service bus). SOA

may start out simple, but it inherently introduces complex-

ity into the IT organization. This is mainly due to the nature

o the problems that we are attempting to solve.

8/7/2019 6312_SOA_apr10_v2[1]

13/14



The rampant use o web services, and the conse-

quent adoption o SOA, makes keeping up with

the rapid changes in technology all the more

critical because these technologies are unda-

mental to the success o a business.

SOAs appeal isnt dicult to understand. While there is nowidely agreed upon denition other than its literal transla-

tion, SOA is an architecture that

relies on service orientation as its

undamental design principle. In

an SOA environment indepen-

dent services can be accessed

without knowledge o their under-

lying platorm implementation.

Adopting SOA is becoming es-

sential to delivering the businessagility and IT fexibility required

by todays enterprises. SOA de-

livers a major competitive ad-

vantage by increasing organiza-

tional agility, allowing companies

to easily assemble and modiy

business processes in response

to market requirements. It also

oers greater fexibility in the

way computer systems can be used to support the busi-

ness while lowering implementation costs by increasingreusability.

With SOA, IT assets are aligned to business services in

a standard, open, and fexible architected ashion. The

promise and goal o SOA is that it can transorm the IT as-

sets o a business, making it possible to do more with less,

and aster while keeping pace with technology changes.

Sustainable SOAThe idea o sustainability isnt really a new concept but its

vital in the process o strategic IT thinking. What it means

is that its not enough to think about technology in the

context o solving a problem or addressing a need that

you have today. To deliver sustainable value rom IT you

have to think about how technology will continue to address your needs going orward.

Understood this way, SOA is only

viable in the long term when you

consider the whole liecycle o

services over time as they are

created, changed, and even re

tired. And thats where sustain-

ability comes in. I youre not

thinking ahead to how you wil

deliver that consistent experi-ence youre not thinking in a sus-

tainable way. But the question o

sustainable SOA is moot without

proper governance.

SOA GovernanceCompanies embarking on the

path to SOA start with a rame-

work to guide them through decision-making, accurate

tracking, improved serviceability, and better communica-

tion. This path is called SOA governance.

Essentially, SOA governance is the mechanism to ensure

that the decision making structure is solid, evolution o

business process and technology is encompassed, rela-

tionships between services and parties are managed, and

that there is compliance with the laws, policies, standards

and procedures under which an organization operates.

Making SOA SustainableBy Lionel Carrasco

8/7/2019 6312_SOA_apr10_v2[1]

14/14


SOA governance is an extension o IT governance that

ocuses on the liecycle o services and composite appli-

cations in an organizations service-oriented architecture.

Because SOA applications are intrinsically ragmented,

they introduce new governance challenges. But with the

proper business semantics, policies, principles, standards,

procedures, and processes in place, businesses can realize

the ull benet o service orientation.

An eective SOA governance platorm not only helps busi-

ness and IT teams better identiy which projects contribute

most to business goals, but it also empowers employees

to work and collaborate more eciently by clearly dening

their roles and responsibilities.

Without SOA governance, SOA has little chance o be-

coming sustainable. In a study on SOA and governance,

industry analyst rm Gartner concluded that the most

common reason or ailure in SOA projects encompass-

ing 50 services or more was a lack o working governance

mechanisms.

The bottom line is that any enterprise that ails to realize

the importance o an eective governance and sustain-

able structure may not stand to benet much rom anSOA transition.

Sustainable StrategiesYour SOA approach should align processes governance

and inormation technology with business objectivesYou should view your organization as a system, and see

its technology, inormation, and processes as components

o an overall structure. You should consider that only the

proper articulation and alignment o processes and busi

ness objectives will make an SOA implementation sustain-

able, manageable, and protable.

The key to success in implementing a sustainable and unc

tional SOA takes into account our main components:

Design a ramework that integrates throughout the liecycle

o SOA. This includes people, processes, and technology do

mains, all around the goals o supporting business processes.

Assess the IT maturity stage, business goals, and technical context constraints o the enterprise.

Create a plan that covers the design, construction, deploy-

ment, and operation o artiacts, principles, policies, etc., to

help IT adopt and evolve an SOA.

Produce a sound adoption roadmap encompassing the To

day and the To Be scenarios.

By using a systemic approach you get a clear advantageto working independently o the dierent legacy sotware

systems you might have, as well as optimize the solution

and ensure sustainable protability. The result will be sus-

tainable SOA.

6312_soa_apr10_v2[1]

Documents