SOA: A Frankenstein in the Enterprise?

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Over the last couple years, businesses have enthusiastically embraced Service Oriented Architecture (SOA). The Aberdeen Group reports that 90% of large enterprises have adopted or will move to adopt SOA by the end of 2006.

The attraction is obvious. SOA enables a remarkable degree of flexibility, and of integration of applications. This new enterprise architecture technology – almost like magic – allows IT departments to combine the services from many disparate software.

With SOA, data stored in outdated legacy apps can be meshed with data in current-day apps. The trend toward virtualization is pushed forward. Open source apps can be integrated with proprietary software as if Bill Gates and Linus Torvald were each other’s long lost twin.

SOA Articles

SOA in Plain Language

Web 2.0: The ‘Consumerization’ of The Enterprise

Swainson: Virtualization Everywhere in 5 Years

SOA and Vendor Buzz

Is it any wonder that SOA (promoted heavily by deep-pocketed vendors and legions of pricey consulting firms) has found a place in forward-looking enterprise architectures?

But amid the hoopla, SOA presents new challenges to enterprises – challenges that some companies may be ill-equipped to handle. As a technology that allows far greater flexibility, even creativity, it requires far more governance.

SOA is the exact opposite of a “set it and leave it” technology. Like a garden that constantly grows and changes, a SOA-enabled architecture needs carefully tending to prevent it from growing into a riot of unplanned consequences.

Clearly, “The architecture allows you to do a lot of integration of disparate systems,” says Marianne Hedin, an IDC analyst who’s written voluminously about SOA, and who sees great potential in this new technology.

Yet while SOA offers wonderful advantages, she tells Datamation, the danger is that “it becomes too wonderful and you’re creating chaos instead, and then you’ll have unhappy organizations that say ‘What is this thing? You’ve destroyed our whole entire procurement process and payment process.’”

Too Easy

Using SOA on an ongoing basis can be more complicated than some companies think it will be, Hedin says. “So vendors have to be careful when they introduce this to their customers.”

“One of the big issues is, if you make it so simple to create new applications through these combinations – I call it ‘plug and play’ – eventually it’s going to be so easy that even someone like you and I can do it. You don’t need to be a software developer.”

While this ease of use might conjure images of a complex network responding to the needs of any employee, it also suggests problems, ranging from mere inconvenience to true nightmare.

First, “Software developers now have to become much more cognizant, more than ever before, of what the business needs,” Hedin says. “Because they can’t just take any application and say, ‘Oh, I’m going to change this one. And I’m going to take this component from that application, and this component from that application, and I’m going to create a new one.’”

The resulting SOA-enabled application might be quite advanced, but it might also also be unneeded. Worse, it might create problems for the business. It may reveal sensitive data or route work orders in ways that are counterproductive.

As good as this new SOA-enabled app looks on the micro level, does it fit into the enterprise’s macro plan?

“In fact, there was a case – and I’m sure there were many cases like this – where the IT department said, ‘Oh, yippee, hurray, let’s put a new application in our department, in the IT department only. And let’s free up the software developers to create all this new nifty stuff.’

“And they did that. And lo and behold, they created complete chaos in the business. Because all of a sudden there were all these applications popping up that customers were using, that became accessible to customers and partners, and oh my goodness,” Hedin says, with a laugh.

Next page: Everything’s Interconnected

Everything’s Interconnected

The danger of SOA – which is also its greatest promise – is that it interconnects everything in the network architecture. This means any problem becomes a pebble in a pond, rippling out and affecting everything around it.

“So suddenly the business is affected by this, because there is this relationship or interdependency,” Hedin says. “Everything is loosely coupled now. Applications are not stand-alone hard-wired assets any longer.

“Well, when you get into that kind of environment of loosely coupled assets, there are a lot of interdependencies. Because you don’t have a rigid structure around every single application. Because they can now interplay with so many different things.”

It’s almost as if SOA creates a Frankenstein – or at least the possibility of a Frankenstein if it’s not managed.

SOA Articles

SOA in Plain Language

Web 2.0: The ‘Consumerization’ of The Enterprise

Swainson: Virtualization Everywhere in 5 Years

SOA and Vendor Buzz

A Urgent Call for Management

With SOA, “The whole issue around management and control can become huge,” Hedin says.

For instance, businesses have told her that they’ve used SOA to create 20 brand new services. To which Hedin responds: “Once they’ve created more than 20 services, they really need to put a governance structure in place.”

“Because otherwise, you have hundreds – or thousands – of services being created. How are you going to manage those services?”

Chaos can result if these services aren’t monitored. Who has access to these services? Who is allowed to create them? How do you write new versions of that same service? What happens when they’re updated? What are the rules and polices around upgrades?

“All these rules and policies need to be put in place very quickly so the whole thing doesn’t go out of kilter,” she says.

“In fact, some organizations, internally, have tried to do this on their own, and created such chaos that they have given up on it.”

Talk Among Yourselves (Please)

Business gurus are constantly harping on the need for greater communication between IT personnel and business personnel. These two distant camps need to break down the walls. But if that was true before SOA, in the age of SOA it’s absolutely imperative.

“All these integration capabilities are obviously shifting the way people are going to run their IT departments,” Hedin says. “IT departments now become much more business savvy. Software developers now have to work the business side of the organization to understand what they need.

“There have to be committees put in place, and cross-functional teams, of both business and IT folks.”

In short, “SOA really pushed the alignment of business and IT.”

To prevent SOA-related problems, organizations are advised to hire an ombudsman, a kind of inter-company middleman, an interpreter between business and IT. The enterprise architect could fill this role, as could some kind of business analyst.

“You’re creating a new role, or you’re demanding more from the enterprise architect. In fact you’re demanding that the enterprise architect has business experience.

“It [SOA] is creating more complexity for the IT department. Things are not so neat and clean any longer. Whenever you introduce the issue of integration, and the ability to integrate, things become a little messier.”

“The ‘con’ [of SOA] is really about being very much aware of what you’re in for,” Hedin says. “And knowing what the consequences can be unless you have a governance structure in place.”

But if SOA is managed properly, its potential is high. “You are buying yourself enormous opportunity to do a lot of things you couldn’t do before,” Hedin says. “It’s a whole new environment.”