SOA: The Time to Value of IT

A Transcript of a WSOA Interview with Hub Vandervoort, CTO

Posted: 06 Nov 2007
Listen to the podcast on Veotag >

DEMPSEY:
One of the challenges, I think, before us, in this market of selling fairly complex technology in a fairly avant-garde kind of market is when are we simply seeking out about technology for technology's sake - often basing our decisions on what's the latest trend, who's the hottest company, and what tools and technology I should be using so that I can appear to be hip and happening in my IT department. I mean, why do we go ahead and invest in these very complex technologies. We're in business, we're in business to make money, and more importantly we're in business to create value for customers. In our case, we're in a business-to-business world and we're trying to improve the quality of an enterprises' business life, and make them more effective, productive, and better able to serve their customers. So, wouldn't it be great if we could have a conversation about how technology really helps a business create additional value. How can we follow a kind of chain of events that explains how this fairly arcane technology can be understood and connected to helping a business change the way they deliver value to customers. And, then would it be great if we could find some connection points right between fairly low-level technology and the high-level benefit of what service-oriented architecture (SOA) is meant to bring, which is business agility.

VANDERVOORT:
Hmmm. Yeah. No, I definitely think that there's a way to talk about it. And there's no doubt, as you know, that from the literature and all the pundits out there talking there seems to be a disconnect. On one hand, you've got the technician talking about standards and interoperability, and then on the other hand you have the sort of platitude artists who talk about time to value and agility - there definitely seems to be a disconnect. And, there's no straight line between the use of a WS standard and accelerated time to value of business. So, being that it's not a straight line, it may be that it isn't the simplest, uh, notion to grapple with. But if you build a chain of logic, there is a way of perhaps expressing this and connecting the dots that goes from top to bottom. So, the chain of logic that I like to establish is, at the top level, I think we can say that SOA is meant to at least be about accelerating the time to value of IT systems. And if you just started the chain of logic with that first link, then, you have to ask, well, how's that going to occur?

DEMPSEY:
So, let me just pause you there for a second, just to be really clear, that for a given project or initiative, think about shortening the amount of time - or at least making it much more obvious what the return is on an investment of people's time and money in a bunch of software - shorten the time it takes to see how it does that affect the bottom line or improve the top line, or something like that.

VANDERVOORT:
Absolutely. I mean, and even the way I'd put that too, is people frequently talk about how useful SOA has been because they've gotten faster release cycles. Well, to the technician, that looks useful, but the way I like to phrase it is, what's the time between when the line of business asks for something and when they come back again and say, "thank you very much, that's exactly what I was looking for"?

DEMPSEY:
Oh, yeah.

VANDERVOORT:
And, that time is what we're trying to shorten here - the time where a line of business can ask for something and get it right away. And the truth is that today, most people will conventionally say it takes six to nine months on average. Some people can do it in 90 days, but those are the kind of latencies that IT proudly hold out as their accomplishment. We've done, you know, a release in 90 days. Line of business's expectation, typically, is ten days. That's what they want and anything less would be unreasonable. But ten days, how much more time do you need to make the simple business change I want? That's their expectation. So that's why we talk about accelerating time to value of IT, its getting in alignment with line of business's expectation of what change cycle time should be.

DEMPSEY:
So a line of business guy has got a pretty high-level idea of what it means to improve his process or to add more value to the business.

VANDERVOORT:
You bet.

DEMPSEY:
And, by the time it gets to the technologist, it's got to become a much more detailed, specified set of steps to take. So, how do you break it down. I mean, and I think that probably contributes to this great gap between, I'm the business guy and I want something to change, or I need something to improve. OK, you've got ten days to do it. And IT, who really has to go build it, make it happen, deal with the problem in much more detail and ensure it's going to work reliably, scalably, etc., they see that as a nine-month problem. So how do you decompose the steps? Because that's a big gap...

VANDERVOORT:
Yeah. No doubt. It comes from two ends at the highest level. In one case, it's empowering the user more to express what it is he wants. So move the solution closer to the problem in that conceptual idea. If the user, knowing what he wants, can express that more clearly and more quickly, he can probably get the results faster. The other end of it comes from the technology side. The current state of the art, or prior generations of state of the art, didn't allow you to reformulate the technology very quickly, notwithstanding that it wasn't very close to the requirement in the first place. Even if you got the requirements correctly communicated, there was still just this complexity in making it change. So, you know, at the technical end, we talk about standards as relieving some of that constrain. And that's goodness. But then connecting that back to time to value is still somewhat of a disconnected idea because it's not a straight line. And so that's where the decomposition starts in this chain of logic. So if the first ring is time to value of IT, then the next link in the chain is alignment of IT function, or the service they perform, and the business, and the service they require. Now, that sounds like the next step down. Certainly, IT will accelerate it's value if those things are in better alignment. And again, the platitude guys talk about that as one of the overarching values, but again, it doesn't connect all the way down to why web services then?

