IBM's Liebow: SOA still fairly immature

Michael Liebow is the vice president of Web services and service-oriented architecture for IBM Business Consulting Services. He 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 two

Based on your experience, what percentage of companies are working on Web services projects versus those working on SOA projects?

The key notion here is you can do Web services without SOA. You can't really do SOA without Web services. People have been experimenting, piloting and rolling out projects using Web services to do point-to-point integration. To some extent they've been able leverage that within their organization and perhaps consume a set of services from outside their organization in limited numbers. It's difficult to gauge who is doing what. Though we track things like downloads of software development kits and we're seeing lots of grassroots adoption. Along those lines how conversant are IT executives in SOA?
What we've done over the last couple of years is significant outreach to CIOs and senior IT at executive summits and architect summits we host around the globe. I just came from one in India. We know that their organizations want to do this in a significant way, but perhaps they as leaders haven't necessarily taken a position on when, where and how to do it. They want to know how to standardize this across their organizations.

When you look at the pattern or adoption, you not only see these developers who are picking up the technology, but we're also seeing their business units, fairly autonomous business units, picking up the technology – not because they were asking for SOA, but because they had a pain point they needed to solve. They need visibility into inventory, visibility into supply chain, some type of multi-channel integration.

What we're seeing now relative to the marketplace is that CIOs are realizing this stuff is for real, but it's not necessarily cheaper the first time around, it's not necessarily easier the first time around. The approach to IT is to fund it on a project basis and the first guy to walk in with a set of requirements, even if the CIO wants to do it through service-oriented architecture principles, is going to have some difficulty convincing that business owner that for the good of the company he should spend more.

So how many companies have been willing to look past the immediate pain point and address the larger needs of the enterprise? How many companies are willing to bite the bullet and build an SOA?
These are cross-enterprise decisions. Do they have the funding to create a set of services and reusable components across the enterprise? You've got to start someplace. You've got to start with the things that have the lowest risk and highest reward for the organization. How do you define the metrics around that so that you know you've arrived? What does the organization look like when you've got a fully functioning SOA? You need to have that vision. You need to have that master plan so that you know where you are relative to your build-out.

It's like building a house. You have a blueprint. You don't just build one room today and six months later build another room and hope that the hallway's aligned. You know what you want this thing to look like when all's said and done.

Along those lines, how many companies have you run into that would earn a certificate of occupancy for their SOA?
Here's the deal, we've done thousands of implementations and nobody I know of has the full house built. We offer to the industry a maturity model for service-oriented architecture and there are seven levels of maturity within that. The first level of maturity starts around siloed applications. The notion though is that you get alignment between the business and IT, so that you have a business architecture, the application architecture, the infrastructure, the whole alignment from top to bottom in your organization.

Level two speaks to the notion of EAI and essentially proprietary integration. Level three talks to the really decade-old notion of SOA, which was around components. These were not the same types of components we're talking about today, but around CORBA, COM, whatever. They were still somewhat hampered because they were hard-wired, but this is not a new concept. People have been trying to do this for a long time.

For more information

BEA tries to move ColdFusion apps into SOA

Check out our newly updated BPEL Learning Guide

Level four is where we get to services integration. It's Web services-based. You're able to expose services to be connected. We call it SOI, for services-oriented integration. It's an approach to integration that's much more flexible. And we think that most organizations we work with are trying to get to level four. The majority of organizations today are somewhere between one and three.

Level five gets you to composite applications.

Is it a rarity to see a company at level five these days?
You can see examples of level five and organizations that are starting to get there. They're real leaders in their industries. By no means would I say they have a full house, but they are pinpointing areas of the business where they want to build that capability. Yet the industry as a whole is just on the verge of touching this area. There are a number of startups that are providing aspects around this, but the major vendors don't really provide this.

We think that the majority of the industry is just trying to get to level four. They are trying to articulate a vision around level five. Six and seven speak to a level of dynamic sense and response, automatic, autonomic systems that's a future state. No one's there to any significant degree.

Dig deeper on Service-oriented architecture (SOA) Design



Enjoy the benefits of Pro+ membership, learn more and join.



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: