We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business Transformation in Action

Joe McKendrick

Transcript: SOA Manifesto, With Steve Ross-Talbot

Vote 0 Votes

The following is the full transcript of a discussion between Steve Ross-Talbot and myself about some key takeaways from the SOA Manifesto, particularly the first core value, "business value over technical strategy."

(Listen to the podcast here.)

Joe McKendrick: Hello, this is Joe McKendrick, contributing editor and analyst with ebizQ and the SOA in Action site. I'm please to be here today in this podcast with Steve Ross-Talbot, European Technology Officer with Cognizant. I had the pleasure of working with Steve and 15 other individuals last October on development of the SOA Manifesto at the SOA Symposium in Rotterdam. Welcome Steve.

Steve Ross-Talbot: Thank you very much Joe.

Joe: As you know, it was quite an intensive week for the group of us involved in the SOA Manifesto. We probably were able to deliver this document, which has actually received a lot of commentary across the blogosphere, and ionosphere, and the industry in general. It took us about three to four days to actually develop the document, which is pretty good in terms of the work of standards committees. And Steve, you played a very auspicious role in the development of the manifesto. You provided a lot of input and really helped guide the direction of the core values and guiding principles that we established and I'd love to talk about some of the areas that you saw pertinent in development of the Manifesto.

Steve: Sure.

Joe: Why don't you tell us about the core value you feel is the most important and compelling and what you're thinking is behind the development of this value.

Steve: Good question. First for me, the most important one, I mean it has to be blogged about both in the negative context and the positive context, which is business value over technical strategy. And the naysayers generally has said what's this got to do with Service Oriented Architecture and service orientation. And those are the more supportive of the manifesto has from largely come out in support of stating what seems to be motherhood and apple pie but is something that is often is forgotten about. It's very important that people understand that service orientation and Service Oriented Architecture are ultimately not about technology and that's why it's so important.

And one may use technology in the application of service orientation and then deliver instant of a Service Oriented Architecture. But ultimately, the technology is supportive of delivering business value. So when we apply a service orientation focus, we look at business value always.

Let me give you one specific example. There's one large client that we're dealing with at the moment. They're launching a large program of work with nine workstreams. One of those workstreams is the service layer. The other eight are business specific. But when you look at the relationship between the other eight and the service layer, they all rely on the service layer to deliver things to them. And the only way of getting this right is to ensure that the service layer is subservient to the business value that those other workstreams have to deliver.

And the task of any enterprise architect and solution architect is really to ensure the correct sequencing of those business related works streams that drive the service layer workstream so that business value can be delivered over time and continuously. And that's really why business value over technical strategy for me is perhaps the most important thing to say despite the fact that so many it's obvious. It's an obvious thing to say it's a very difficult thing to achieve.

Joe: Yeah, it's interesting Steve. I noticed in the course of the discussion at the development of the Manifesto in Rotterdam that we had to constantly keep revisiting that idea that its business value over technical strategy. The conversations, and the discussions, and sometimes the heated arguments we were having over the various other values and the guiding principles, eventually we had to kind of set our course back to this particular core value about this particular aspect, business value.

Steve: Absolutely. I think it drove a lot. I mean it's interesting to go back to the very first statement that service orientation is a paradigm that frames what you do and Service Oriented Architecture is a type of architecture that results when applying service orientation because the discussion that led to that was largely about the idea that you can't buy a service-oriented architecture. And so, once you've established that you can't buy them, then it's something you have to build. And if you're going to build it, and there's a budget attached to it, there must be value that you're delivering. So I think the minute that we frame that particular statement in the very beginning of the discussions, it was actually inevitable that we would say something like business value over technical strategy. It becomes so blindly obvious to everybody.

But sometimes -- my father always used to say that common sense is an interesting kind of common sense because it's not common -- we need to state the obvious despite the fact that it seems like common sense because by and large, if people did follow it, they would be more successes and than we currently have. And that's not to say there aren't many successes but there would be more, many more.

Joe: And you mentioned in your work with Cognizant you're out there in the industry every day working with companies, customers that are focusing on building Service Oriented Architecture. You find this is something that companies also have to buy into. There has to be a business value to really make this project work.

Steve: I think so. I think if you look perhaps four or five years ago, the beginning of this sort of SOA genre, people were going down the SOA route without any sort of view of business value at all. And as the economy fell into -- I think got more difficult to get budget, people started to look more at business value in general but not everybody, not everybody got there. So it's quite common for me to go into customer sites and for people to say how do I sell SOA. And of course, you can't because you can't buy it. And so it always comes back to well, you have to have the business focus. And the mission that we try to deliver for our customers and where we get called in is usually because they don't quite understand how to sequence those workstreams to deliver the business value.