DEMPSEY:
So who's the burden on at that point? Is it the business guys being able to understand better how to express their needs in IT terms, vice versa, or some combination of the two? I mean, it sounds like you've got a kind of a Tower of Babel problem there, where people are speaking different languages, and I mean, how do you close that gap?

VANDERVOORT:
Well, I think the point I just made is that, on the one hand, if I can allow the user to self-enable the on-demand concept -- you know, empowering the user to do what he wants, that's one way to attack the problem. IT can become a facilitator in that, rather than building the solution, build the "enablers" for the end user to build their own solution, would be the concept there, and that's what SOA is, certainly in part, if not in large part, actually facilitating. On the other end of it, though, is breaking the technology barriers. Can I get through standards and other things the mechanism where I can reformulate IT solutions more quickly -- just at the basic mechanics of doing the job? So those are the two cruxes, but that now begins to bring IT and business into closer alignment. But again, it still doesn't answer the question, why web services?

So let's move down the chain to the next level. If IT and business are better aligned, the next link in the chain, then, is agility. So, in other words, business is going to make up their mind on their own timetable. They will have their own external stimulus and reasons for wanting to change what they want to do. So their motives for changing the IT function that supports them will vary widely, but we can take as a constant that they will change their mind with regularity, and probably with increasing frequency. So the business agility concept says that the alignment is brought about by the two parties, business and IT, being able to more quickly reformulate the solution in order to meet the business value requirement at hand. So that's the third link. Now, agility still sits up at the platitude level. Again, not answering directly why web services, but it begins to decompose how we break the problem down.

DEMPSEY:
And, historically, one of the barriers to having that degree of flexibility -- right? I'm a guy who runs a business. I want to think about a business process change I want to implement, and I want it to just be so.

VANDERVOORT:
Exactly.

DEMPSEY:
One of the big barriers to that, historically, has been just silo applications and, as you know, hardened concrete walls around business applications.

VANDERVOORT:
Yeah.

DEMPSEY:
So, clearly, there's no hope of achieving that, if we don't embrace the kind of disintegrate applications, decompose -- you know, just take the jackhammer out to the hardened concrete around these business applications and get them to be more manipulatable.

VANDERVOORT:
Yeah. Well, and I think that's what leads to the next link in the chain - reuse. The business user knows today that he can do what he needs done. Most often, the function exists somewhere in the business. And if it doesn't, he can imagine how it could be created very quickly. The problem is, as you point out, silos, that, yeah, the function exists in silo A, but it's needed in silo B, and there's simply no way to reuse A's function in B's context.

DEMPSEY:
Yeah, sure there is, someone in Department A can get on the phone and call someone in Department B and ask him to execute the service for them and call them back with the result.

VANDERVOORT:
Yeah, well, and that's how it happens today. Email and word docs and phone calls are our primary mechanisms for getting that work done. So many times, the function is already available, but it's locked inside of some box that makes it non-reusable in the next context. And so re-use is clearly that fourth link in the chain. And so, now, we begin to bridge into the IT world, and we begin to start seeing, maybe the vision of how the dots connect all the way to web services.

DEMPSEY:
So, we started out kind of at the - I love that term - the platitude artists. We started out in the really rarefied ether of the platitude artists with this concept of time to value of IT, and we broke that down a couple of steps further. So, first step, you've got to get stronger alignment and better communication. Almost, you know, kind of more formal contracting going on between IT and business. There needs to be much clearer understanding there about the business needs and the IT requirements.

VANDERVOORT:
Yeah, move the solution closer to the problem.

DEMPSEY:
Right, exactly. We're going to achieve some notion of business agility, when we have -- if I could use just a simple term -- when we have more Lego blocks to assemble in more different ways, right? And the fundamental concept that's going to get us out of the platitude artist realm and start talking about the technology is that, at the core of that, is having these components, I suppose, designed so that they can be flexibly and scalably reused. OK. So now we're at this kind of high point of components driving the agility of an aligned IT and business department and accelerating time to value. So let's go turn the corner and talk about, you know, the other side -- more of the technical details behind it.

VANDERVOORT:
Yeah, and I think, you used the term before we got started -- fulcrum. I believe reuse is the fulcrum where the business time to value starts to intersect with the technical. So how does reuse come about? It presumes interoperability, or SOA integration. I mean, at the end of the day, [Daryl Plummer] has a statement that says components that are interoperable natively, and don't need to be integrated. Or, stated another way, two things that are not natively interoperable would need to be integrated in order to become interoperable. And so reuse fundamentally depends on interoperability, and so that's where we begin to reach into why Web Services? So, at the end of the day, if I need to make components reusable, I need to make them interoperable. And sometimes, if they are based on standards, and they have common standards, then they are natively interoperable. They don't need to be integrated, in other words.

