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 dont have a rigid structure around every single application. Because they can now interplay with so many different things.
Its almost as if SOA creates a Frankenstein or at least the possibility of a Frankenstein if its not managed.
|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 theyve used SOA to create 20 brand new services. To which Hedin responds: Once theyve 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 theyre 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 doesnt 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 its 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.
Youre creating a new role, or youre demanding more from the enterprise architect. In fact youre 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 youre 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 couldnt do before, Hedin says. "It's a whole new environment."