A World of 2.

We bought expensive Enterprise

Service Bus (ESB) infrastructure, so
rather than investing in staff training,
the board assumed their developers

Assumptions we’ve already implemented SOA.

3. We’re already an SOA company! “We
could learn about SOA on the job.

That Make an did one project, so we know how

these things work.”
Introduction to the Project
(See assumptions 1 and 6)

SOA Project the • Project-specific assumptions:

On the first Monday morning of
each month, project managers attend a

Perfect Storm— 4. How different can SOA be from

what we’ve been doing already? My
portfolio meeting to hear about news
and initiatives proposed by upper man-

and What You engineers have been developing

software for decades—some of them
agement. In these meetings, project
managers are assigned to new projects

Should Know even in Java!

5. The implementation doesn’t need to
that bring in revenue from external
partners and customers.

About Them be agile. “A waterfall model works

great and is what we know.”
6. Because it’s SOA, the project is easier
to manage.
Recently, one of the company’s major
customers decided to start a prototype:
moving legacy COBOL code into an
SOA. “After hearing that SOA cuts down

By Clemens • Technological assumptions:

our maintenance costs and enables us to
have shorter response times to change

Utschig-Utschig 7. SOA is about Web Services, since

SOA uses SOAP. “Someone must
have forgotten the ‘P’ on the end.”
requests, we decided to invest in this
initiative,” the customer said.
If the pilot proves successful, the

M any companies today start imple-

menting Service-Oriented
Architecture (SOA) projects and face
problems that can be attributed to a
belief that SOA makes everything easy.
This article will show that, while SOA
brings many advantages, it doesn’t alle-
viate the need for good planning, orga-
nization, and training.
We’ll examine the impact of a set of
common assumptions about SOA. A
fictitious integration project will serve
as an example; you’ll listen in on team
dialogue over the lifecycle of the project
and identify the sources of the assump-
tions.
Each assumption can easily be
applied to different stages of the project
and each contributes something to the
perfect storm. The assumptions can be
categorized into three areas:
• General organizational assumptions:
1. SOA doesn’t need a clear implemen-
tation strategy (from skills to gover-
nance). “Strategies and plans cost
money.”
8. Let’s take our Application Program
Interfaces (APIs) and turn them into
Web Services. Isn’t that all that’s nec-
essary?
9. I’ve read something about design
patterns. Well, we bought SOA, and
it’s supposed to work!
Company Profile
The company in this fictitious exam-
ple is a service provider that’s highly
specialized in solution delivery. Part of
its success during the past decade was
from long-term relationships and con-
tracts to extend custom-built solutions.
Most of these contracts were written
years ago, and these long-term support
contracts are important to the compa-
ny’s revenue.
Because of budget considerations,
time pressures, and resource shortages,
no attempts have been made to educate
employees about new technologies or
implementation strategies. The compa-
ny’s board has heard about SOA and
knows projects in this space could be a
valuable contributor to revenue, but
company will get a large share of the full
project, in which all the strategic appli-
cations will be rewritten or migrated. As
stated clearly by the directors, this proj-
ect has to be on time and on budget to
get to the next level with any chance of
further contracts with the customer.
After a quick vote in the Project
Management Office (PMO), Brandon,
one of the more seasoned project man-
agers, was assigned to this four-week
job. He earned his reputation for project
management during the company’s first
and only Java 2 Enterprise Edition
(J2EE) project. However, because of its
urgency, that project was a rapidly
assembled Band-Aid solution rather
than a well-planned and organized proj-
ect. Furthermore, it didn’t really advance
the skills of the company or the devel-
opers.
Internal Planning and Staffing
(See assumptions 3, 4, and 5)
Brandon accepted the challenge, but
with some concern about how to staff
the project. Some of the people who had

