Hello again. This is Vance McCarthy, Program Director for Integration Developer News with another in our series of Expert Voices talking about the trends in business-critical enterprise architecture. And for today’s conversation, I’m very pleased to be joined by Hub Vandervoort, CTO of Enterprise Integration at Progress Software. Hub, welcome to Expert Voices.

Thanks Vance, always great to be here.

You know, Hub, you’ve called your session today “Discovering Dimensional Agility in Next Generation.” In it, we’re going to talk about how [enterprise] architects and IT operations can get more benefits from their SOA investments, both in people time and money.

While many of our attendees are well-versed in SOA, you’ve got some very intriguing new ways to look at SOA investments in that new dimension that I think will really help IT realize better benefits. Tell us what you’re seeing?

I think the new dimension really has to do with the “People” context.

The fact remains today, and quite profoundly at times, that someone can make a seemingly innocuous or insignificant change at one point in the distributing system -- and something way over on the other side of the world breaks. And, everybody stands back and scratches their head and they go, “Why did that break that way over there?”

And usually after a long forensic analysis, you figure out where the traceability is between those two things. Indeed, it amounts to some obscure relationship that’s hidden in the vast distributed system. And, indeed, SOA was meant to deal with that problem.

SOA is about loose coupling. And, you and I have spoken many times about a concept we call the 7 Points of Mediation. That’s a design center we’ve used for years here at Progress [Software].

We’ve architected our SOA products to think about how we de-couple technical aspects of mediations. Things like location; interaction model; semantics and quality of service -- all of these technical attributes that involve mediation. But, when we separate those away from services and push them down into infrastructure, we create the opportunity for the services at the end point to be pure. They’re not [tagged] with a lot of contextual constraints around those mediations and therefore they become more reusable.

But, as we’ve now moved through literally hundreds or thousands of deployments around SOA, we’ve begun to learn that there’s another aspect of loose-coupling that’s equally important. It’s the separation of the people that actually design, build and operate and deploy the services in the SOA architectures that are built.

So you’re saying that you can boost SOA ROI by helping companies better understand how the various roles or the various people that work on SOA projects design and build their solutions?

What I realized in several years of interacting with customers is that you can somewhat…[and this is an oversimplification], bucket people or customers into one of four persona types.

So to illustrate them here, the primary actors tend to be what I call the “services” personnel and the “data” personnel. There’s an interesting mapping between these people and the points of mediation that are most important to them. So the services person, for example, thinks about transports and protocols, interaction models and location abstraction. But the data person, while he may be aware of those points of mediation, tends to focus more of his attention on things like format and semantics, the meaning of data and ontologies.

The secondary actors in this picture are what I call “policy” and “process” people. The policy person tends to be focused on things that relate to quality of service and quality protection so security issues, auditing issues, compliance. The process person tends to focus on the two points of mediation that we call sequencing and error recovery -- so the steps that one takes to complete the work of the business.

Now clearly all four [persona] are important to the success of the SOA. But, what I find fascinating is how often people are confronted with the need to collaborate with other of those four persona types in order to get their work done.

So a simple example is, if a process person wants to do a simple order process, you know, I capture an order. I do a credit check. I pull some inventory. I assemble it. I box it. I ship it and I bill for it. That’s the level of abstraction. The process person wants to think about it and he may concern himself with what happens if the person doesn’t pass credit approval? Or what happens if I don’t have the raw material inventory in stock? And so on. So he thinks about the recovery procedures and so forth that would go around that. Now the services person on the other hand may produce a business service that says, “Here’s a credit check and it simply returns he’s qualified or he’s not.”

But underlying that business service may be a check to an in-house credit database, a call out to S&P for their current creditworthiness. We go to Experian, TransUnion and Equifax and do some checks there. We may do some Patriot Act Validation. We may do any number of things where the call test and [retest] a service and a call to TransUnion is this complicated web service with all these web service security certificates involved.

Now if the process person was trying to model a business process and all of a sudden [he also] had to deal with things like web service security certificates and SOAP headers -- all of a sudden, he’s outside of his realm of expertise. He’s thinking about business process optimization, not these low-level service interactions. And the policy person may be materially interested in whether or not his credit card number or his bank account number goes out the door encrypted or that we’ve audited properly for SOX compliance.

All of these concerns now become captured on the palate that the process designer is working with. And now three guys are huddled around the same screen. All that [are] manifestations of what I call organizational type-coupling. The key now becomes the question of whether I can separate these concerns from one another that these people can start to make asymmetric change. So the thesis [is to] separate the people.

So just to summarize, Hub. You’re suggesting that, to a very large extent, there is a huge value in seeing that while we’re adapting SOA as a loosely-coupled technology, we’re keeping tightly- coupled org charts, so to speak. So we need to make sure we loosely couple the technology as well as the people.

Right. Look at a classic SOA environment. Here I’ve got a distributed bus on a global environment, even a federated bus because it’s got, in our case, dynamic routing architecture links that’s separated into a multi-segment ESB. And just like I described here, the business process guy is trying to optimize his business process and all of a sudden the service guy want to change a service and it starts breaking the process. Or a policy guy says, “Hey, you have to start encrypting this data at a low level.” And now all of a sudden it starts feeding back into the service architect and the process architect’s work.

