The following article was sent to me as an e-mail from David Linthicum.
Gervas
SOA in Danger of Over Hype, Over Spending, and Bad Practices
David S. Linthicum
In a recent Burton Group event, the analysts stressed what I've been
beating to death for years now, that too many companies are over
spending in the SOA space, too early, and are not thinking through the
core issues. Thus, many initial SOA project are in danger of hitting a
wall before the core value of SOA is understood.
The Burton analysts stressed that you don't need to chase after some
Enterprise Service Bus (ESB) with every possible option, or try to
support the latest chic Web services standards to achieve service
orientation. Indeed, they are describing what SOA really is--an
architecture style--and thus something you do, not something you buy.
However, don't tell the vendors that.
The hype in the SOA space is raging right now, largely due to the amount
of marketing money that's being spent in order to both create and
capture the demand. You just don't feel like you're a true enterprise
unless you have an ESB and governance tool, no matter that you've not
figured out how to use them yet.
Indeed the big "SOA stack" players are in the market early with
enterprise license agreements that lock in their customer into an
all-you-can eat SOA technology buffet that will supposedly provide them
with solutions to all of their SOA needs. The truth is much more
complex and less exciting.
In actuality, each enterprise is like a snowflake, and the problem
patterns present vary greatly from problem domain to problem domain,
enterprise to enterprise, as I'm finding both in my consulting practice
and data points with a number of SOA practitioners out there. Thus,
selecting technology before you understand your unique issues, puts your
first SOA project at risk and will cost you dearly, considering that
this is the mother of all mistakes that you can make here.
There is much homework to be done before you can begin shelling out the
big dollars for the big SOA technology, and more often than not you'll
find the technology that's a fit is not the technology you had first
thought. Case in point are the number of projects I'm finding where
ESBs are not the correct solution, but their early purchase means it's a
"force fit" which means the project is at risk, and at the very least,
the solution is not optimal. Not that ESBs are bad; they are not.
However, like any technology, ESBs do not fit within all SOAs. Same
can be said about SOA governance tools, SOA security solutions, service
development tools, etc.. You can define your architecture around
technology, and the reverse is also true.
The fact of the matter is that you need to go through some iterative
steps before you can even begin to define your technology requirements,
and look for products that fit them.
First, you need to understand your data at the semantic, metadata, and
abstraction levels. This means a clear definition of what's there,
what's needed, and how it should be modeled and implemented as a part of
your SOA. Data is the foundation, services are the externalization,
and processes are the solution. Keep that in mind.
Second, you need to identify all candidate services, or potential
services in your domain. This means going on a service mining
expedition, looking at mainframes, and other enterprise applications for
core business processes that need to be externalized as services for the
architecture. This means working back from screens, APIs, and
transactions, and the creation of a solution for recasting them as
services.
Third, you need to figure out the meta-processes that are a part of the
domain. This will become the foundation for your orchestration and/or
choreography layers, in essence, defining how the services interact and
providing a platform for driving them together into solutions.
Beyond all that you need to figure out performance, security, service
tracking, service level agreements, policy management, design time, run
time, and any special needs that your project/domain may have, and there
is always something that's unique. Then, and only then, do you figure
out your technology requirement.
Those who jump right into the SOA hype pool full of SOA technology are
finding a few things out. They are not solving their problem, they are
not using best practices, and worst of all, they are putting their
projects at risk and spending too much money in doing so. I'm not sure
if this is one of those "let the kid touch the hot stove" issues, where
a few painful failures will teach the masses that this is the wrong
approach, or if I need to keep jumping on my soapbox and preaching the
very unpopular notion that SOA is complex, hard, and if you're going to
make it work, it's going to take some work. Sorry to be the buzz-kill,
but somebody has to speak up.
Happy to listen to other options here.
