David Bressler, Progress Software
Dr. Chris Harding, The Open Group
Chris Kraus, ITKO LISA
Jignesh Shah, Software AG
Phil Wainewright, ebizQ, ZDNet
Joe McKendrick, ebizQ, ZDNet, moderator
It is probably an inevitability that as more and more organizations adopt SOA, many are falling into the trough of SOA disillusionment. They are finding their SOA solutions do not perform well, or are not secure, or services are not being reused, or they are being reused in unintentional ways. Defining who is responsible for paying for service maintenance when services become a shared resource is becoming a real issue for many organizations. This panel presentation will look at the issues many organizations are encountering on their SOA journey, and best practices for avoiding common pitfalls.
Joe McKendrick: Today were going to be talking about SOA quote-disillusionment-unquote,. and I put the term disillusionment in quotes, because it's a loaded term that's being thrown around these days by pundits and analysts. We have to take a look at what's going on out there. What may not be working so they can do to set things right. We're probably asking a lot of IT. IT is being called upon to sell the idea of transformation to the business as a whole. I've always felt this was a quite a tall order for IT departments who are already overworked and overloaded with keeping things running. Dan Woods at Forbes. made an interesting observation, that SOA shifting burden of application maintenance and upgrades away from packaged vendors to the IT departments themselves. Dan Woods is saying when you have applications abstracted into a service layer, there may not be a vendor to run to when there is a problem. I'd like to call out a couple of other analysts statements that have been made in recent months. Gartner, for one, said earlier this month that fewer companies planning or considering SOA, and this may be a result of the difficulties of proving return on investment. Also, we heard from Anne Thomas Manes, Burton Group, who has been involved in a deep study of SOA initiatives, who said that Burton Group had only identified one company demonstrated SOA success so far.
I'd like to throw it out to the panelists.. What's your take on all this, what do you see beneath these headlines. Are organizations really feeling a sense of disillusionment about SOA? Is it too early to tell? Are there actually a lot of success stories? Are they underneath the radar at this point?
Chris Harding: My perspective is that of supporting the work of people from the Open Group's member companies on SOA. I haven't yet heard anyone come up to me, or speak in the group and say well, I'm disillusioned with SOA. I haven't heard that at all.
What I have very definitely noticed is that there's no longer an interest in learning about SOA. People are no longer seeing SOA as 'a great new thing' that they have to find out about. They're still interested in working on how you use SOA, how you do SOA governance, how you integrate SOA into an architectural framework. They're still interested in looking at those things. But what's disappeared is the SOA is 'a mystical new thing' that we need to find out about.
Disillusionment isn't the word that I'd use to describe what I'm getting. Its more a case of, 'yes we know what it is now, we just need to get into doing the detail.' And I'm sure I can remember more than one presentation at Open Group conferences that has talked about SOA success. So I'm not seeing SOA disillusionment from where I'm sitting.
Joe McKendrick: Perhaps it has ridden the hype curve, to use Gartner's analogy. Now it's more the nuts-and-bolts implementation, the lets roll-up-our-sleeves-and-get-it-done phase.
Chris Harding: You're right. The hype phase is very important when a new concept come up. Its very natural. There should be a huge buzz of interest.. people what to find out about it. As you said, we're into the sleeves-rolled-up-lets-get-it-done phase...
Joe McKendrick: David Bressler, you're out there in the market working with a lot of customers... what kind of perceptions are you seeing.. you see any disillusionment?
David Bressler: I'll take the contrasting point of view. Whether its disillusionment or not its just a semantic thing, I think it's the kind of thing where vendors, of which I am one, go out and promise the world to people, saying SOA is going to solve all of your problems. Great, because I have a lot of problems, let's bring it in. They brought in some stuff, they to one extent or another implemented an SOA, or some sort of SOA architecture. Maybe they even modified some of the way they deliver IT to the organization. They combined technology with process. Yet, they still have the same problems they had before, and in some cases maybe even more of them. Because now, instead of having a packaged applications where they can now go beat up a vendor, they now have ten services and they have to beat up ten vendors.
I've got three things that kind of come top mind as I was listening to Chris talk, and some of the introduction comments you made. But I think there's going to be more of a focus as a result of the economy as a result of whatever, on solving very specific problems. I'm working with a few customers, its it's the same old thing. From my perspective, we tend to focus on the space formerly know as SOA management or service management. But the idea is you've got a bank full of management systems, and everything is green, and yet something is still not working -- dropped transactions, Web page that's slow, data is not showing up, or maybe its not accurate. Those kinds of things. So instead of saying, bring in a SOA and solve all my architecture woes, that's a big problem in several vertical markets...
There's also the concept that change is still too hard. Integration has become much much easier. But, change -- anytime you look at something and say, I need to combine that piece of data, that still becomes way too hard. It's the lifecycle of the application, as well as just getting the coding done...
And finally, simple things just take too long. Put yourself in the shoes of a businessperson, someone who really doesn't care about technology. And you say, I need to look at geo information alongside of shipping information. I want to look at it either geographically, or by product or by some other way that I've imagined in my head because I know the business. Most IT departments will take a deep sigh...
And you mentioned my work in the financial community... ..on a lot of trading floors they have a lot of IT people who site there with traders... and they do this stuff on the spot in real time... ...and get in down to get products to market quickly... but the investment .... Is way too high...
Joe McKendrick: That's the ultimate form agile development... if the IT folks are sitting right out there working with investment managers working on solutions in real time.
David Bressler: Absolutely.
Joe McKendrick: Dave raises an interesting point. This is something that what the business understands and supports... companies looking for solutions to problems... they're not looking to build an SOA per say.. SOA may underpin that solution... should the emphasis need to be on the solutions... does the business really need to ... understand or support the fact that this is SOA... or is SOA something that plays more of a behind the scenes role?
Phil Wainewright: I was just thinking while I was listening to Chris and Dave saying their piece. A big issue here is the whole IT-business alignment issue. If SOA is regarded as a big IT infrastructure project, then the businesspeople are cut off from it. And actually the other problem is that its being designed without a clear view of what the business objective at the end of the day is.
That's one of the reasons why you might get a certain amount of disillusionment, because your still actually focused on the technology and not the business results. Perhaps SOA can solve all of our problems, as they said. Okay, it does solve some of the old problems, but when there are a whole lot of new problems that come along, the focus needs to be on what the business actually needs. And SOA can provide a much more of intuitive approach to problem solving that does make it easier to deliver solutions.. ...
The example of adding geolocation capabilities. I saw a demonstration on Monday of a developer that is writing in a SaaS environment that is offering small businesses. A GIS visualization system that they are actually are offering for free to work with QuickBooks data using the intuit in the cloud platform, which runs on the QuickBase database.
And so that is a great example. I think there are SaaS or cloud examples of SOA infrastructure that has been built for the specific business objective of being able to deliver solutions cost effectively to small businesses with a lot of mashup capabilities, which now vendors and developers are coming in and offering very cost-effective solutions that use the mashup capability to bring in the different functionality that interact with the data and can then be adapted to business results, basically.
Joe McKendrick: Phil, this sounds like providing mashups that the businesspeople can work with... it sounds like something that makes SOA real to businesspeople... SOA they can see and touch...
Phil Wainewright: Well it is. I think the concept of SOA is not something that is alien to businesspeople... ....because at the end of the day business is all about delivering services to contract... ...and SOA is all about IT delivering services to contract.. so I think it's a very easy concept for... people to believe... I believe a lot of businesspeople think if only that's what I could get from IT... ..if only I could go into IT and know what I was getting... ...
Jignesh Shah: Maybe I can add a little bit to that conversation... one of things that I've seen working with customers that have been successful with SOA, and this is something I recommend to customers that I work with... ...is that when you're explaining, trying to sell SOA to the business side, don't bother calling it SOA. because its not to say SOA is not relevant... to the business side... but what's more relevant is delivering services to the business...
Seeing IT leadership has been successful in getting business on board with funding their SOA initiative is, when they talk about things like, 'we have to do this to support your business process management initiative,' building applications, we'll help you build and automate business processes faster, or 'we have to do this because we want to rationalize our applications, we want to go from six applications that they're using today to quote prices, and bring it down to a set of common services that can be used uniformly across the organization.' Or 'we want to use this approach to building IT capabilities to help you outsource capabilities.'
That is what is quite effective in helping the business to understand the value of SOA. This is not to say SOA vision is not even necessary. It's not to say you should not have a vision,.strategy or a plan to go from A to B. But the way you sell it to the business should remain in terms that are relevant to the business..
Joe McKendrick: I've heard it said that the best SOA business proposal would not even mention the phrase SOA. It will talk about the problem and the solution, SOA practices and methodologies.will be there to make it happen, but it's not necessary to sell that aspect to the business.
Jignesh Shah: I would absolutely agree with that recommendation.
Chris Harding: This builds upon the point that Phil was making about the need to link into the business result. Because SOA in itself does not address any particular business need. What it does do is structure the IT in a way to make it a lot easier and quicker to address particular business needs when they come up...
In order for it to do that, you do need to take an overall architectural view... ...of how its going to be used within the enterprises... ...there are two traps that we see... people talking about... that you could fall into that might make an organization disillusioned with SOA... one of them is that you do SOA as a small pilot project, you don't think about how it fits into the architecture of the business as a whole... and then you find that you cant do anything beyond that first pilot project....
The second trap you can fall into is the opposite one... that you spend too much time on doing an overall super master plan... before you do any detailed work, and that can lead you to waste time too. ...master plan... ...so you do need to do pilot projects.. but you need to do them within a framework of.. ...an overall view of what the SOA has to achieve...
Joe McKendrick: Do you see too many SOA projects and initiatives... being designed without the long term in mind? perhaps building services and throwing them out there... without consideration of how it's going to play with the rest of the architecture... is that still a common problem?
Chris Harding: When you look at the analysts surveys... ...that show a decrease in the take-up of SOA.. that's because the initial take-up that they measure it against are really pilot projects... ...I think a lot of enterprises did experiment with SOA in a small way to start, and quite rightly so... ...but you do need to take an architectural approach... to the enterprise to move beyond that to a larger scale SOA in which you can deploy the infrastructure that you need to be successful and.. deliver business results. ...
Chris Kraus: The one thing that we're seeing when we're working with customers, you just said the pilot project versus a master plan architectural approach, we're finding that our customers who are most successful with SOA actually did some architecture, and decided they're going to have a consistent view of a customer object or an order object and actually redesign the interface to make sure it was reusable by multiple people. So the pilot wasn't to create a Web service to serve ourselves. It has to be something that is on purposely consumable by multiple people..
The people that we see are failing with SOA are the ones that say 'oh SOA is just Web services; I've got one big object, so all my Web services have one interface.' .. I'm just going to gin a WSDL in front of them. And they're not actually thinking from an architecture perspective. My goal should be, is this reusable by multiple people, because that's where the business side comes in. Everyone can has a single view of the customer, from an IT perspective, coding and testing in those timeframes...
Joe McKendrick: Chris Kraus, that's a great observation... one of the criticisms I've heard over the last couple of years about the whole reuse concept.. is when services are created... they're not created for reuse... created for the task at hand by the business unit originating the service... they're not thinking ... ..well a year from now purchasing may want to use this service.... So well to make sure that's ready for that as well... how do we address that long term?
Chris Kraus Quite honestly, it would be nice if we could say the service is going to be reusable next week. A lot of times if you think about mergers and acquisitions, and folding of companies and industries together, obviously, we're going to represent our customers differently, so we have to come up with some kind of common lingua franca on how we serve our customers. We're actually seeing people writing a service that's so specialized, they can even use it horizontally within their own organization...
We've delved down all the canonical models... and all the data modeling in the past... and we've tried to implement those things within our enterprise integrations... need to kind of look at where we fell short... in those areas... to say, when we represent a customer... do we need to represent every possible attribute about them? or ..do we split them up into smaller components... so that people have smaller things to consume, and they can reuse those easier...
If you think you're doing to get into the one uber... customer object that has every attribute about them... of course its going to be missing the one thing that people need... so if you keep them into smaller logical areas.. ...makes the smaller components easier to digest by the consumer...
David Bressler: I think that's all great from a strategic perspective. I think it's really important, and I agree with you. The challenge becomes as you start to deploy that within an organization is, how do you do that if you have a projects -oriented IT organization? They count hours for what they are doing. They bill it back to some part of the organization. The people are motivated and promoted and judged based on well they deliver projects, and not necessarily how well they solved problems for future projects somebody else is doing.
I think it runs into a lot more systemic problems with IT, even going back to what Jignesh said, is who cares whether its SOA or not. What the proposal needs to contain is how do we solve some of these fundamental problems? From our perspective as technologists, SOA is an awesome tool for solving these problems. But we're still just going back to solving problems, and not achieving SOA so to speak.
Phil Wainewright: The other thing here is you need to move away from the old waterfall approach to development, because I think that less appropriate in an SOA environment. Pushing services out there is a learning experience. You need to push them out into the infrastructure and see if people are going to use them, and maybe you need to fine tune those services before you get the right granularity and the right set of features. Certainly what you're seeing in the SaaS environment is that SaaS providers have to iterate through several versions of their APIs before they get their integration story right going into the enterprise marketplace. I think being ready for change is part of the mindset adjustment to SOA.
David Bressler: One thing that pops into my head as you talk about that, having multiple APIs.available and figuring out iteratively, whether it's a SaaS provider, or whether its an internal provider providing services inside the organization as if they were a service provider. I forget which SaaS provider it was, but I think the cost of their support calls for API-type SaaS kind of stuff is significantly, something like 4 to 10 times more expensive than a support call for somebody using their UI. So if we translate that over to an organization, if I deploy an off-the-shelf piece of software to a constituency of users. Or I say to my users, here are services, go build your own application, my support costs for that infrastructure are going to vary dramatically, and I need to allow for that in my organization, I need to allow for that in my budgeting. These are not necessarily trivial problems to resolve. Again, they're not necessarily technology problems...
We got some good technology, we've got some good ideas, and we've got perhaps the wrong kind of environment to apply those in many situations, and that might be the frustration, or the disillusionment we see.
Jignesh Shah: .Highlighting the other difference between the folks who are succeeding with SOA, and the ones that are perhaps somewhat struggling. The first thing said, as Chris and Chris identified was, you have to have an overarching focus on the architecture, how do you get the reuse, maximize reuse, is the organizational and the process issues that a lot of people that are struggling with SOA are probably missing out on...
If you continue to focus on the technology aspect.. and not the organizational aspect... this disillusionment or worse is almost inevitable... ....what I mean by this is one of the emerging best practices that we actually talk about in the book... SOA adoption for dummies... is the need for a competency center... ...the role of a competency center can be to provide architectural vision and organizational guidelines... make sure that people are building the right services... at the right granularity and it can be to deliver those reusable services...
Having a competency center has to be a recognition that... a different level of organization and a different level of processes are needed... to support SOA and to support reuse...
Chris Harding: Certainly a competency center.. is something that will help to achieve things on the technical front.. it will help to spread technical competence to achieve the definition that you deliver services that satisfy that concept if that service is to be reused. Also there is the question, perhaps SOA needs a cultural change within the organization.. and that's something that is very difficult to achieve... and perhaps more time is needed to achieve that change... than to simply put in a new technical infrastructure.
So the people talk a lot about SOA governance... and governance being important to the successful deployment of SOA... in my mind, that governance has to start with getting the culture right. That is perhaps what is taking the time and effort now...
Joe McKendrick: A couple of questions I want to throw out to the panelists.... Two related questions... First, how do you know when your SOA is succeeding... is there a way to measure that? and the other is how do you know when your SOA is not succeeding? With ERP and crm and these large systems, their failures have been legend.. in some case well publicized... you know when you need to tear up the system and roll back to what you had before... but how do you know when your SOA isn't delivering? You may have services that are being put out there and not being reused and adopted? How does a company know things aren't going as planned?
Chris Kraus: One interesting antidote I had from one of my customers. Is they felt they were succeeding in SOA when they change a service and multiple systems broke... because that proved that people were leveraging the services... the way they felt ...the way they were going to mature SOA... ..they can change the service, and all the consumers still work.... So they had the horizontal trust within the organization.... The governance and so forth... to make it work for multiple consumers at once..... so it was an Interesting idea... they're following the life cycle... ...they actually got usage... made a change and multiple things failed... ...how do we manage these things...
Jignesh Shah: Some of the other KPIs that I have seen, and actually have been published by our customers through press releases, what not... are things like what is the improvement in time to delivery. Or if these external-facing services, what is the difference in time to market... for new capabilities for customers and partners... Those are also quite relevant in terms of proving the value of SOA... to the folks in the business side.. is to say, definitely you have ... KPIs in terms of the use we are getting... and the cost benefit were getting our of reuse,... is there is a way to measure? There is a way to measure the cost to your business... in help to adapt to making these business changes faster...
Joe McKendrick: It is sometimes difficult to measure the impact KPIs? Difficult to measure impact SOA is having versus other initiatives.... A well-run company that is forward looking...and has good management is likely to be taking a variety of strategies... SOA being one of them... moving to the cloud, data warehousing initiatives... .... business intelligence.... its like an orchestra... and every class of instruments its part to this ...beautiful music... and SOA is one of those... how do you weed that that out and determine what role SOA is playing?
Jignesh Shah: In a lot of these cases... as the investment is made around specific initiatives... or around specific projects... it is fairly straightforward to identify... the impact of using an SOA approach, to integration, for example.. what is the impact of using an SOA approach to integration as an example... what is the track record when we were using a more classic EAI style? Or what is the improvement we delivered in terms of automating business processes and bringing down cycle times?
So generally as you're applying... these things to a specific business problem... yes there may be additional elements that may be able to contribute to it, but if you have sufficient focus you should be able to isolate... this is the advantage we get in terms of being able to change things faster.... Or being able to create new things faster... Most IT departments have a history in terms of how long it takes in doing these things... so you also have a benchmark that you can compare against...
Joe McKendrick: Another challenge with SOA is the expectations that arise around SOA. In fact, in some cases, SOA may become a victim of its own success, in that a lot of business units start subscribing to a service, but the provider of the service may not have the capabilities or capacity to keep things up and running on a 24x7 basis. Or they may be making unexpected changes to a service. They may have a situation where services are constrained by their owners. The services may be unavailable when they are needed by consumers, and so forth. Panelists, are you seeing this as an issue as well? I guess trust comes into play here, the ability to maintain or rely on services from other parts of the organization, or perhaps outside the organization. Is this an issue?
Chris Kraus: We're definitely seeing the need for agile development and moving from spiral development.... Which we mentioned earlier.. teams are building ...systems in parallel... they may not have access to what the other team is doing... ... or the service may not be available yet because they're behind schedule... or it could be there are constraints on the system.. maybe they only have access to a mainframe... that's only available for only a few hours a day...
A lot people think of virtualization in terms of hardware... ..we think it in terms of the behavior of the service... if I give you something that looks like the Web service and acts like the Web service....but actually a virtual version of it... People can code against it initially... ...or you can load and test against it... people are asking for this...
Software as a service... will play into this... ...but when it's team to team working together.. maybe because there's lot dependencies or constraints...there... so having behavioral.. virtualization of a service for people to code against... do ...load testing...against... ...or having people able to send a purchase order... so they wont get rejected because they don't have good data, things like that.... those are becoming important...
Chris Harding: In the days when SOA was bright shining new... there were a lot of promises made about it, a lot of things said ... ..things haven't come completely true or have become difficult to achieve... ...than you would have expected initially. That always happens when you have a new technology... or a new way of doing things is brought in... SOA is a paradigm shift... it will take time for the industry to digest it, if you like. And it wont be a case of all the promises being met. It will be case of people being sufficiently happy.... With what they can achieve with SOA that they carry on using it.. and build on it to go in ..further directions like integrating it with the cloud... ....my feeling is that yes, that is the way that it's looking... but it's probably too early to tell... for sure...
Joe McKendrick: I want to go around to our panelists on what you see in the year ahead... ...in particular the economic conditions... were seeing these days. will a tightening or tumultuous economy that unfortunately may continue on through 2009.. do you see that as changing the way that organizations look at SOA? will organizations look to SOA-based methodologies to help streamline operations and cut costs and so forth... or do you see perhaps cutbacks in SOA programs? Organizations may need to trim back their SOA efforts... let's start with our Wall Street guy... David Bressler... how do you see SOA playing in a very rocky economy?
David Bressler: I think were going to start to see vendors focus less on pitching SOA.. and more on pitching solutions... from the vendor perspective, I think we'll hear a little bit less about it... I think the Technology is in some sense maturing... to the point where it can do that. Obviously people are going to make cutbacks... ...I think they're going to make cutbacks where they cant measure a clear benefit or a clear improvement... over the way they're doing things now... I of course believe SOA technology can help them measure that improvement, but that's a different question...
Joe McKendrick: Jignesh Shah, do you see SOA coming under the budget knife?
Jignesh Shah: It will differ based on two things. One is, where is the company today with their SOA, and b) what kind of company is it in terms of its response to bad economic conditions in general. Let me clarify that. If a company has already embarked on a SOA... and has been doing that for some time, I don't necessarily see them scaling things back, because for them this is the way they now build applications. As long as there's a need to build applications to deliver new capabilities, I don't necessarily see them scaling back..
If there is somebody who is not quite ready with SOA or has been experimenting with, I think a lot of it is tied to what is the overall reaction to the economy... ...some companies buckle down, and are trying to find a way to survive.... everything is on the chopping block... SOA is included with that, along with SaaS, or data warehousing, or whatever they are doing.... there are companies that also use these opportunities... to build out capabilities that will help them when the market does recovery.
A lot of these companies will take a very hard look at SOA and say... ...this is something ready to do when to be ready the market comes back...
Joe McKendrick: Chris Kraus, will the economy help or hurt SOA, what's your view?
Chris Kraus: I think it will help SOA because with all the mergers and acquisitions and folding of companies together, one the first things that happens, people who are well versed in business process management and traditional EAI tools understand the advantages of decoupled architecture in SOA. So it's the perfect chance to be a little more nimble and do things a little faster. So SOA should be their preferred way to handle all these mergers and acquisitions that are going across the organization...
Joe McKendrick: Phil Wainewright, what do you see for the year ahead with SOA and cloud computing?
Phil Wainewright: I think were going to see less spend on SOA, but there will be more done with it... I think it's going to be the death of big SOA projects. And much more tactical adoption... of SOA, and also ...tactical adoption of SaaS and cloud services... that's the bright horizon of SOA, and the great thing about external services... and the great thing about external services... in a down economy where spending is under constraint is that is that somebody else is funding the infrastructure... you don't have to... and therefore you've got a much lower cost... and a much lower risk if you start with an external service... I think to take advantage of that cost benefit... people are going to want to have an infrastructure... that can take advantage of these external services...
Chris Harding: I don't think you can generalize about all companies doing this or some companies doing that... I think the recession will hurt some companies, but some companies will survive through it or perhaps even grow through it... and that's when perhaps when we come out of it, we'll see a world that looks a little bit different... from what it looked like when we went into it... maybe one of the ways in which that change will come will be... ...the ability to use services between companies and SOA across companies... and not just within companies... ...over the longer term, that's the way things will develop...
Joe McKendrick: You heard it here first folks... SOA is a good growth strategy. and I'm in total agreement with what everybody here said.... All you have to do is look back to the recession 2001-2002... that's where SOA got its roots... SOA and Web services was seen as a way to streamline all those legacy systems that were ...built up before Y2K.... we still have 35,000 mainframes storing 80% of the world's data... that's not going away anytime soon.. The better companies leverage systems to get to that data and those applications, the better.
Dr. Chris Harding, The Open Group
Chris Kraus, ITKO LISA
Jignesh Shah, Software AG
Phil Wainewright, ebizQ, ZDNet
Joe McKendrick, ebizQ, ZDNet, moderator
It is probably an inevitability that as more and more organizations adopt SOA, many are falling into the trough of SOA disillusionment. They are finding their SOA solutions do not perform well, or are not secure, or services are not being reused, or they are being reused in unintentional ways. Defining who is responsible for paying for service maintenance when services become a shared resource is becoming a real issue for many organizations. This panel presentation will look at the issues many organizations are encountering on their SOA journey, and best practices for avoiding common pitfalls.
Joe McKendrick: Today were going to be talking about SOA quote-disillusionment-unquote,. and I put the term disillusionment in quotes, because it's a loaded term that's being thrown around these days by pundits and analysts. We have to take a look at what's going on out there. What may not be working so they can do to set things right. We're probably asking a lot of IT. IT is being called upon to sell the idea of transformation to the business as a whole. I've always felt this was a quite a tall order for IT departments who are already overworked and overloaded with keeping things running. Dan Woods at Forbes. made an interesting observation, that SOA shifting burden of application maintenance and upgrades away from packaged vendors to the IT departments themselves. Dan Woods is saying when you have applications abstracted into a service layer, there may not be a vendor to run to when there is a problem. I'd like to call out a couple of other analysts statements that have been made in recent months. Gartner, for one, said earlier this month that fewer companies planning or considering SOA, and this may be a result of the difficulties of proving return on investment. Also, we heard from Anne Thomas Manes, Burton Group, who has been involved in a deep study of SOA initiatives, who said that Burton Group had only identified one company demonstrated SOA success so far.
I'd like to throw it out to the panelists.. What's your take on all this, what do you see beneath these headlines. Are organizations really feeling a sense of disillusionment about SOA? Is it too early to tell? Are there actually a lot of success stories? Are they underneath the radar at this point?
Chris Harding: My perspective is that of supporting the work of people from the Open Group's member companies on SOA. I haven't yet heard anyone come up to me, or speak in the group and say well, I'm disillusioned with SOA. I haven't heard that at all.
What I have very definitely noticed is that there's no longer an interest in learning about SOA. People are no longer seeing SOA as 'a great new thing' that they have to find out about. They're still interested in working on how you use SOA, how you do SOA governance, how you integrate SOA into an architectural framework. They're still interested in looking at those things. But what's disappeared is the SOA is 'a mystical new thing' that we need to find out about.
Disillusionment isn't the word that I'd use to describe what I'm getting. Its more a case of, 'yes we know what it is now, we just need to get into doing the detail.' And I'm sure I can remember more than one presentation at Open Group conferences that has talked about SOA success. So I'm not seeing SOA disillusionment from where I'm sitting.
Joe McKendrick: Perhaps it has ridden the hype curve, to use Gartner's analogy. Now it's more the nuts-and-bolts implementation, the lets roll-up-our-sleeves-and-get-it-done phase.
Chris Harding: You're right. The hype phase is very important when a new concept come up. Its very natural. There should be a huge buzz of interest.. people what to find out about it. As you said, we're into the sleeves-rolled-up-lets-get-it-done phase...
Joe McKendrick: David Bressler, you're out there in the market working with a lot of customers... what kind of perceptions are you seeing.. you see any disillusionment?
David Bressler: I'll take the contrasting point of view. Whether its disillusionment or not its just a semantic thing, I think it's the kind of thing where vendors, of which I am one, go out and promise the world to people, saying SOA is going to solve all of your problems. Great, because I have a lot of problems, let's bring it in. They brought in some stuff, they to one extent or another implemented an SOA, or some sort of SOA architecture. Maybe they even modified some of the way they deliver IT to the organization. They combined technology with process. Yet, they still have the same problems they had before, and in some cases maybe even more of them. Because now, instead of having a packaged applications where they can now go beat up a vendor, they now have ten services and they have to beat up ten vendors.
I've got three things that kind of come top mind as I was listening to Chris talk, and some of the introduction comments you made. But I think there's going to be more of a focus as a result of the economy as a result of whatever, on solving very specific problems. I'm working with a few customers, its it's the same old thing. From my perspective, we tend to focus on the space formerly know as SOA management or service management. But the idea is you've got a bank full of management systems, and everything is green, and yet something is still not working -- dropped transactions, Web page that's slow, data is not showing up, or maybe its not accurate. Those kinds of things. So instead of saying, bring in a SOA and solve all my architecture woes, that's a big problem in several vertical markets...
There's also the concept that change is still too hard. Integration has become much much easier. But, change -- anytime you look at something and say, I need to combine that piece of data, that still becomes way too hard. It's the lifecycle of the application, as well as just getting the coding done...
And finally, simple things just take too long. Put yourself in the shoes of a businessperson, someone who really doesn't care about technology. And you say, I need to look at geo information alongside of shipping information. I want to look at it either geographically, or by product or by some other way that I've imagined in my head because I know the business. Most IT departments will take a deep sigh...
And you mentioned my work in the financial community... ..on a lot of trading floors they have a lot of IT people who site there with traders... and they do this stuff on the spot in real time... ...and get in down to get products to market quickly... but the investment .... Is way too high...
Joe McKendrick: That's the ultimate form agile development... if the IT folks are sitting right out there working with investment managers working on solutions in real time.
David Bressler: Absolutely.
Joe McKendrick: Dave raises an interesting point. This is something that what the business understands and supports... companies looking for solutions to problems... they're not looking to build an SOA per say.. SOA may underpin that solution... should the emphasis need to be on the solutions... does the business really need to ... understand or support the fact that this is SOA... or is SOA something that plays more of a behind the scenes role?
Phil Wainewright: I was just thinking while I was listening to Chris and Dave saying their piece. A big issue here is the whole IT-business alignment issue. If SOA is regarded as a big IT infrastructure project, then the businesspeople are cut off from it. And actually the other problem is that its being designed without a clear view of what the business objective at the end of the day is.
That's one of the reasons why you might get a certain amount of disillusionment, because your still actually focused on the technology and not the business results. Perhaps SOA can solve all of our problems, as they said. Okay, it does solve some of the old problems, but when there are a whole lot of new problems that come along, the focus needs to be on what the business actually needs. And SOA can provide a much more of intuitive approach to problem solving that does make it easier to deliver solutions.. ...
The example of adding geolocation capabilities. I saw a demonstration on Monday of a developer that is writing in a SaaS environment that is offering small businesses. A GIS visualization system that they are actually are offering for free to work with QuickBooks data using the intuit in the cloud platform, which runs on the QuickBase database.
And so that is a great example. I think there are SaaS or cloud examples of SOA infrastructure that has been built for the specific business objective of being able to deliver solutions cost effectively to small businesses with a lot of mashup capabilities, which now vendors and developers are coming in and offering very cost-effective solutions that use the mashup capability to bring in the different functionality that interact with the data and can then be adapted to business results, basically.
Joe McKendrick: Phil, this sounds like providing mashups that the businesspeople can work with... it sounds like something that makes SOA real to businesspeople... SOA they can see and touch...
Phil Wainewright: Well it is. I think the concept of SOA is not something that is alien to businesspeople... ....because at the end of the day business is all about delivering services to contract... ...and SOA is all about IT delivering services to contract.. so I think it's a very easy concept for... people to believe... I believe a lot of businesspeople think if only that's what I could get from IT... ..if only I could go into IT and know what I was getting... ...
Jignesh Shah: Maybe I can add a little bit to that conversation... one of things that I've seen working with customers that have been successful with SOA, and this is something I recommend to customers that I work with... ...is that when you're explaining, trying to sell SOA to the business side, don't bother calling it SOA. because its not to say SOA is not relevant... to the business side... but what's more relevant is delivering services to the business...
Seeing IT leadership has been successful in getting business on board with funding their SOA initiative is, when they talk about things like, 'we have to do this to support your business process management initiative,' building applications, we'll help you build and automate business processes faster, or 'we have to do this because we want to rationalize our applications, we want to go from six applications that they're using today to quote prices, and bring it down to a set of common services that can be used uniformly across the organization.' Or 'we want to use this approach to building IT capabilities to help you outsource capabilities.'
That is what is quite effective in helping the business to understand the value of SOA. This is not to say SOA vision is not even necessary. It's not to say you should not have a vision,.strategy or a plan to go from A to B. But the way you sell it to the business should remain in terms that are relevant to the business..
Joe McKendrick: I've heard it said that the best SOA business proposal would not even mention the phrase SOA. It will talk about the problem and the solution, SOA practices and methodologies.will be there to make it happen, but it's not necessary to sell that aspect to the business.
Jignesh Shah: I would absolutely agree with that recommendation.
Chris Harding: This builds upon the point that Phil was making about the need to link into the business result. Because SOA in itself does not address any particular business need. What it does do is structure the IT in a way to make it a lot easier and quicker to address particular business needs when they come up...
In order for it to do that, you do need to take an overall architectural view... ...of how its going to be used within the enterprises... ...there are two traps that we see... people talking about... that you could fall into that might make an organization disillusioned with SOA... one of them is that you do SOA as a small pilot project, you don't think about how it fits into the architecture of the business as a whole... and then you find that you cant do anything beyond that first pilot project....
The second trap you can fall into is the opposite one... that you spend too much time on doing an overall super master plan... before you do any detailed work, and that can lead you to waste time too. ...master plan... ...so you do need to do pilot projects.. but you need to do them within a framework of.. ...an overall view of what the SOA has to achieve...
Joe McKendrick: Do you see too many SOA projects and initiatives... being designed without the long term in mind? perhaps building services and throwing them out there... without consideration of how it's going to play with the rest of the architecture... is that still a common problem?
Chris Harding: When you look at the analysts surveys... ...that show a decrease in the take-up of SOA.. that's because the initial take-up that they measure it against are really pilot projects... ...I think a lot of enterprises did experiment with SOA in a small way to start, and quite rightly so... ...but you do need to take an architectural approach... to the enterprise to move beyond that to a larger scale SOA in which you can deploy the infrastructure that you need to be successful and.. deliver business results. ...
Chris Kraus: The one thing that we're seeing when we're working with customers, you just said the pilot project versus a master plan architectural approach, we're finding that our customers who are most successful with SOA actually did some architecture, and decided they're going to have a consistent view of a customer object or an order object and actually redesign the interface to make sure it was reusable by multiple people. So the pilot wasn't to create a Web service to serve ourselves. It has to be something that is on purposely consumable by multiple people..
The people that we see are failing with SOA are the ones that say 'oh SOA is just Web services; I've got one big object, so all my Web services have one interface.' .. I'm just going to gin a WSDL in front of them. And they're not actually thinking from an architecture perspective. My goal should be, is this reusable by multiple people, because that's where the business side comes in. Everyone can has a single view of the customer, from an IT perspective, coding and testing in those timeframes...
Joe McKendrick: Chris Kraus, that's a great observation... one of the criticisms I've heard over the last couple of years about the whole reuse concept.. is when services are created... they're not created for reuse... created for the task at hand by the business unit originating the service... they're not thinking ... ..well a year from now purchasing may want to use this service.... So well to make sure that's ready for that as well... how do we address that long term?
Chris Kraus Quite honestly, it would be nice if we could say the service is going to be reusable next week. A lot of times if you think about mergers and acquisitions, and folding of companies and industries together, obviously, we're going to represent our customers differently, so we have to come up with some kind of common lingua franca on how we serve our customers. We're actually seeing people writing a service that's so specialized, they can even use it horizontally within their own organization...
We've delved down all the canonical models... and all the data modeling in the past... and we've tried to implement those things within our enterprise integrations... need to kind of look at where we fell short... in those areas... to say, when we represent a customer... do we need to represent every possible attribute about them? or ..do we split them up into smaller components... so that people have smaller things to consume, and they can reuse those easier...
If you think you're doing to get into the one uber... customer object that has every attribute about them... of course its going to be missing the one thing that people need... so if you keep them into smaller logical areas.. ...makes the smaller components easier to digest by the consumer...
David Bressler: I think that's all great from a strategic perspective. I think it's really important, and I agree with you. The challenge becomes as you start to deploy that within an organization is, how do you do that if you have a projects -oriented IT organization? They count hours for what they are doing. They bill it back to some part of the organization. The people are motivated and promoted and judged based on well they deliver projects, and not necessarily how well they solved problems for future projects somebody else is doing.
I think it runs into a lot more systemic problems with IT, even going back to what Jignesh said, is who cares whether its SOA or not. What the proposal needs to contain is how do we solve some of these fundamental problems? From our perspective as technologists, SOA is an awesome tool for solving these problems. But we're still just going back to solving problems, and not achieving SOA so to speak.
Phil Wainewright: The other thing here is you need to move away from the old waterfall approach to development, because I think that less appropriate in an SOA environment. Pushing services out there is a learning experience. You need to push them out into the infrastructure and see if people are going to use them, and maybe you need to fine tune those services before you get the right granularity and the right set of features. Certainly what you're seeing in the SaaS environment is that SaaS providers have to iterate through several versions of their APIs before they get their integration story right going into the enterprise marketplace. I think being ready for change is part of the mindset adjustment to SOA.
David Bressler: One thing that pops into my head as you talk about that, having multiple APIs.available and figuring out iteratively, whether it's a SaaS provider, or whether its an internal provider providing services inside the organization as if they were a service provider. I forget which SaaS provider it was, but I think the cost of their support calls for API-type SaaS kind of stuff is significantly, something like 4 to 10 times more expensive than a support call for somebody using their UI. So if we translate that over to an organization, if I deploy an off-the-shelf piece of software to a constituency of users. Or I say to my users, here are services, go build your own application, my support costs for that infrastructure are going to vary dramatically, and I need to allow for that in my organization, I need to allow for that in my budgeting. These are not necessarily trivial problems to resolve. Again, they're not necessarily technology problems...
We got some good technology, we've got some good ideas, and we've got perhaps the wrong kind of environment to apply those in many situations, and that might be the frustration, or the disillusionment we see.
Jignesh Shah: .Highlighting the other difference between the folks who are succeeding with SOA, and the ones that are perhaps somewhat struggling. The first thing said, as Chris and Chris identified was, you have to have an overarching focus on the architecture, how do you get the reuse, maximize reuse, is the organizational and the process issues that a lot of people that are struggling with SOA are probably missing out on...
If you continue to focus on the technology aspect.. and not the organizational aspect... this disillusionment or worse is almost inevitable... ....what I mean by this is one of the emerging best practices that we actually talk about in the book... SOA adoption for dummies... is the need for a competency center... ...the role of a competency center can be to provide architectural vision and organizational guidelines... make sure that people are building the right services... at the right granularity and it can be to deliver those reusable services...
Having a competency center has to be a recognition that... a different level of organization and a different level of processes are needed... to support SOA and to support reuse...
Chris Harding: Certainly a competency center.. is something that will help to achieve things on the technical front.. it will help to spread technical competence to achieve the definition that you deliver services that satisfy that concept if that service is to be reused. Also there is the question, perhaps SOA needs a cultural change within the organization.. and that's something that is very difficult to achieve... and perhaps more time is needed to achieve that change... than to simply put in a new technical infrastructure.
So the people talk a lot about SOA governance... and governance being important to the successful deployment of SOA... in my mind, that governance has to start with getting the culture right. That is perhaps what is taking the time and effort now...
Joe McKendrick: A couple of questions I want to throw out to the panelists.... Two related questions... First, how do you know when your SOA is succeeding... is there a way to measure that? and the other is how do you know when your SOA is not succeeding? With ERP and crm and these large systems, their failures have been legend.. in some case well publicized... you know when you need to tear up the system and roll back to what you had before... but how do you know when your SOA isn't delivering? You may have services that are being put out there and not being reused and adopted? How does a company know things aren't going as planned?
Chris Kraus: One interesting antidote I had from one of my customers. Is they felt they were succeeding in SOA when they change a service and multiple systems broke... because that proved that people were leveraging the services... the way they felt ...the way they were going to mature SOA... ..they can change the service, and all the consumers still work.... So they had the horizontal trust within the organization.... The governance and so forth... to make it work for multiple consumers at once..... so it was an Interesting idea... they're following the life cycle... ...they actually got usage... made a change and multiple things failed... ...how do we manage these things...
Jignesh Shah: Some of the other KPIs that I have seen, and actually have been published by our customers through press releases, what not... are things like what is the improvement in time to delivery. Or if these external-facing services, what is the difference in time to market... for new capabilities for customers and partners... Those are also quite relevant in terms of proving the value of SOA... to the folks in the business side.. is to say, definitely you have ... KPIs in terms of the use we are getting... and the cost benefit were getting our of reuse,... is there is a way to measure? There is a way to measure the cost to your business... in help to adapt to making these business changes faster...
Joe McKendrick: It is sometimes difficult to measure the impact KPIs? Difficult to measure impact SOA is having versus other initiatives.... A well-run company that is forward looking...and has good management is likely to be taking a variety of strategies... SOA being one of them... moving to the cloud, data warehousing initiatives... .... business intelligence.... its like an orchestra... and every class of instruments its part to this ...beautiful music... and SOA is one of those... how do you weed that that out and determine what role SOA is playing?
Jignesh Shah: In a lot of these cases... as the investment is made around specific initiatives... or around specific projects... it is fairly straightforward to identify... the impact of using an SOA approach, to integration, for example.. what is the impact of using an SOA approach to integration as an example... what is the track record when we were using a more classic EAI style? Or what is the improvement we delivered in terms of automating business processes and bringing down cycle times?
So generally as you're applying... these things to a specific business problem... yes there may be additional elements that may be able to contribute to it, but if you have sufficient focus you should be able to isolate... this is the advantage we get in terms of being able to change things faster.... Or being able to create new things faster... Most IT departments have a history in terms of how long it takes in doing these things... so you also have a benchmark that you can compare against...
Joe McKendrick: Another challenge with SOA is the expectations that arise around SOA. In fact, in some cases, SOA may become a victim of its own success, in that a lot of business units start subscribing to a service, but the provider of the service may not have the capabilities or capacity to keep things up and running on a 24x7 basis. Or they may be making unexpected changes to a service. They may have a situation where services are constrained by their owners. The services may be unavailable when they are needed by consumers, and so forth. Panelists, are you seeing this as an issue as well? I guess trust comes into play here, the ability to maintain or rely on services from other parts of the organization, or perhaps outside the organization. Is this an issue?
Chris Kraus: We're definitely seeing the need for agile development and moving from spiral development.... Which we mentioned earlier.. teams are building ...systems in parallel... they may not have access to what the other team is doing... ... or the service may not be available yet because they're behind schedule... or it could be there are constraints on the system.. maybe they only have access to a mainframe... that's only available for only a few hours a day...
A lot people think of virtualization in terms of hardware... ..we think it in terms of the behavior of the service... if I give you something that looks like the Web service and acts like the Web service....but actually a virtual version of it... People can code against it initially... ...or you can load and test against it... people are asking for this...
Software as a service... will play into this... ...but when it's team to team working together.. maybe because there's lot dependencies or constraints...there... so having behavioral.. virtualization of a service for people to code against... do ...load testing...against... ...or having people able to send a purchase order... so they wont get rejected because they don't have good data, things like that.... those are becoming important...
Chris Harding: In the days when SOA was bright shining new... there were a lot of promises made about it, a lot of things said ... ..things haven't come completely true or have become difficult to achieve... ...than you would have expected initially. That always happens when you have a new technology... or a new way of doing things is brought in... SOA is a paradigm shift... it will take time for the industry to digest it, if you like. And it wont be a case of all the promises being met. It will be case of people being sufficiently happy.... With what they can achieve with SOA that they carry on using it.. and build on it to go in ..further directions like integrating it with the cloud... ....my feeling is that yes, that is the way that it's looking... but it's probably too early to tell... for sure...
Joe McKendrick: I want to go around to our panelists on what you see in the year ahead... ...in particular the economic conditions... were seeing these days. will a tightening or tumultuous economy that unfortunately may continue on through 2009.. do you see that as changing the way that organizations look at SOA? will organizations look to SOA-based methodologies to help streamline operations and cut costs and so forth... or do you see perhaps cutbacks in SOA programs? Organizations may need to trim back their SOA efforts... let's start with our Wall Street guy... David Bressler... how do you see SOA playing in a very rocky economy?
David Bressler: I think were going to start to see vendors focus less on pitching SOA.. and more on pitching solutions... from the vendor perspective, I think we'll hear a little bit less about it... I think the Technology is in some sense maturing... to the point where it can do that. Obviously people are going to make cutbacks... ...I think they're going to make cutbacks where they cant measure a clear benefit or a clear improvement... over the way they're doing things now... I of course believe SOA technology can help them measure that improvement, but that's a different question...
Joe McKendrick: Jignesh Shah, do you see SOA coming under the budget knife?
Jignesh Shah: It will differ based on two things. One is, where is the company today with their SOA, and b) what kind of company is it in terms of its response to bad economic conditions in general. Let me clarify that. If a company has already embarked on a SOA... and has been doing that for some time, I don't necessarily see them scaling things back, because for them this is the way they now build applications. As long as there's a need to build applications to deliver new capabilities, I don't necessarily see them scaling back..
If there is somebody who is not quite ready with SOA or has been experimenting with, I think a lot of it is tied to what is the overall reaction to the economy... ...some companies buckle down, and are trying to find a way to survive.... everything is on the chopping block... SOA is included with that, along with SaaS, or data warehousing, or whatever they are doing.... there are companies that also use these opportunities... to build out capabilities that will help them when the market does recovery.
A lot of these companies will take a very hard look at SOA and say... ...this is something ready to do when to be ready the market comes back...
Joe McKendrick: Chris Kraus, will the economy help or hurt SOA, what's your view?
Chris Kraus: I think it will help SOA because with all the mergers and acquisitions and folding of companies together, one the first things that happens, people who are well versed in business process management and traditional EAI tools understand the advantages of decoupled architecture in SOA. So it's the perfect chance to be a little more nimble and do things a little faster. So SOA should be their preferred way to handle all these mergers and acquisitions that are going across the organization...
Joe McKendrick: Phil Wainewright, what do you see for the year ahead with SOA and cloud computing?
Phil Wainewright: I think were going to see less spend on SOA, but there will be more done with it... I think it's going to be the death of big SOA projects. And much more tactical adoption... of SOA, and also ...tactical adoption of SaaS and cloud services... that's the bright horizon of SOA, and the great thing about external services... and the great thing about external services... in a down economy where spending is under constraint is that is that somebody else is funding the infrastructure... you don't have to... and therefore you've got a much lower cost... and a much lower risk if you start with an external service... I think to take advantage of that cost benefit... people are going to want to have an infrastructure... that can take advantage of these external services...
Chris Harding: I don't think you can generalize about all companies doing this or some companies doing that... I think the recession will hurt some companies, but some companies will survive through it or perhaps even grow through it... and that's when perhaps when we come out of it, we'll see a world that looks a little bit different... from what it looked like when we went into it... maybe one of the ways in which that change will come will be... ...the ability to use services between companies and SOA across companies... and not just within companies... ...over the longer term, that's the way things will develop...
Joe McKendrick: You heard it here first folks... SOA is a good growth strategy. and I'm in total agreement with what everybody here said.... All you have to do is look back to the recession 2001-2002... that's where SOA got its roots... SOA and Web services was seen as a way to streamline all those legacy systems that were ...built up before Y2K.... we still have 35,000 mainframes storing 80% of the world's data... that's not going away anytime soon.. The better companies leverage systems to get to that data and those applications, the better.
Leave a comment