This is the second part of a two-part interview with Peter Hermans, noted SOA consultant and former architect at a major European telecommunications company.

The Continuing Role of ESB
Strukhoff: So let’s talk a bit about ESBs and the role they play as you as you move forward to service orientation.

Hermans: It’s very important to see it from a business perspective. With web services technology getting introduced further, interoperability between companies will increase and we will see automated processes run across companies: The ESB will cross company borders and eventually industry sector borders as well; it will enable new value chains in an efficient way.

Strukhoff: This quickly leads to the questions of what business managers need to know about SOA, and what do IT managers need to know about the business when they're considering SOA?

Hermans: I see a lot of people struggling with that. So I use a lot of metaphors, and in this case I use the metaphor of a restaurant. You go to a restaurant and you want to have a nice meal. From the IT side, you can’t try to sell the cookbook to the guest in the restaurant. The business is not interested in the cookbook, the business is interested in the menu.

So my current thinking is that the nitty-gritty about how an SOA is comprised and what it all takes to build it, well, that's the trick of IT. Don't try to persuade the business with all those difficult things. Try to focus to them what it means for their business. That means that the IT people really have to think in business terms and that they have to learn to think and talk to the market as the business managers do.

Strukhoff: But yet the business managers need to be able to read the menu. How do you go about making sure they can?

Hermans: First by keeping it simple. Secondly by also teaching the business to think in terms of services. Let the business request services from IT and let IT figure out how to realize them--today with this application, tomorrow with another one, without business bothering with that. I think the concept of services has a very strong potential for improving business IT alignment.

Strukhoff: Why?

Hermans: Services is something the business understands because that is what they deliver themselves to the market. Since business has responsibility for the business processes—by the way, note that a process can also be seen as a “process”service that can be invoked—they just need to specify what service they need in each step of the process.

Strukhoff: Whose responsibility is it to tie benefits to what's being provided on the menu? Is it productive if IT can tie specific benefits in terms of TCO or in terms of increased efficiency or faster response or higher volumes? Is that helpful for IT to do that or whose responsibility is that to tie benefits to the services and architecture?

Hermans: I think it's somewhat shared. Today, the business is in the lead, the business has the budget and IT just should do what the business asks. But I think if the IT people—knowing what the capabilities of IT are—also know what the challenges and the opportunities for the business are, then they also have the responsibility to bring their knowledge on IT capabilities to the table.

I've done an assessment recently where the IT people complained, “well, the business is specifying the requirements, not only in the “what” sense but also in the “how” sense, and they came up with very specific requirements. Well, that doesn't fit in our IT so we have to rebuild our IT.”

The other side of the coin would be that IT asks the business why they need these types of requirements and with a clear understanding of that, proposing solutions that fulfill the business needs in a way that do not require a significant rebuild of IT—business and IT as equal partners around the table.

Strukhoff: Sounds like a dialog.

Hermans: Yes, because I strongly believe that success is strongly dependent not on technology but on how business and IT people work together. Also, the dialogue between all who work inside IT is equally important. Creating an ESB is 70 percent a change management and peoples issue; the technology is the easiest part. It’s crucial to pay attention to these issues since it will make the difference between failure or success!

Virtualization and Governance
Strukhoff: If we go back a little bit to where we're decoupling web services and we're flowing them through an ESB, today the topic of services virtualization is coming up. Is that something that business managers need to really get out in front of and, if so, how? Where are we with this concept of services virtualization and what do people need to know about it?

Hermans: The business should be out in front of this. Again, it comes back to thinking in terms of services rather then applications. For years, I've seen business managers formulating requirements in the sense of “I want this application to do this, this, this and that.” I said, "Stop, specify your requirements in terms of the service and then it's IT’s job to provide it."

When you virtualize your applications and expose them as services, the business might go for “SaaS” (software as a service) outside the company, and IT might start to exploit services to others outside the company. The boundaries of the company will blur. However, a lot of organizational issues need to be tackled here first. If you say the business should think in terms of services you should also have the right governance in place—for example, who owns the service.

Strukhoff: What sort of questions do business-side people need to ask about governance?

Hermans: First of all, if you have an SOA initiative, it depends on the ambition level of the initiative. Is it just a small implementation in a business unit, or is that you really start to do the first things of an enterprise-wide initiative?

If you really start on an enterprise-wide initiative then you immediately hit a number of governance issues because you are changing the whole IT structure. A business unit or business line manager will say “well, I just want to connect this application to that application. Create a point-to-point solution since that’s the cheapest and fastest way forward. And all these nice things about services and reusability, that’s fine, but I am not going to pay for that.”

As I used to say at this point, “the first passenger is not going to pay for the whole bus.” So this will require executive sponsorship, based on a vision and courage, to create a first set of services to build up to a momentum where the business starts to see the benefits of loosely coupling and (re)use of services. Within IT it requires strong business insight in defining the right services.

Strukhoff: Yet in doing so it sounds like you create more spaghetti.

Hermans: Not really. Remember that the process is not hardcoded and embedded in the application anymore, but in a different layer. You really need to talk about the BPM layer as a different layer as the one which delivers the services.

So in starting your SOA, it is important that you set up a framework. At the bottom you have your applications and data. Then you define your service layer, with your (composite) services and then your process layer. Even if you have a BPM layer in place, you might do process orchestration on top of that. I think that event-driven orchestration of processes has an enormous business potential.

Governance issues will have to be addressed at every layer. And let the business evolve your SOA implementation, no "only-IT" projects, please!

•   •   •

Follow the author at his blog or at www.twitter.com/strukhoff