| QUESTION & ANSWER |
IBM's Liebow: Everyone's got an SOA army |
 |
By Michael Meehan, News Editor
19 Apr 2006 | SearchWebServices.com |
|
|
Michael Liebow is the vice president of Web services and service-oriented architecture for IBM Business Consulting Services. Helped build IBM's SOA consulting practice and has spent the past three years directly involved with customers working on Web services/SOA projects.Read Part 1
How do you recommend avoiding the construction of services 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.
|
|
|
|