So in a sense, it's kind of a techno-economic piece of engineering in order to sequence things correctly so that business value gets delivered, budget gets relief to do the next phase. And as a result, you start go build up a better way of managing reuse and handling change, and all of the other value statements then coming to their own. But this one drives everything for me.

Joe: And certainly with this economic climate, we seem to be pulling out of the recession but there's a whole new economic climate that awaits us. The world is much more competitive, it's global, companies really need to innovate and be flexible to really compete.

Steve: Absolutely. One of the -- for me, one of the principles that spends from this was -- and its one that I spoke quite a lot about during those three days was verify that services satisfy business requirements and goals. And I think it's fairly obvious as to why that links to this particular value statement. For me, that's been a driving force in all that I've done at Cognizant and even before. What I'm interested in from the technologist is how can we assist the architect, how can we assist the subject matter experts, the business analysts in order to ensure that the service contract match the requirements and the goals before we actually write a line of code and any technology that we can do to help that happen.

Any tool assist that we can provide will effectively lower the cost of delivering those services up front. And we've had some pretty good success within Cognizant of actually doing this, using a related standard, which was the Web Services Description Language and the tooling that's come out of the project called "Savara", which is Red Hat Project. And I work fairly closely with Mark Little on bringing that to market and making it available to everybody.

And the aim really is to shrink to the cost of that initial design and to get rid of design defects upfront. And what's nice about SOA and SO and the whole genre, is that because we dominated by the notion of service contracts, we actually have something that's fairly unambiguous that we can test against. So for the first time we have a contract that we can examine computationally and determine its correctness against some well-formed set of requirements. And for me, that's a really exciting area. And for me, that's the area that I think SOA tooling will lose towards to provide a much higher standard of governance and so reduce the ultimate cost of change, as people need to flex their infrastructures and architectures and services.

Joe: Steve, how do you see the SOA Manifesto itself helping to move SOA and service orientation forward? Is this now a -- do you see this document as a guiding principle to help folks such as yourself working with companies as well as enterprise architects and CIOs and so forth get a sense of what they need to do?

Steve: Oh, very, very, very much so. I mean I'm sure that many of my esteemed and partners in the Manifesto have already done their own whitepapers. Well, we've done our whitepaper on it, and that whitepaper has started to be released to a number of key prospects and customers, and they're genuinely excited because they suddenly feel that as consumer of this technology that they feel a little bit more control than they were before.

And one of the things that I think it's given the community as a whole is a sort of a standard language in which to describe what SOA is about,what service orientation is about, how it can be employed, and what some of the got you's are, or what some of the things are that you should really be doing. And that helps enormously because it reduces the amount of education you have to do for clients and prospects and they feel much safer in your hands. So I think we've done a -- as a set of 16 authors, I think we did an amazing job in that short period of time. I'd loved to have had more time but we'd probably just go around in circles for a bit longer.

But what I think we've done is tremendously effective and I think what we have yet to do -- I know that the annotated manifesto is out already. What we have yet to do in terms of adding additional information and clarity for this will only help us and the community more.

Joe: Are there any values or principles that you feel may have been left out or you'd like to see in SOA Manifesto 2.0?

Steve: There was one thing that we decided to leave out but that actually included in the whitepaper. And this is we actually decided to deal with business processes. And I actually feel that a very good way is promising the power of SOA and the power of service orientation is to think about processes because those service contracts don't live in isolation. You have a set of service contracts that somehow collaborate to actually deliver a business process. And so the thing that I would like to come back to if we ever get a 2.0, is to look at process orientation and how that impacts and uses service orientation as a genre.

Joe: Okay. Great Steve. I've been talking with Steve Ross-Talbot of Cognizant and also one of the authors of the SOA Manifesto that was recently released. For those who would like to see the manifesto, it's accessible on the Web at www.SOA-Manifesto.org. And Steve, I want to thank you very much for joining us today in this podcast and thanks for your contributions.

Steve: Thank you very much indeed, Joe.

In this blog (formerly known as "SOA in Action"), Joe McKendrick examines how BPM and related business and IT approaches can promote business transformation.

Joe McKendrick

Joe McKendrick is an author and independent analyst who tracks the impact of information technology on management and markets. View more


Subscribe in Bloglines
Subscribe in NewsGator Online
Add ebizQ's SOA in Action Blog to Newsburst from CNET News.com
Add to Google

Recently Commented On

Monthly Archives