stovepipes, e.g. services that aren't integrated and don't get reused?
Michael Liebow: Let's talk about three conditions that lead to a
successful SOA deployment. First one is how innovative is the
leadership? Is SOA happening down a few levels in the organization or
is it being directed from the top. If you have a real innovative CIO
who's looking to standardize and govern how this plays out in the
organization so it isn't chaotic, that's one condition of success.
The next condition is how centralized is your IT organization? Is
there a control mechanism? Separate out this notion of SOA governance
from IT governance. These are two distinct notions, with some overlap,
but SOA governance is more on the business side. If they have regular
IT governance and a strong CIO and strong CIO office so there's this
level of awareness, structure, communication, competency from the top
then you don't have a lot of decentralized fiefdoms going off and
doing their own thing. It's much more controlled.
The third condition really reflects the alignment between business and
IT. Does IT have a seat at the table or is it just viewed as this
cost-sucking machine? So if you have an innovative leaders running a
centralized IT organization and a seat at the business table then you
have the structure to create a set of services that ensures a level of
success around SOA.
Now, not too many organizations have all three, so the notion around
SOA governance is a design, a best practice, a focus, an
organizational construct and a set of tools to be able to facilitate
any gaps in what you don't have.
What's the easiest thing to get yourself on a path to SOA that
companies generally don't do?
Liebow: There's this notion around business enablement, assessing
where you are, creating a framework for a discussion across the
business. To what degree are we doing SOA? I've been in rooms with 70
architects from an organization and I ask who's doing SOA and everyone
raises their hand. I'm like, there's no way.
You need to understand what you have and what you don't have and you
need to know what is the underlying plan. There's not really that many
people that understand this stuff, understand it at a gut level, but
they do exist. You can put them into a center of excellence to protect
them from the forces of nature.
The next thing is from a design standpoint, you can design this stuff
really poorly and it'll probably even work, but you need some
principles and techniques around how you design it so you do get that
level of reuse. You just don't take existing business process, model
it and then automate it. You need to focus on how to improve the process.
Let me ask you about a criticism we often hear from your competitors.
Can you do SOA with an army of IBM Global Services consultants?
Liebow: Tell me, who doesn't have an army? Are you telling me
Microsoft doesn't have an army for SOA or that SAP, which is investing
in a huge services organization, doesn't have an army? Who's kidding
who here? I find it particularly amusing when those organizations
announce services capabilities a week later. Talk about armies,
Microsoft has 300,000 consultants. I don't come anywhere close.
Is the rise of these armies an indicator that SOA is too complex for
most companies to implement without some sort of outside help?
Liebow: We had a state government come to us last February and say
"We're not going to meet the requirements of the Help America Vote
Act. It's a mandate for January 1, 2006." And this was a state that
could ill-afford not meeting the mandate. The counties were content
with what the had so it really was the state's burden. We said this
notion around service-oriented architecture fits perfectly. What we
can do is we can leave the county systems intact and we can virtualize
the state system. We had that done in less than nine months and up and
running a week before the deadline. The were the only state that met
the mandate.
Now the question is could they have done it themselves? They have an
IT organization, but the answer is the skills to do this aren't
readily available. You have to train people on this technology. You
need to understand how things have changed. You need to understand the
tools that are available and you need to build to that design.
Is the upside to all of this that you don't need to buy as much
software in order to get rolling on SOA?
Liebow: Hey, I'm from IBM. You have to buy some software. I'll say it
like this. It's not about the technology. The technology is still
important and there are some tools and products that you'll still need
to buy in order to get there. The point, though, is you'll leverage as
much legacy as possible. This is not about rip and replace and it's
about an 18-to-36-month journey to develop some kind of new siloed
application. This is about leveraging the systems you already have,
that you've already invested in. You're finally going to get the ROI
that you promised the business initially.>>
You can read this at:
<http://searchwebservices.techtarget.com/qna/0,289202,sid26_gci1182867,00.html?track=NL-110&ad=549842>
Gervas
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
