Gordon Van Huizen: The largest barrier to successful SOA adoption that we see has to do with internal staff training and time.  SOA is not simply another development technique—it requires a more holistic organizational approach in order to be successful. This translates into additional need for skills development, clearly defined goals and objectives, as well as managerial understanding and buy-in.

 

Van Huizen: There’s a significant distinction to be drawn between homogenization and normalization. IT infrastructure clearly needs to be normalized. Customers—whether internal or external—need be able to see and interact with IT infrastructure in a unified way, even though it may in fact be highly heterogeneous. For example, they need to be able to make a single request and have it take action across a number of otherwise diverse systems. And they need to be able to govern across the infrastructure as if it was a unified whole.

We see our clients today adopting enterprise service bus (ESB) and SOA management technologies to normalize their interactions with backend systems, as well as manage and govern them in a unified way.  So homogenization itself doesn’t need to occur in order to obtain the benefits of unification. This is largely what SOA is about.

 

 

Van Huizen: Well, they can be. Organizations that begin with business drivers and thoughtfully implement SOA do indeed see real benefits, and they have for several years now. We’ve personally witnessed several hundred organizations reduce operational costs, increase customer satisfaction and offer new services to the market through their SOA-based IT initiatives.

SOAWorld Magazine: You were a driving force in bringing the industry's first enterprise service bus to market and establishing the ESB product category – why was a further abstraction layer on top of existing enterprise messaging systems necessary?

 

Van Huizen: That’s a great question, as messaging is fundamental to decoupling in a distributed enterprise and is used in both SOA and non-SOA architectures.  Without an ESB, messaging is used primarily as way for applications to reliably communicate in an asynchronous fashion or as a means for distributing data between components of a distributed application.

 

However, in these cases the application is written in a specific manner to be a messaging application: it’s coded to directly send and consume messages and, in general, has to “know” a fair amount about the messaging environment that it’s deployed in.  With an ESB, the applications don’t need to be “messaging aware.” The benefit is that they remain unmodified, greatly reducing the effort to connect them to the bus and avoiding the need for all sorts of coordination meetings.  In essence, the ESB acts as an integration backbone for the applications it connects.  The further advantage is that applications connected to an ESB generally don’t need to be modified as message routing, process definitions, data formats and the like are changed. These changes are all configured within the ESB itself.

Van Huizen: It’s hard to know exactly what Dave meant by that comment, but I believe our team does have a strong track record of demystifying SOA. When talking about SOA, as with many technologies, you need to understand your audience: from business-focused individuals to hardcore technologists, and everything in-between. There’s a lot to talk about with each audience, but the content varies significantly. I can tell you that we’ve seen customers in a wide variety of industries rapidly build the competency to develop and deliver mission critical systems on our portfolio of SOA products.

 

Van Huizen: Yes, we continue to evangelize and educate on SOA. We don’t see the need for education diminishing, but changing form.  When you visit a new website or read a book on a new subject you first need to understand what’s being presented and then figure out how to interact with it. With SOA, as with any new technology, there is an initial gap in understanding centered on what the technology is. That gap must be overcome before you can really begin to think about how to use it. 

Once you understand the basics—the “what”— there is a second learning curve that needs to be addressed: the “why and the how.” How do you successfully design and implement systems based upon this new technology? Why would you do so? What need does it serve? We found that the first few years of education around SOA focused, necessarily, on that “what.” That need still exists today, but the “why and the how” are more at the forefront.

 

Van Huizen: Let’s separate SOA from middleware for just a moment.  SOA is an architecture and a discipline, which relies on middleware implementations to get things done.  Our implementations are best in class and therefore are individually distinguished in the market. This is absolutely core to our strategy: each of our products must provide distinct value on its own. When you’re looking for the most scalable and robust ESB, we believe you’ll look at us. When looking for a SOA management solution that provides the greatest visibility, again we believe you’d look at us.

It’s also important to us that while our products leverage the strengths of each other, that they should work well within and around other vendors’ products in a heterogeneous IT environment.  This distinguishes Progress’ approach to the market from all others.  Contrast this with other vendor solutions that are built up from a stack of interdependent components: they may work together as a stack but they don’t typically work well with products from other vendors—they don’t stand on their own. And a given product from their stack may not be the best at what it does. We believe that SOA demands a best-in-class heterogeneous approach. Isn’t that the whole point of SOA?

 

Van Huizen: I think 2008 is the year of the “events.”  And let me describe what I mean by events – because they are not new – they’re just not understood as first class citizens within IT.

We believe that SOA needs to support services, events and processes.  So far the market understands how to mix services and processes together to form new business processes.  But what has been missing is the event as a third element in this computing architecture.  Most analysts understand this and have been writing about events for some time, but many practitioners equate SOA to web service request/reply interactions.  We believe events are the decoupling agent in modern enterprise computing architectures and are as important as services and processes. 

Van Huizen: The potential death of middleware has been highly exaggerated! SOA middleware is among the fastest growing segments of the software industry.  When you think about all the logic that’s moving from traditional application stacks to the cloud, you quickly realize that this is where the applications will live.  When we speak of enterprise mash-ups, composite applications and software as a service (SaaS), it’s easy to forget that you actually need infrastructure behind the user experience to make it happen.

It’s not unlike the portal projects we say five to seven years ago where some people mistakenly focused on the portal application but came to realize that the back-end integration behind the portal was where all the heavy lifting happens. —and to higher heights—than enterprise application integration (EAI) did. So get ready for an interesting few years ahead.