Today I present the last part of my four-part piece on IT ecosystems. This last part deals with the human /organizational side of SOA - understanding corporate politics, building coalitions, gaining consensus, and providing governance and process to support your infrastructure.
4. In an ecosystem where every property has access to every process or service, where do you draw the lines about which system exposes which functionality? The nirvana of process decomposition can devolve into the ugly reality of political turf wars, with individual middle managers trying a land grab to "steal" each other's roles by incorporating functionality from one system into another.
Dave Watts:
The bigger issue I've run into isn't people trying to stake out other
people's stuff, but rather the opposite - people not being willing to
support what other people are using. If I build a system that depends on
services from three or four different organizational units, who gets blamed
when those services fail? (And they will.) There's a lot of paperwork that
goes into any serious SOA effort I've seen, involving who has to support
what, how they have to provide support, etc, etc.
Mark Kruger:
Looking around at blogs on topics like SOA and integration I think this point - interdepartmental cooperation - is missing from the discussion… "Banging heads" is rarely productive. Getting buy-in is a proactive process that requires salesmanship, collaboration, congeniality and integrity. Everyone has "spheres of influence" and a CTO may temporarily get what he or she wants by running rough shod over those carefully crafted power structures, but in winning the battle he or she will more firmly entrench such structures and quite possibly lose the war.
Rob Brooks-Bilson:
This is where governance comes in. There are lots of vendors out there now selling solutions to help you manage that governance, but at the end of the day, a well defined Enterprise Architecture with the backing of management is necessary (I believe) to be successful. Enterprise Architecture can be a wonderful tool for limiting the scope of turf wars. The governance layer helps you maintain the inventory (it's more than just UDDI for web services) of what's available, where, and who's responsible for it. You need to build a culture of reuse. It's difficult getting people to move away from the idea of "I need to get a list of customer numbers, so I'll just write my own query to get them from the db" to the idea of "let's create a single service for retrieving this information, exposing the process through the ESB".
When you say you want to influence people to do the right thing, that is certainly a valid approach, but it requires a heck of a lot of effort given the potential number of players in an organization. An alternate approach is to tackle this through an Enterprise Architecture initiative. You can involve key players from various groups, but the main person you need to influence here is the CIO/CTO. You get them on board with the concept of EA, get their backing, and the getting everyone else to fall in line - especially when one of the goals is to better align IT with the business - should be a whole lot easier.
A good SOA effort, like any enterprise-wide initiative, requires the active, ongoing cooperation of lots of people. Like never before, IT needs to work hard in a collaborative role, both inside the IT department and in the rest of the enterprise, in order to successfully execute an SOA strategy. “Banging heads is rarely productive”, as Mark noted (in response to a comment by me about the innate urge to do just that). As Rob B. notes, a governance layer can provide the mechanism by which disagreements are settled and rules finalized. Much like governance in a change management group can ease tensions among business users, application owners, and infrastructure staff by providing clear rules about the production release of changes in IT infrastructure, SOA governance can provide a clear set of rules and a neutral forum for resolving disputes among business users, application owners, and other stakeholders.
Finally, all of these questions pertain to just a small part of current IT ecosystems. IT evolution touches phone systems, network infrastructure, desktop computers, collaboration systems, hardware infrastructure, external systems from customers to vendors – virtually every piece of technology in the modern enterprise. Successful management of an IT ecosystem is an ongoing campaign to measure the effectiveness of current systems, look for opportunities for improvement, and guard against risk. Thanks to everyone who responded to my original questions and contributed to this discussion.
