At this week's IBM Impact conference in Las Vegas -- where the SOA and BPM are the hottest acronyms around -- I had the opportunity to sit down with Steve Mills, senior vice president and group executive of IBM's Software Group.
I talked to Steve about the business drivers for SOA, and how its heritage is at work today. Here are some highlights:
Joe McKendrick: [In the conference opening keynote], you discussed IBM's original vision for SOA, announced in 2002, has come to pass. Is there anything still missing from that original vision?
Steve Mills: Nope. What we said was true. We believed it at the time. Obviously, there's always lots of hard work that has to transpire to make these things come true, so its not a matter of simply declaring it, and it happens. We understood what the customers were looking for, and therefore we knew what we needed to invest in, and the nature where the technology had to go, when improvements were needed. We're very persistent bunch, so we stay with it, and we get these things to work.
JM: Ten years from now, at Impact 2020, how will we be looking back at how SOA progressed?
SM: I think we'll see a continuing progression here -- by modeling techniques, this is the way to create applications. Not 100% of all applications, but certainly the bulk of commercial applications in business, will incorporate various aspects of service orientation.
Today, versus five to ten years ago, some of things were doing today around SOA and the amount of loosely coupled functional characteristics in some applications today are far beyond what we thought we could ever achieve leveraging SOA. Again, the acceleration of cost and performance and improved infrastructure tools and so on contributed to being able to do things now that you couldn't do before. And I suspect with even faster computers, more viable scenarios will emerge over the next decade.
Looking ahead, some of the bigger challenges are going to be more about service orchestration. Were not just simply talking about a loosely coupled collection of services within an enterprise, but now the inter-enterprise service model is going to become much much bigger.
Companies have been de-verticalizing for decades. Henry Ford owned the iron ore mines, steel mills, and rubber plantations. In order for him to create a car back then, he had to have a full vertically integrated manufacturing infrastructure that went all the way back into the raw materials. Ford clearly doesn't operate that way today, there's no need to.
So if you look at that as an analogy, I think if you look at the last 30-plus years of the evolution of the use of IT within business, you'd see an ever-increasing amount of de-verticalization. Companies are becoming ever more flexible and open to the idea that third-party providers of useful business process services are a convenient cost-effective way to get the job done. And that;s good news, in terms of improving economics and creating greater flexibility.
The flip side of that is, gee as I look at now my corporate IT infrastructure is becoming ever more virtualized, logically virtualized in the context of where do these services come from, and now I'll need to track all these relationships, I have interdependencies that take place, I still have to deal with all my compliance, and bring it toward filings an certification and everything else.
The good news is that SOA has given me tremendous flexibility and real leverage on costs. The down side is that I have to spend even more time thinking about how I'm going to manage all these services, and certify services, and be able to ensure that I can sustain my overall business model in context of everything I have to do to protect my brand to manage my company effectively. Its not that its impossible to do. It juts changes the nature of what the IT organizations become responsible for. IT becomes a service aggregator, much more than a service producer.
JM: Is IT ready to take on such a role as agent for business transformation? IT managers are well-trained and experienced in bits and bytes.
SM: The lines blurred. The image of IT was the back-office organization that processes bills. Then if that's all it is and that's all it does, obviously its not an integral part of customer-facing activities. But those days are long gone. IT has a long time ago made the transition to become a partner and integral part of the value proposition that different parts of a company are responsible for.
The IT people in retail are working with merchandising people and purchasing people and customer loyalty programs. IT is part of the fabric of the way companies do things. You wouldn't ever think of doing it any other way than by leveraging information technology. IT is ready.
For those that are trying to craft new and creative business models, that's a bigger issue than IT. Talking about ups and the crafting of their brown offering. They knew they had a lot of infrastructure, they they had a lot of IT capability. The question is, can they translate all of that into a value proposition, that fundamentally change or transforms somebody's supply chain. They came at the problem not from an IT perspective, but from a process transformation, all their operations research capability, all of their knowledge of how to optimize things. That was at the very root of the business model. Then the IT becomes the supporting capability to allow it to scale to be efficient.
JM: The work that led us to SOA has been going on for decades. But I often hear criticism that SOA is merely a repackaging of prior initiatives, such as RPC and object orientation.
SM: I don't think that's entirely true or fair. Everything builds on the things that came before it. You see this with technology all the time.
The distributed computing environment, DCE [Distributed Computing Environment], that originally came out of DEC, and involved the use of remote procedure call techniques, which then evolved into CORBA. If you look at the whole OMG CORBA initiative, that was very much about using RPC mechanisms as a way to call routines, and incorporated object constructs into it. You had a lot of complexity in those models. If you looked at the amount of programming necessary to initiate a remote procedure call, or to set up a remote method innovation, they were very programming intense, and required a great deal of knowledge in order to be able to do those kinds of things. And technologies such as Java were in many ways to simplify the principle around the original OMG services with J2EE is a rebuild of the CORBA services, 20-plus CORBA services all written in C++ that were all re-implemented as part of the J2EE to provide an integrated infrastructure that would allow application-to-application communication to take place around a relatively simple model.
SOA works today because computers have gotten faster. Some of the
complex interface structures have been simplified. The underlying
concepts are not dramatically different. I would argue with anybody
that wants to focus on things that have came before, that what we've
done is we learned our lessons from things that were cumbersome and very
difficult to deal with. Certainly the very complex OO that started to
get popularized coming through the eighties into the early 90s, people
have backed away from those very sophisticated uses of OO technique and
technology, to very coarse-grained approaches that are easier to
understand, easier to document, easier to create reuse around.
Clearly, compute speed and growing sophistication around transactional infrastructure has led to enterprise service bus architectures that 15 to 20 years ago were extremely hard to implement, because you couldn't get enough performance out of the software and hardware to instantiate a true shared bus architecture. Anybody who tried that ended up backing off to point to point, as an easier implementation model for doing application-to-application connection. So we can clearly show where SOA learns from the past, and takes advantage of growing sophistication and knowledge.
I would argue that, like so many things in this world, the third time is the charm. All the previous attempts, which had value in their own right, which didn't really seem to quite build to the crescendo that you would have hoped that were part of the learning experience, so then you do it again and again, and sure enough you finally get it right. It all coalesces. Look at the history if invention. You'll see that all great investors had stood on the shoulders of those that preceded them that solved other problems. Those problems now were taken care of, and opened up for a new invention to capitalize on everything that came before it.