Fralick Says:
|
The
problem is that the term
is now bounced around
so often that it is easy
for vendors to say “We’re
SOA,” declare victory,
and simply move onto the
next slide. Are
they lying? Who knows?
What
do you say? Send
us your comments here
|
There
is an incredible amount of noise
and hype in the supply chain
space right now about “SOA,’
or Services Oriented Architecture.
Unfortunately, there is a problem
with a whole lot of the noise
and the hype.
Not
that I don’t think SOA
is important. Having been
one of the principle architects
for what I believe was the very
first SOA-based supply chain
application (a warehouse management
system) in the mid-1990s, I’ve
been living and breathing SOA
for a dozen years. But
the conversations that typically
take place around SOA right
now run the spectrum from techno-babble
to partial truths to outright
fabrications. It needs
to stop.
Here’s
a quick primer on SOA.
The whole idea of SOA is to
free the functionality of a
software package from the confines
of the application. We do this
by creating logical bits of
functionality called services.
A service, then, can be thought
of as a piece of functionality
delivered as a stand-alone ‘black
box’. Each individually
identifiable black box is or
can be decoupled from the application
(doesn’t need the bounds
of an application to execute).
It’s
not that the application does
not use the services. Rather,
the services aren’t designed
to be exclusive to the application
(or the application as delivered).
In other words, SOA empowers
us to create reusable, borderless
bits of functionality.
These services can be used to
create functionality and “work
flows” (or processes)
both within an application and
between applications, sometimes
in ways the original software
developers may not have contemplated.
Sounds
simple enough doesn’t
it, even pretty logical? You
might say “Makes sense.
Isn’t this how software
should be built? Give me the
right building blocks.”
You’d
be right in thinking this. Software
should be developed using SOA-based
principles. The problem is that
all too often it isn’t,
or wasn’t. Now that SOA
is such the buzzword, every
software vendor is putting an
SOA ribbon on everything they
do. The reality is if the software
wasn’t built that way
from the ground up, getting
there isn’t easy.
Some
applications are truly based
on SOA, some are not and most
right now are partly SOA.
The problem is that the term
is now bounced around so often
that it is easy for vendors
to say “We’re SOA,”
declare victory, and simply
move onto the next slide.
Are they lying? Who knows?
The problem is that there is
no real clear definition of
what it means to be SOA or have
an SOA-based solution.
Here’s
my suggestion – fill out
the following SOA scorecard
for each vendor:
- If
they talk about the technology
of SOA (their implementation
of it) – give them 1
point.
- If
they misspell SOA on any slide.
Take away 1 point.
- If
they do not know each word
making up the acronym SOA,
take way 1 point for each
of these words.
- If
they pronounce S.O.A as “So-A”,
take away 1 point.
- Add
5 points if they can use Web-Services
based Integration. A
Web Service is an implementation
standard for SOA. Take
away 10 points if they did
not know this.
- Add
20 points if they talk about
it in terms of functionality
and not so much in terms of
technology – and can
show how to shift the functionality
around or move it outside
the application.
If
they score between 5 and 10
they probably have some SOA
capability. If they score
over 20, they are probably pretty
far along the spectrum.
But, my tongue in cheek scorecard
highlights the most important
thing about SOA. While
SOA is enabled by technology
and architectural approach,
its real value is to the operation
and the enterprise’s business
processes.
So,
in my book, vendors that speak
of SOA in terms of technology
are just adding to the noise
– and may not “get
it” yet. Those that,
more correctly, talk about SOA
as a tool for yielding the most
ROI out of the systems by how
you can drive process innovation
and rapidly configure the solution
to the needs of the business
(without regard to the specific
functionality of the applications)
– really get it.
If they are approaching the
discussion from this perspective
and (this is really important)
can demonstrate how they
do this, they probably actually
do SOA to a level from which
will yield you the potential
for long term value.
In
the coming weeks, I’ll
be publishing articles revolving
around what SOA can do for an
operation and an enterprise
and how to think about this
in real terms.
Agree
or disgree with our expert's
perspective? What would you
add? Let us know your thoughts
for publication in the SCDigest
newsletter Feedback section,
and on the web site. Upon request,
comments will be posted with
the respondent's name or company
withheld. |