Editor's Note: Interested in the future of SOA, then sign up for our 2 day SOA in Action Virtual Conference coming this Oct. 28-29 right here.
What follows is my podcast with David S. Linthicum, an internationally recognized industry expert and thought leader on cloud computing, SOA , Web 2.0 and enterprise architecture. In this podcast we discuss SOA: it's death, rebirth, and bringing SOA to the next level. We also discuss David's participation in the upcoming SOA in Action Virtual Conference.
Listen to or download the 8:31 podcast below:
---TRANSCRIPT---
PS: First of all, what is your take on this whole SOA is dead business?
DL: Oh, I think even if you talk to Anne Thomas Manes it's much more complex than that. So she was really pointing out the fact that people were having a hard time with the complexities around SOA and in essence, those guys just kind of decided to declare it dead. And part of the way to kind grab attention to kind of a problem, I think a lot of the analyst in the market we were seeing at the time. And also, to shine a light on the fact that people weren't doing SOA as effectively as they could be doing.
So what's going on now is people really kind of understand the practical value of Service Oriented Architecture. I think that the vendors, and the hype, and even some of the analyst and a lot of the press were writing checks that quite frankly couldn't be cashed and the whole the SOA concept was being setup for failure. So I think that we had around the old SOA is dead thing is its normalization of expectations in terms of we can do with SOA where it's a practical fit and really looking at it for what it really is. Not as a savior to IT, not as something that can fix years, and years, and years of bad architecture but something that is able to provide a good approach in architectural patterns to doing enterprise architecture correct.
A number of companies have experienced performance issues when implementing SOA. How do we get around this type of issue?
Well, you have to expect performance problems in any kind of federated distributed architecture, which really, Service Oriented Architecture is and we've been doing these for years and years and years. So it's really a simple process. As you start moving toward a resolution, you need to understand and define performance requirements for the particular architecture. In other words, how much time should it take for information to flow through the system, from the user all the way to the database, and from the database all the way back, and to all the points that are interested in consuming those services and leveraging services.
From there, we can create a model of what the service interactions and information flow is going to look like. Then you do some prototyping and some testing to figure out what kind a real performance are you going to experience when this thing goes into production. And from there, you can create some very rudimentary mathematical models to figure out where your performance issues are going to be. And by doing that, you're able to provide a good understanding of where the performance bottlenecks are going to be and work around them, use different products. Perhaps you may not want to use Web services in some instances; you want to use transactional kinds of systems. And just understand what you're getting into model performance and if you do see issues there's always a way to engineer rather round them.
Now, as you're going to be hosting the roundtable on the Convergence of Cloud in SOA at the SOA in Action Virtual Conference, do you think the pervasive use of cloud computing will expand or contract the use of SOA?
I think is expanding exponentially the use of SOA. And it's funny that people that are using it don't really know they're using it. So if you look at what cloud computing is, it's really kind of the mother of all federated architectures. We're looking to leverage all of these assets typically through APIs or services there out outside on the platform of the cloud and we're accessing storage services, and information services, and services that are around CRM applications, and services around ERP applications, and we're consuming those services inside the enterprise and leveraging them with our on-premise systems.
So that's Service Oriented Architecture at its essence. So what people are doing is they're moving out into cloud computing. And I wrote about this in my books Cloud Computing and SOA Convergence in Your Enterprise. They're really looking at the patterns of Service Oriented Architecture to be kind of the foundation in how they're moving to the cloud. So they're taking their existing "as is" architecture, they're breaking it down into a functional primitives or cluster of services, and behaviors, and data.
Then figuring out from a logical point of view which services data and processes should exist on the platform in the clouds and which one should exist on-premise, looking at security requirements, performance requirements, privacy requirements, compliance requirements, all those sorts of things. And then, when they deploy it, low and behold, you have a Service Oriented Architecture because we're addressing all of these distributed systems as services.
We have to have a very robust governance infrastructure in place that allows us to control and manage, change and log, and do the whole transitional stuff as we operate these services in a real-time state. And then ultimately, the ability to put these things into various security models that are right for the particular architecture, in this case, is what I call a Service Oriented Architecture using cloud computing.
Now you mentioned governance, and it seems that those coming from the design-time SOA governance, they seem to be floundering where runtime governance seemed to be exploding why exactly is this?
Well, I think the design-time guys had good intentions of that. If you're going do governance, you're going to have to go through a very robust design phase to really kind of design the policies correctly around the services that are out there. However, the aspect of runtime governance became a lot more valuable to people that are implementing Service Oriented Architecture. And now people that are implementing Service Oriented Architecture are using cloud computing. Because at the end of the day, the real value to SOA governance is the operational value, the ability to kind of wrap these policies around these services that are operating in runtime, making sure that they're not doing anything wrong, that the people who are leveraging the services are authorized to leverage the service, that they have clear and concise goals and objectives that are wrapped around them.
We have it implemented in a security infrastructure able to track changes to the services. So if someone changes a service where lots of other services or lots of other applications are leveraging the service, they don't break lots of stuff and it becomes more and more important as our architecture becomes more and more federated, and more and more distributed. So moving to cloud computing creates a natural need for runtime governance. And they provide some good enough design-time environments within those systems. And ultimately, it's going to be very domain dependent. So the design-time guys are going to have to reinvent themselves into the runtime space or find some other niche in the emerging cloud computing meets SOA marketplace in order for them to survive, in my opinion.
That makes sense to me too. Now, what do you see for the future of SOA?
I see huge amounts of growth in SOA where no one's caring about SOA. I think the buzzword as I've been saying for years, and years, and years is eventually going to go away. We've been doing SOA, Service Oriented Architecture as an architectural pattern predating the birth of the buzzword, and predating the book the TLA. We been doing it since I've been in computing. We just formalized it and became more interested in it as a discipline and put some pretty good and nifty technology around, now we have to move into the cloud, which is basically taking SOA to another level allowing us to extend our architectures outside the platforms that we don't happen to own nor control.
So eventually, Service Oriented Architecture, which is what it is, is an architectural pattern will be something that just becomes innate. It's a good architectural practice. So it's good architecture instead of Service Oriented Architecture. It is a, kind of the de facto standard approach in way in which we design and deploy and architect our existing environments in our system.
And I think that eventually it's just going to be very much like good programming, we object-oriented (Inaudible) with all that and a bag of chips when it first came around, now it's kind of the way we do something. And it's already built in there, we don't talk about it much but it's in there adding value each and every day, and I would say that its probably 20 times the size that it was 10 years ago. And I think Service Oriented Architecture is going to go along the same way lines. That eventually, it's going to become an innate architectural pattern, it's not going to be as an exciting thing but it's going to provide a tremendous amount of value, and the use is going to explode as we move into these complex and distributed and federated systems.
Great to know, David. And everyone listening to this, I recommend you pick up David's book, Cloud Computing and SOA Convergence in Your Enterprise: A Step-by-Step Guide. And make sure to check out ebizQ's SOA in Action Virtual Conference.
Leave a comment