And then a data guy comes along and says, “Well, let’s change the definition of customer or change the definition of product.” And all of a sudden everything breaks because now the policies around that customer data are suddenly impacted and services that handle that customer data need to be changed to meet those policy adjustments. All of a sudden, these four people are coordinating with one another and if the tools aren’t built correctly, they’re literally coordinating around the same screen. And that’s not going to be a very agile change because these people have to schedule meetings and they have to meet and discuss and then they make their changes and they all have to review their changes and so on and so forth. What we really want to have is this notion of being able to make change at any one point, technically, so that I can go about my business, get my work and my projects done without having to coordinate extensively with others while at the same time knowing that I’m not going to break the system when I do that.

So that’s also a fascinating point about a barrier or a wall that many SOA project managers hit but don’t exactly know why. Are you saying here that I should apply my same principles of mediation that I do with technology to all of my domain experts?

That’s the essence of the take away. So you’ve got it precisely!

I’ve given a variant of this presentation to customers where they kind of do the, I should have had a V8 slap on the head and go, “Wow, you finally explained why I’m having the problems I’m having in my organization.” One of our customers wanted to do a large Pub/Sub arrangement to publish master data out to eleven different systems and that’s a perfectly loosely coupled technology. It should work fine but getting the eleven teams together, even to have the first meeting, took over 90 days to schedule. And when they got those teams together they realized one team was tied up for 18 months on a project and another teams said, “Well, this is a COTS package. We can’t change it.” And the other said, “It’s a mainframe package and we don’t even have the source code anymore.”

And another one was written by an SI that had gone out of business and all along the way, there were 100 reasons why none of those other teams could make the shift over to this loosely coupled technology. And in spite of the fact that I was using loosely coupled technology, the organization was so brittle that it was going to take three years to make the change.

So Hub, with all of this customer feedback for how this happens and how it can be resolved, take us through some of the solutions [and] architectures that Progress has come up with that will help address…this kind of people in-agility -- and yet keep my SOA technologies and talents in place.

We feel that separation of the technology at the SOA level really comes down to three buckets.

• Service mediation
• Semantic mediation and
• Policy mediation.

And if you can separate those three technologies cleanly from one another and then delegate those down into infrastructure, you can literally apply policy in a way that doesn’t think about the specifics of a given end-point service or the specifics of a given end-point data model. Instead I’m describing the policies in the context of the infrastructure and therefore anything that flows through it will adhere to those. But now the end-points don’t have to think about implementing that anymore.

And so a service mediation infrastructure deals with things like transport and location and interaction model transparency. Whereas the semantic mediation deals with the data meanings, you know, it’s semantics, it’s ontologies, it’s rules of behavior at the data level and then the policy framework gives you a way of declaring SLA and security and governance policies that are de-coupled from those other two planes of operation. So, in manifest terms, that’s the Sonic ESB; the Dataxtend Semantic mediator; and the Actional SOA governance platform.

And interestingly Hub, appropriately these three ways that Progress [Software] has parsed their technology dovetails pretty well with how many SOA teams already conduct their SOA lifecycle, all the way from design inception to operations, right? Is that fair?

The guy who builds the service is usually not the same guy who tests it which is probably a different guy who deploys it which is yet a different guy than the person who operates it.

Many of our competitors will come in and draw you attention entirely to one phase of the lifecycle or another. So without naming names, one in particular will focus on the build cycle and indeed by focusing all of your attention on the build of the service only and making it look so simple in two or three clicks, it takes you attention off subsequent questions that happen later in the lifecycle. Like, for example, how did you secure that service or make it fault-tolerant? How did you actually policy-enforce it in a way that is governable across all use-cases? Or how did you ensure that the semantics are consistent with corporate meetings of data?

Well, in fact, in doing it in two or three clicks, he didn’t actually solve those problems. He passed the buck probably to the deployment engineer to figure out how to deal with it or some other design engineer. And so he hasn’t really loosely coupled it. It’s kind of like he moved the fat part of the snake just further down the snake but the block is still there. And so you can turn to another of our competitors who focuses all of your attention on the operational phase. “Look how scalable we are! Look how performant we are.” Never raising the question, “Well what did you have to do back in the build and test and deploy phases to actually achieve that?” And it’s sort of obviated a whole bunch of very expensive build problems that had to happen upstream of achieving all of that.

Now, in reality, it may still take me four or five clicks to make the service and so I can’t compete with the two clicks perhaps but in the five clicks, I’ve already policy-enforced it. I’ve already dealt with the semantic questions. Not because I’ve passed the buck to the next guy down the lifecycle but because I’ve cleanly pushed them into infrastructure and decoupled those questions away from the service designer all together. I’m thinking about the whole lifecycle, not in terms of passing the buck to the next guy, the next persona that has to deal with the question but I’ve truly loosely coupled or decoupled those people from becoming interdependent. And that’s what makes it possible for me to poke on one part of the system with the confidence that I won’t break something way over on the other side of the system.

As we close, we show this dimensional agility as the three underlying pieces: Service mediation, Governance mediation and Semantic mediation. And we draw that as a triangle because well, (A) it’s the strongest geometric structure. But, it also shows there are three [facets] to be dealt with here.

And while they are certainly inter-related in the success of a SOA, they can be decoupled in the extreme. And when you achieve that decoupling, you get the agility you’re looking for. How you surround that with the right people and the right organizational decoupling that needs to go along with it is really what we’ve talked about here today.

And it was an excellent conversation.

Hub Vandervoort, CTO, Enterprise Integration at Progress Software. Thanks again for this terrific chat about how SOA in 2012 could benefit from a new persona view of SOA and that would lead to better agility, not just for my infrastructure but for my people. And as is our custom, we’ve covered a lot of good ground here so we’ll leave up these links so that folks can tap into more resources and information from you on this very interesting topic and perspective. Hub, thanks again.

Very good Vance. Thank you. It’s always a pleasure to be here.