Business
• Transitioning an organization into a model that has solid, well-
defined, decision-making processes (governance) is harder than
simply writing a few services.
• A clear strategy for implementation of a Service-Oriented
Architecture (SOA) is needed; consider an iterative development
approach.
• Communication about implementation of the SOA strategy and its
benefits is a major key to success.
Technology
• Developers that implement services to leverage legacy system code
need deep knowledge of both sides to ensure working, flexible
code.
• When applying iterative development, ensure short phases (cycles
of analysis, design, implementation, and test) and closed, workable
packages.
• Keep away from implementing a framework for orchestrating
services yourself. Instead, consider using Business Process Execution
Language (BPEL).

16  •  Business Integration Journal  •  September/October 2006 Business Integration Journal  •  September/October 2006  •  16
worked on the last SOA-like project
were moved into different parts of the
organization, and all the external staff
members were gone.
But this was “just” a proof of con-
cept, and luckily there were still several
weeks to go before the actual kickoff.
Brandon decided that once the team
was formed, he would send them for
training on the latest and greatest tech-
nologies (assumption 4). This was a
good idea, but it didn’t work out that
way:
“We just lack skilled resources,”
Brandon said. “And management isn’t
willing to do anything to make the situ-
ation better. Today, when I was assigned
to this project, I brought up this issue
and the only answer I got was,
‘Education, for an SOA project? Sorry,
but the guys already have plenty of
development experience.’ ”
What Brandon described in his com-
ment is a deep fear—not just about the
lack of skilled resources he needed to
succeed in a critical project, but also
about his own lack of expertise in SOA.
Despite his seniority, the only method-
ology he’d ever worked with was the
waterfall model (assumption 5). (For
details on the model, see The Software
Development Edge: Essays on Managing
Successful Projects, by Joe Marasco,)
Finally, Brandon decided on the
approach. “Just move ahead,” he said.
“It’s just another project; let’s have the
team learn on the fly.”
Why did Brandon proceed without
ever thinking of getting the right project
strategy together for his team? In today’s
fast-moving project environment, which
is almost entirely margin-driven, com-
panies tend to forget about long-term
investments, especially—as shown in
this virtual company—where the inter-
nal resources lack knowledge and expe-
rience. The company’s board decided to
“rent” external people for the duration
of the project, without any master plan
of knowledge transfer into its own orga-
nization.
Depending on your constraints, one
of two approaches could be taken in a
similar situation:
• High go-to-market pressure: The
project is under severe time con-
straints, and failure isn’t an option.
This is the time to bring in skilled
resources from outside and have peo-
ple learn from them. This isn’t an easy
solution, particularly if there are dif-
ferent mindsets among the developers,
but it has proved to be successful. In
17  •  Business Integration Journal  •  September/October 2006
this case, the people from outside will
lead the project to ensure success.
• Time is no pressure, and manage-
ment is willing to make a long-term
investment: When time isn’t a con-
straint, it’s a great chance to start with
two or three small projects, almost
prototypes, and let the whole team
learn from scratch. Just a few experts
from outside are needed for guiding
and mentoring.
Design and implementation
(See assumptions 2, 7, and 8)
After some analysis, the first ideas
on how the new system could look,
from a technical perspective, were con-
sidered. Some possible services had
been identified, and now everything
came down to the newly appointed
architect. Greg, a seasoned developer,
was thought to be the perfect match, as
he had considerable experience design-
ing software systems. The only problem:
He had no experience designing sys-
tems with new technologies. Luckily for
the team, he was interested in learning
about them and had read one book after
another on new emerging technologies.
He was convinced he could design a
super-flexible and more-or-less easily
maintainable architecture. After looking
into the many documents that had been
written during analysis, he started
designing services … and plenty of
them. All were Web Services.
He took a partly object-oriented
approach and designed two kinds of
services. One, referred to in the anti-
pattern world as a Godfather Service,
offered an overabundance of or mixed
functionality. (Design patterns repre-
sent accepted solutions or best practices
for common programming challenges.
“Anti-patterns” generally contravene
these design patterns and are consid-
ered undesirable.) The other, Tiny
Service, consisted of several small,
decoupled services for each function.
Consider these examples:
• Godfather Service: “A Godfather
Service is a service with many public
interface methods that implement
many different key abstractions or
entities. The result is a service that
couples too many underlying business
or technical components, and is there-
fore used by too many clients, making
development and maintenance diffi-
cult, and creating a reduction in flexi-
bility.
• Tiny Service: “A Tiny Service is a ser-
vice that incompletely represents an
Business Integration Journal  •  September/October 2006  •  17
abstraction, implementing only a sub-
set of the necessary methods, resulting
in the need for multiple services to
completely implement the abstraction.
The result is that clients have to utilize
several services to implement a signifi-
cant business process, and need to
implement the sequencing and work-
flow.”
Greg’s whole design consisted of
abstract definitions of Web Services
with plans for their reuse in the next
phase of the project. But after another
week of painful code generation and
regeneration, some of the developers
discussed the impact of Greg’s design
during a coffee session late at night:
“I fear all the overhead of SOAP and
the abstraction will immediately break
the system,” one developer said.
“I had to change my code three times
last week, thanks to this inferior design,”
another developer said. “Everyone start-
ed changing the interfaces because they
lacked the information needed to get
the operations done.”
From these quotes, two points can
be inferred:
• A clear strategy for implementation is
needed (see assumption 1). In an
older-style waterfall project, the design
was created and frozen. In compari-
son, an SOA project, or an agile proj-
ect, is defined by its interfaces, which
could change during the iterative pro-
cess. So clear communication of roles
and tasks in the development group is
key. A change in an interface could
have major consequences (not just in
terms of a broken build, but also in the
frustration level of developers).
• Developers that implement the ser-
vices to leverage legacy system code
need deep knowledge of both sides
(see assumption 4) to ensure working,
flexible code. Even if Fourth-
Generation Language (4GL) code-
generation tools are promising and
easy-to-use (see assumption 9), they
aren’t the solution for everything,
especially if the granularity of services
is wrong (say, causing too many
roundtrips and resulting in poor per-
formance).
When an agile development method
is used, the impact of bad design deci-
sions (such as too much or too little
granularity, or using just Web Services
for everything) can be discovered at an
early iteration.
Test and User Acceptance
(See assumption 5)
After three weeks of agonizing devel-
opment work, several interface changes,
and some unit testing, the group was
shocked at the first round of integration
tests: performance was almost unac-
ceptable. A lack of skills led to a bad
implementation of the bridges to the
legacy systems, resulting in too many
roundtrips. The group also realized that
there was a huge gap between the proto-
type as originally envisioned and what
they now had.
Some goals were met, but others,
such as the User Interface (UI), were far
from the communicated goals. Not only
was the customer unhappy and harbor-
ing strong doubts for phase 2 (the big
implementation), but the developers
themselves weren’t happy with their
work, either.
“For weeks now, we’ve built this sys-
tem, and it’s far from what everybody
hoped,” a developer said. “It’s slower
than the old one, development was no
easier, and it seems to be even less
maintainable.”
The developers’ lack of training
(assumption 4) and an inexperienced
architect resulted in a clumsy design
(assumption 9). With a monolithic
application, you can still get reasonable
performance from a bad design.
However, the more distributed your
architecture, the more a solid design
matters.
“We’re not even close to the results
the customer expected, even though we
had clear specs,” Brandon said. “We
took shortcuts and hacked here and
there just to get it done.”
This clearly shows the lack of agility
(assumption 5) and belies the idea that a
waterfall approach is the best methodol-
ogy for all situations. Instead, consider
applying an iterative approach such as
the Rational Unified Process (see www.
rational.com/products/rup) to ensure
fast results that can be shown to the
customer for immediate feedback and,
if necessary, allow for the possibility of
reworking results and errors in the next
iteration.
Operations and Governance
(See assumptions 1 and 5)
The pilot project was intended to
show the successful transition from a
monolithic application to a distributed
SOA. However, no time was spent
thinking about operations. There are
two important aspects of operations to
consider:
18  •  Business Integration Journal  •  September/October 2006
• Scalability: As more people or clients
use the available services, more infra-
structure is required to provide those
services.
• Change management: Managing
change impacts the software and the
company itself. Usually, the move to
SOA implies a switch from organiza-
tional silos to a more matrix-like orga-
nization (reuse of functional services
across departments or silos). While
this may sound easy, it can be difficult
to achieve. This is because of the exist-
ing structures that have been around
for many years, such as who can sign
off for a change request, or who is
allowed to request features. Moving to
an SOA means having to form com-
munication channels and agreements
between what were previously in spe-
cialized, separate, and independent
silos.
One of the challenges of SOA is
forming the capability of providing the
right hardware resources that are cheap
and can be easily expanded to meet ris-
ing needs. (This is the concept behind
“grid” technologies.)
Transitioning an organization into a
model that has solid, well-defined, deci-
sion-making processes (governance) is
harder than simply writing a few ser-
vices. It could require a change to both
organizational structures and the mind-
set of employees.
Summary and Recommendations
Here are some recommendations for
creating the wind that can drive your
project into a safe haven instead of a
thunderstorm:
1. Invest in continuous education of
the organization (assumption 4):
• A strong understanding of both the
implementation technology and the
technology of the legacy code is need-
ed. COBOL programmers can be
assigned to service development.
• Know and adhere to the standards in
the SOA world such as SOAP, Web
Services Interoperability (WS-I), and
Service Component Architecture
(SCA).
• Understand SOA, its principles, and its
design patterns. SOA offers a blueprint
for implementation.
• Get familiar with the run-time/deploy-
ment environment (such as applica-
tion servers, J2EE containers, and so
on). The new implementation and
Business Integration Journal  •  September/October 2006  •  18
run-time environment will differ from
the legacy one.
2. Service analysis and design (assump-
tions 7, 8, and 9):
• Consider an iterative development
approach.
• Keep the design simple, open, and
close to standards such as WS-I (see
http://www.ws-i.org).
• Keep away from implementing a
framework for orchestrating services
yourself. Instead, consider using
Business Process Execution Language
(BPEL).
• Web Services should be used as appro-
priate to solve your business problem.
They’re extremely effective for loose
coupling but sometimes other
approaches, such as the Web Services
Invocation Framework (WSIF), can
overcome performance and transac-
tional issues by using native protocols
(see http://ws.apache.org/wsif).
• Lean toward asynchronous interac-
tions, and choose synchronous inter-
actions wisely, as they’re blocking.
• Design stable contracts and interfaces
first, and have everybody agree on
them.
3. Waterfall vs. agile implementation
(assumption 5):
• A waterfall implementation (analysis,
design, implementation, test, and
acceptance) can hardly react to chang-
es in scope, the customer’s vision, or
requirements. Consider using agile
development techniques to be able to
react quickly and gain immediate cus-
tomer feedback. This is especially per-
tinent for short-lived projects such as
prototypes.
• When applying iterative development,
ensure short phases (cycles of analysis,
design, implementation, and test) and
closed, workable packages. Usually,
when the cycles are kept too long, the
overall direction heads back toward a
waterfall implementation.
4. Communication (assumptions 1, 3,
and 6):
• Communication about implementa-
tion strategy and its benefits is a major
key to success, because SOA often
means a switch in the mindset of
developers—not just in terms of tech-
nology, but also in their way of think-
ing: from tightly integrated to loosely
coupled.
• SOA isn’t just applicable in a team that
implements a certain project; SOA can
drive the whole organization to the
next level.

Conclusion
This article showed how some false
assumptions people make about SOA
can take a four-week project from a
smooth start to chaos; it also addressed
what’s needed to change these assump-
tions. The key to successful SOA proj-
ects is continuous education, a strong
will to clear existing barriers, and an
agile team that’s willing to focus on
adapting to the visions of their custom-
ers.

About the Author

e-Mail:

Callout: SOA often means

a switch in the mindset of
developers—not just in
terms of technology, but
also in their way of thinking:
from tightly integrated to
loosely coupled.

19  •  Business Integration Journal  •  September/October 2006 Business Integration Journal  •  September/October 2006  •  19