DEMPSEY:
And there are those who believe that if you go down a really hardcore standards route, and you upgrade to common standards, you get into least common denominator kinds of functionality, and presumably, it's not going to satisfy everybody's needs to be purely based on public standards. There's always going to be a need to protect a little bit of my IP, and we're going to go an entirely standards-based world and have pure interoperability are we?

VANDERVOORT:
Well, no. I mean, I think that's an idealized view of the world. I suppose within a given scope, you might be able to say that's a true statement, but in a very small project team in a very small environment, yes, I might be able to force a single standard among all of them. But the point you make about least common denominator is very real. Web services is a very broad set of standards. And yet, we had to create what's called web service basic profile in order to even get agreement among all the WS standards and allow for true interoperability out of box or through a default configuration, if you will. And while WS basic profile does, in fact, create interoperability natively, it is a least common denominator. It would only support 10 to 20 percent of the use cases out there, in terms of it's quality of service, performance or whatever.

DEMPSEY:
Now, for my benefit, just to make sure I understand -- WS basic profile is that core set of the four WS, or six or whatever is it, standards that everybody agreed they would make the standard implementations?

VANDERVOORT:
It's actually narrower than that. The WS basic profile is an implementation of http soap that ratchets down some of the choices you have even within that single specification, to a point that, when it comes out of box, it works, first time every time. Yeah. Very, very narrow. Very simplistic.

DEMPSEY:
Wow.

VANDERVOORT:
And so, while that's useful in and of itself, it is hardly useful in all contexts. And so, that's where the second point really comes about - SOA, at its foundation, is about reaching further and further. It's about reusing things that are further and further away from me that are not necessarily mine. I might reuse Google and Amazon and Salesforce.com. I may reuse services from other departments, and so forth. So the chances that we're all going to align on the same standard across all those domains and communities is next to impossible. I mean, certainly, I can't make Google do what I want, and if I don't align to them, then we're not interoperable. So the missing link, the piece of the chain that connects standards to true universal interoperability across all the possible variations of standards is integration. And that's where the link that ultimately affords true reusability. We talk about what does the integration need to be? That's probably another subject. But the seven points of mediation are what make that a true usable integration across all possible contexts so that now, irrespective of the standards that I'm using, the bottom link of the chain. We all have standards - we're probably going to choose some in common and some differently, but those standards now need to be bridged through integration in order to create interoperability. That interoperability now gives me broad level reuse, and that broad level reuse then promotes agility, which allows IT to remain in faster alignment with business, and therefore the time to value and IT is realized.

DEMPSEY:
So how much time is it going to take us? Really, broadly, across the economy, to really be approaching much more rapid time to value with this technology. I mean, when we live in this industry and our patience doesn't run very long, as soon as something looks like it's starting to get well understood and stabilized, oh, that's mainstream, we've got to move on to the next thing. Where would you say we are in adoption and how long is it going to take to accelerate time to really broad-based embrace of these kinds of concepts?

VANDERVOORT:
Well, let me try to answer that in two ways. I mean, one is, I tend to be an optimist on timelines, so I like to think that they're going to happen faster than they in practice actually do. But I think that we're probably at the front door of a transition that's going to occur over the next five to 10 years. You know, over the next three years, people will actually put a lot of these foundational capabilities in place -- the requisite standards and the requisite integration capability. I think you'll see that go into place in the next two to three years. What is happening is SOA is breaking out of the small experimental projects and moving into the real production domain. And as you see that happening, what's happening is reuse is starting to tick up. So applications may be built from five percent reusable components today. But as it moves beyond ten and toward 50, we're going to start seeing that we're incrementing the number of units of beneficial work we're bringing to the business, without adding to incremental management overhead. And that's where the scale will start to tip. When applications are built of greater than 50 percent reusable components, I will substantially increment the units of incremental business value, without increasing my management overhead, and that's where time to value will really start accelerating. And I think the foundation points being laid into place are happening today. I mean, certainly, our customers are seeing that kind of result today in smaller scale and smaller scope. But as they reach out and start reusing services over broader and broader populations and geographies, and across organizations, that's really going to start to kick in.

DEMPSEY:
Well, that's great, helpful, and very informative. But I'd like to T up a concept maybe we can bridge to and talk about separately. You've described this nice kind of chain that links the platitude artists big honking goals around agility and time to value and all that kind of stuff to really the block and tackle work of embrace of standards and integration and everything in between with kind of reuse at the center of that. As I envision a world in which business people, have all this flexibility to go out and reach, as you say, all over -- well, all over the planet -- for services they need and can assemble them in many different ways to drive their business needs. It seems like there's a ton of detail behind there about how to make all that stuff work smoothly, seamlessly, and how all the tiny little marginal differences between how people design and think and send and receive and transmit -- it sounds like there's a ton of detail to discuss there. So why don't we come back and talk about that next level of detail and just what is it like in that world, where you've got so many heterogeneous systems and processes trying to communicate with each other, and to try to mediate their differences.

SOA: The Time to Value of IT

Related Topics