| QUESTION & ANSWER |
SOA worst practices, lots of Web services = trouble |
 |
By Rich Seeley, News Writer
12 Oct 2006 | SearchWebServices.com |
|
|
Dan Foody, CTO for Sonic Software and Actional products at Progress Software Corp., is seeing SOA failures based on what he considers SOA worst practices. Although he is a chief technology officer, he does not see the problem as technological. In his opinion, the problem is with the management of the projects, lack of understanding of the SOA approach and the inability of organizations to make the shifts needed to embrace the SOA philosophy.Read Part two
In terms of SOA, what are you seeing?
Dan Foody: Service-oriented architecture is on everyone's lips these days. Everyone in the enterprise knows and wants to be involved in service-oriented architectures. That, in and of itself, is creating challenges because not everyone really understands what it really means to do service-oriented architecture.
What kind of challenges are resulting from this SOA naiveté?
Foody: Some of the things we've found is that people say they're doing service-oriented architectures, but some of the things they're doing are amazingly scary and not at all in the sense of what service-oriented architecture was intended for.
Does an example come to mind?
Foody: Let me give you an example of one of my favorites. There's a company that gave a keynote at a conference and up in the keynote they told how successful they were with service-oriented architecture. They said they had 300 services and they were on track to go to have a thousand services within a year. Sounds pretty impressive, doesn't it? The only problem is that's kind of like a train wreck in the making.
Why will the train go off the track?
Foody: One of the things you're trying to do with service-oriented architecture is avoid complexity, not have 30 different services that more or less do the same thing. You're trying to get reuse. With a thousand services, the likelihood of any reuse is virtually zero. So while they might have a lot of Web services, the fact is they're not going to have a service-oriented architecture. They're not going to be able to show any real business benefit. That's an example of the mistakes people make when they go off track and think "the more I have the better I am."
Is this because people are still having a problem defining service-oriented architecture?
Foody: There's two aspects to that. There are people who clearly don't understand what it really means. Just having services doesn't mean you have a service-oriented architecture. It's not about the number of services you have. It's the number of ways you use the services you already have. That's really what defines service-oriented architecture in many ways. And that's a subtlety lost on a lot of people. It's not the services, it's the reuse of services that's really the value. The fact that you're sharing a resource across the organization is the value of service-oriented architectures.
But there's a lot of times when even if they understand that, they don't necessarily know how to go about successfully growing a service-oriented architecture. Some people think building proprietary standards will make an effective service-oriented architecture. So we've seen some organizations, for example, that take Web services and SOAP as the basis. Then they mangle it until it can't interoperate with anything else that's out there. They add their own special features to the standard. And now they need to custom code everything, so they've lost a lot of the interoperability benefits, which makes it very hard to get service-oriented architecture in the first place. Even in those cases you see people who are trying to do SOA and they understand the point they are trying to get to, but they don't understand the path to get there.
Do standards help clear the path?
Foody: Most people will say that technology really isn't the issue with SOA. The hardest challenges are the organizational ones. So a large focus around a technology architecture may help shore up 20 percent of the problem and solidify that 20 percent, but it really doesn't solidify the 80 percent of the people side.
That said. I think the people who make these worst practices kind of mistakes wouldn't be listening to a standards body in the first place. They believe they understand what they're doing, which is part of the problem. The person who went up on the keynote and talked about building a thousand services, he believes he knows better than anyone else how to do SOA. He wouldn't listen to anyone else about it.
So I don't think any amount of work from standards bodies is going to solve that particular problem. The most important benefit an organization can get out of SOA it not anything you could describe in pure technology terms. It's really making IT organize around something meaningful to the business. Aligning IT with the business and making it sustain that alignment over time. So when a business person talks about inventory, the IT guy understand what means, so they organize and operate around the things that matter to the business. That's the true benefit of SOA and there's nothing on an architecture diagram that will ever show you that.
The technology help is there if people need it today. And if they're willing to look for it, they can get it. But the people who fail from the technology perspective are the ones who think they know what they're doing and really haven't availed themselves of the help.
So is this a case of a little knowledge and a lack of understanding being a dangerous thing?
Foody: Yes. Confidence and lack of knowledge put together is a very bad combination.
Are we just going to have a lot of people fail with these worst case scenarios before organizations realize they've got to take a different approach?
Foody: Inherently we are going to see a number of projects fail. Anything that initiates change in organizations, there's a fallout factor. Not every organization will be able to make the change. Not every organization will know how to make the change. So I think it's inevitable that with any shift like this you will see fallout, you will see projects fail. And I think the key for most organizations is to recognize that and learn from the mistakes of those past failures, rather than assume that it's not going to happen to you.
So the key thing there really is to watch for and look at all the failures in the press. If someone is driving an SOA initiative, they shouldn't put their head in the sand when they see bad news in the press. They should actually embrace those and say this is another example of something I can learn from.
|
|
|
|
