In this podcast I spoike with Hub Vandervoort, CTO at Progress Software about his ebook titled "SOA: Socially Oriented Architecture". In this book Hub talks about a the people and management side of complex SOA environments that cross organizational boundaries, and what is necessary to enable people to work together effectively. Transcript follows below. Let us know what you think. Does this strike a chord with some issues you are dealing with in your SOA evolution?
Listen to or download the podcast below:
PODCAST TRANSCRIPT:
BGB: Welcome everyone to this ebizQ podcast. I'm Beth Gold-Bernstein, VP of the ebizQ Training Center, and today I'm speaking with Hub Vandervoort CTO at Progress Software about his ebook titled SOA: Socially-Oriented Architecture. Welcome, Hub!
HV: Thanks, Beth! Nice to be here.
BGB: Now, you say in the book that SOA opportunities are about technology but SOA challenges are about people, and that's why we need socially-oriented architecture. Can you please elaborate on this concept and tell us what a socially-oriented architecture is?
HV: Sure. Well, really the book is meant to draw attention to the fact that SOA as a technology is giving us the opportunity to reach farther and farther than we ever have. If you SOA to mainframe technology, client server, Web app even, what you can distinctly is different about SOA is that it reaches further and allows for interoperatability with more and more distant endpoints, not just geographically but perhaps organizationally and then also, that it allows for the first time a genuine multiparty interaction.
If you think about the fact that you might build a composite app that uses a little of UPS and little Salesforce and a little electronic software distribution and some Amazon and on and on, it's truly a multiparty transaction that's underway when you're doing that. And you couldn't characterize any previous generation of technology that way. And that's a wonderful thing. And as technologists, we tend to spend a lot of time on how that works and what the technical beauty of that is.
But in the experience we've had in rolling out now over 400 ESBs and very large SOA infrastructures, that attempt to approach these multiparty interactions at a very large scale, what we're realizing is there is as much a need for figuring out how to get the people in those various communities and different organization structures to work together in a harmonized way. And so it was a bit a play on words, but over the course of the last year and a half or so, as I talked with customers, I keep saying that "your SOA needs a way of," I mean, we use the word "governance" a lot but your SOA needs a way of interacting socially so that all the people who own their various bits of the SOA can work together.
And so, in essence, what we're really trying to do is juxtapose, maybe with the play of words, not only is there this broad technical interaction that's available to us for the first time with SOA but it's calling on us to come up with a much more sophisticated social interaction model in order to really realize the benefits of SOA as a technology.
BGB: Okay, now. You state that you need to get three things right in order for people to work together, and these are connect interactions freely; mediate policy actively; and control semantics precisely. Now, can you explain these things in terms of a socially-oriented architecture? Is it technology we're talking about here?
HV: Not exactly. Although while those three labels, the way you've asked to talk about the social side, what I try to do in the book was say that those three things are in fact the critical success factors for both the social and the technical side of SOA. And so, you know, labeled as such the technical side is that you have to get things to connect together, right? I mean, that's a foundational aspect in SOA and Web service standards certainly enable that much more cleanly.
The social face of that is, think about the relationships you have in life. And the ones that you probably call the best are those ones where you do interact freely and regularly and I say somewhat jokingly that there's a reason why your mom says that you don't call often enough. Because the more you connect with her, the closer you'll be to her.
When you talk about the policy side of things, clearly we talk about having policies for security and for audit and perhaps for SLA in the technical dimension of SOA and you need to have a way of expressing that and enforcing it. But if you think about the social face of that same point, you have social contracts with your children, your spouses, your neighbors, your colleagues at work, your community, your bosses, and on and on. And in each of those social contracts, while they are somewhat informal, there's a different degree of formality with all of them and in the social contracts that you maintain with each of those, I would suspect that most people feel like the ones where they can enforce their social contracts freely and comfortably are the relationships the best.
So, for example, if your best friend steps out of line, you should feel comfortable, you can call them on it and you can adjudicate that out and maintain the strength of your relationship. And so those relationships where there is active enforcement of policy prove to be the best ones in the social context, like they would in the technical context. When you move to semantics, it was interesting, some of the first times that I delivered this as a presentation. I was doing it in Europe. And in, you know, in Europe on a continent where they speak twelve principle languages every day, semantics becomes extremely important. In other words, you can't let idiom rule the day.
And so those semantics in the social community sense are equally important. And when you think about getting communities of dissimilar groups of people, different governance, different geographies, perhaps even different cultural motives and priorities and so forth, you have to be very clear about what your semantics are in order for those people to interact well in the same way that a SOA, despite different domains and heterogeneous technology needs to have a very precise set of semantics if it too is going to be successful.
BGB: Okay. That makes sense. And the other thing I think is very interesting that you talk about is federated interactions. And we've been hearing a lot more about federated service-oriented architecture. Can you please tell us what a federated architecture is and why is it relevant to the socially-oriented architecture?
HV: Yeah, well. This may be probably more than we can talk about completely in a podcast but certainly when you think about the nature of interactions at a technical level, the idea of getting, say for example, your connectivity straight. So your choice of protocol straight. In the communal sense, it's the idea that you want to be able to feeling and openly allow for communication.
If you think about security models and so forth in the technical SOA sense, what juxtaposes against that in the community environment is the notion of sovereignty. You know, freedom is a really important thing to the human existence. We fought for centuries about it and the idea that I'm going to have multiple domains interact with one another requires that the parties actually permit one another to be sovereign. And that clearly is possible when you are talking about a B2B relationship. That's the only way it can exist.
But surprisingly, inside of companies what you see then is that you actually have to deal with, you know, independence at the same time you're trying to get spanning objectives dealt with. Does that make sense?
BGB: Absolutely! The political realities in organizations, the ownership of information, and of systems. You want to play together but you still want to do things your own way.
HV: Yeah, exactly. And what I think really comes out of that is a very firm realization, it's one of the conclusions of the book. And I think this is the fascinating part of SOA if you think about it just in the sociological sense. That all those previous generations I described were able to be managed and governed comfortably with hierarchy. And when you think about it, hierarchy is such an innate part of management philosophy literally for thousands of years. We almost take it for granted, right? The pyramids were built with hierarchy and hierarchical management.
So, we almost take it for granted that hierarchy is the principle management tool you use all the time. The problem is that when you go into a multi-domain federated world, hierarchy breaks down rather quickly. People just don't like being ruled by somebody outside of their domain. And if you think about the idea of applying hierarchy to the governance and management of SOA, it will likely break down rather quickly. And in fact, it will break down when it tries to hit any level of scale by virtue of encompassing multiple domains.
So there's a from-to analysis you can kind of ask yourself, where management of IT has historically been done with hierarchy, we're moving to a world where the management of IT can no longer occur with hierarchy but instead has to occur with the notions of trust and commitment. That's very different from command and control hierarchy and it calls for new tools. And it calls for a dramatic shift in the way managers need to think about managing.
The worst failures in SOA that I've seen have been those where they try to employ a very federated environment and capitalize on reusing services in other domains and so forth, but then they try to manage it with absolute hierarchy. Because what you find is that the domain members tend to want to secede from the union, so to speak. So that's a very critical transition that SOA is bring about in the management philosophy domain and I'm trying to surface it by way of this book to have people understand (a) that is a change. Many when they hear that for the first time, go "Holy cow, that's exactly what's going on and I just couldn't put words to it." Now that they see it as a shift from hierarchy to a management technique that employs trust and commitment, they know now how to approach the problem."
The second aspect is once you hear, well, okay - if trust and commitment are the mechanisms I gotta use, how do I actually implement that. And there again our technology employs capability and offers features that directly address those questions.
BGB: Excellent. The imperative for change and how this is impacting the way we're going to actually do IT to support the business. It's not just about the technology. You can't succeed on technology alone, which is what we've been saying all along, right?
HV: Sure! And this just tries to add more color and clarity to that through, by way of you know, an interesting juxtaposition of a use of the acronym SOA.
BGB: Aha. Well, it's very interesting and in the blog post, we will give everyone a link to the, your ebook. So thanks for taking the time to talk with us today, Hub. I really appreciate it and this is Beth Gold-Bernstein signing off for ebizQ.
Leave a comment