Today, however, with the introduction of the concept of service orientated architecture (SOA) and the maturing technologies and standards that support it, the goal of IT/business alignment may actually become a reality.
CIO Update caught up with Michael Liebow, vice president of SOA and Web Services for IBM Business Consulting, last month to explore this issue further, cover some basics and try to divine where SOA is going and what it means to you.
Liebow: (SOA) is not a new concept. It's been around for about a decade. This notion of standardization is driving adoption. The industry has always wanted to do this, client CIOs have always wanted to do this, it's just the maturity of the technology, the maturity of the standards, maturity of the organization and skills to be able to do it.
Realistically, most organizations have just been picking it up in the last few years. It's just one of those things though that the industry has tried and not necessarily succeeded in doing it.
What is your definition of SOA?
I sum it up in one word. It's this notion of abstraction. What you are trying to do is abstract the business processes as a service that is readily available regardless of whatever the underlying applications or infrastructure is.
So these business processes are rendered as services. There's a programming model, there's an architecture and there is a defined set of business services that are created in order to allow organizations to quickly and flexibly react to changes in market conditions.
Business unit heads are fairly frustrated with IT because their competition does something and they have a failure to react. So there's a change in market condition either man-made or natural and they want to react to that change and their systems don't allow them to do that or they can but it's expensive it's slow and very difficult to implement.
So there's frustration there. They feel they've been investing in technology for quite some time but that assumed return (the promised business benefits) has been somewhat elusive.
What's worse is the business requirements were set at a point in time and cemented over so as the business changed IT was building to a set of antiquated requirements.
So it's up to IT now to start to move at the speed of business and we think that we are finally at a point in time that the technology and the standards have matured to an extent that we can now realize that goal.
What are the standards you are referring to?
Web services are really just a set of infrastructure standards and if you think about what's happened in the industry you think about this alphabet soup of standards.
Most people are familiar with TCP/IP, they're familiar with html, they're familiar with http:, these are recent standards that have really driven the whole adoption of the Internet.
XML is the newest standard that has really facilitated the movement of information. You have new standards like WSDL, WSDM (Web services distributed management), UDDI to a lesser extent, SOAPthese are all infrastructure standards that have been created in order to facilitate applications talking to one another without regard to what the application is.
So that allows for a level of flexibility, allows for a level of connectivity in the application layer.
How is SOA different from EAI, which is basically an older attempt at the same thing?
Before, application integration was essentially an proprietary statement. So you had EAI techniques that pretty much locked you into pretty much a small world, if you will. And you built adaptors and what not that were fairly proprietary. And all of this resulted in a lot of what I would call hard-wiring it's all very hard to do, very expensive to maintain and it's inflexible.
I mean, it produced business value; there's nothing wrong with it. You had to do certain things and you did them, but when it came time to change it you couldn't.
It's not the coding change that's the issue, it's the (business) cycle after the coding change that really screws you up. Because you have all these hard-wired connections and if you start to play with that you're impacting that across the entire organization.
So how does SOA break through that barrier?
SOA allows you to componentized those business functions. Separate or extract them from the underlying applications and the infrastructure. It allows you to wrapper them with a set of standards so they're not hardwired, their easily called upon.
And so what were talking about now is the sort of the next generation of the Web. The first generation was really about people connecting to machines. This second generation is really about machines connecting to machines.
So, if I think about the second generation of the Internet, I think about how people can easily access information from wherever. And it's amazing for most people to experience with the level of broadband connectivity, wireless connectivity the information that's available on the Web; the innovation that's occurred. But machines have not been able to enjoy that same kind connectivity.
So when we think about SOA we think about building out a service integration layer within the enterprise in order to allow the applications to connect to one another in a fairly seamlessthis notion around loosely coupledso they can connect to information as they need it.
So what they are doing is they are surfing, they're trading messages and deciding if that information is relevant to them or not, just as one would do a Google search or whatever.
So that's this notion that machines can connect to one another. They don't need the hardwiring. They can find the information they need to execute a business process. And what we're doing is were allowing organizations, business, to occur much more rapidly.
What are some of the underlying technologies such as virtualization, broadband that are enabling SOA?
There's a couple of notions from the technology side. There's a whole life-cycle notion around how you model the business process, how you assemble those services, how you deploy those services and how you manage them.
So there's a whole set of tools and products that support that evolution, the SOA life cycle. IBM calls it their SOA Foundation. We're talking about this notion about automating workflow supported by increased gains in connectivity and bandwidth.
Really, the notion around SOA adoption is not technology it's really more in terms of culture, its more in terms of governance, it's more in terms of skills.
So, by saying "not technology" you mean the technology is available, it's understood, it's proven, you just have to want to implement it and control it?
Typically the three characteristics of early adoption tend to be focused on how innovative is the CIO, how centralized is the IT organization, and how aligned is the IT organization with the business; do they have a seat at the table? And if those three conditions are there, then you see SOA adoption.