<http://click.icptrack.com/icp/relay.php?r=54205795&msgid=672521&act=J1NT&c=334543&admin=0&destination=www.davidlinthicum.com>
Most SOA Consultants Need a Lesson in SOA
<http://click.icptrack.com/icp/relay.php?r=54205795&msgid=672521&act=J1NT&c=334543&admin=0&destination=http%3A%2F%2Fdavelinthicum.blogspot.com%2F2009%2F01%2Fmost-soa-consultants-need-lesson-in-soa.html>
David S. Linthicum <mailto:[email protected]>
www.davidlinthicum.com
<http://click.icptrack.com/icp/relay.php?r=54205795&msgid=672521&act=J1NT&c=334543&admin=0&destination=http%3A%2F%2Fwww.davidlinthicum.com>
Many people in the planning stages for SOA do not get the proper advice
and guidance as to how to proceed, or even what a SOA actually is. Thus,
the larger tragedy is that many of these projects will hit the wall, and
do so with an impact that will reflect poorly on the notion of SOA, when
it's not really a SOA issue at all.
First, be wary if consulting organizations point out their experience in
the world of SOA by putting up past projects as proof of their
experience. Most, if not all, of these past projects are really JBOWS
(just a bunch of Web services) and have no underlying mechanisms to
provide agility, which is the core benefit of SOA.
The problem is that many of the people looking to hire SOA consultants
don't understand the difference between JBOWS and a true SOA, and accept
JBOWS as "experience." In reality, it's an indication that the
consultants don't understand the core value of SOA, and thus could send
you off in all sorts of dangerous and costly directions. So, make sure
to hire consultants who understand that SOA is really about
configuration, agility, and changeability, and not just about service
enablement. It's very easy to expose services; turning those services
into solutions is another level of sophistication.
Second, many consultants are a bit too chummy with vendors. Thus, you'll
find that they implement the same vendors and technology each and every
time. This should be a huge red flag since SOA problem domains are all
very different, and technology solutions that work best for the solution
are never, ever, from the same vendor, over and over again. However,
when you sell hammers, everything looks like a nail. The path of least
resistance is what you know, not what you should do.
Those tasked with managing SOA consultants need to state clearly that
you are looking for the right solution, not the one they know, or what
may be part of an existing partnership. Indeed, consulting organizations
with many preexisting vendor partnerships should be quickly overlooked.
You need guys and gals in there who are agnostic when it comes to
technology, and are willing to leverage the best-of-breed to address
your issues.
Third, there needs to be a predefined process. While many SOA
consultants try to use older SDLC and enterprise architecture processes,
SOAs need a specific approach that addresses the unique nature of these
architectural patterns. For instance, there is a traditional focus on
data, but the data needs to be properly bound to services. Moreover,
those services must be properly bound to processes. Plus you need to
keep track of all the interdependencies, and how all of this stuff links
to SOA governance, SOA security, and event management and monitoring.
Many consultants attempt to oversimplify the process, rapidly moving
through or even foregoing the planning steps. Their main focus is the
selection of the technology, or, in some cases, they attempt to force
fit a problem with a predetermined technology solution. This can never
be good.
The fact of the matter is that SOA is a complex distributed system, and
thus complex to plan, design, build, and test. The time spent in
planning will later pay huge dividends. There should be a very rigorous
process/methodology defined that, at a minimum, provides you with a
semantic-level, service-level, and a process-level understanding of the
problem domain, not to mention the governance model and security
strategies. Trust me, you can get SOA right the first time, but with
more planning and sweat than you expect.
Finally, there is the lack of understanding about ongoing SOA operations
and links with traditional enterprise architecture. You just can't build
a SOA; you have to live with your SOA, ongoing. That means understanding
how the solution exists currently, and how to align it with business as
it changes. If your consultant has done his or her job, you should have
an architecture where the volatility has been abstracted into a
configurable domain. Thus, it's a matter of changing things at the
configuration layer to adjust to the changing nature of the business.
Therein is the value of SOA.
If your architecture does not seem to be providing that degree of
agility, then you're going to have to loop back to the beginning to see
where you went wrong. Typically, per my previous point, not enough
planning was done and perhaps the wrong technology solution was
employed. In any event, you need to bite the bullet, spend the money and
fix it, or you'll find that your SOA actually takes you backward.
The issues here are not a case of bad intentions. I think everyone
honestly wants to do their best. It's a lack of understanding and
perhaps talent in some instances. Those who do best with SOA have a wide
range of skills, a good understanding of architecture and the value of
SOA, and all of the good work that needs to occur to make it work for
the client. However, I don't see many out there who fit that bill, and
the amount of bad advice is becoming a huge issue. Unfortunately, many
won't figure this out until it's too late.
SOA is something you do, not something you buy, but you also need to do
it right.
This message was sent from David Linthicum to xxxxx. It was sent from:
David Linthicum, 11654 Plaza America Drive, #103, Reston, VA 20190. You
can modify/update your subscription via the link below. Email Marketing
Software <http://www.icontact.com/a.pl/144186>
