Centralization and SOA
This post, by Robert Swanwick, was brought to my attention by Brenda Michelson courtesy of her followup post. In the first post, Robert describes a situation of a company that has historically operated as autonomous business units, each doing what was best for their own customers, including each building their own web channel. As they tried to incorporate more customer contributions into those web channels, he states that “they sought to build a common platform.” He didn’t provide additional details on what common means, whether it was shared customer presence across all of the web channels, or if all of the web channels were consolidated into one. He goes on:
However, the autonomous business units lived on. Because they are quite independent, they are constantly seeking to diverge in order to meet the specific needs of their customers. At the same time IT continues to work towards increased centralization. As you can imagine, this is creating some tension.
A service oriented architecture (SOA) with shared web services and appropriate SOA governance might be their salvation. If IT can control the main architecture and help facilitate the sharing of approved web services, this firm may be able to get the centralization they need while allowing for business units to meet their own customer needs.
Personally, I think there is a risk that SOA could muddy the waters in this situation. I do agree that this is a governance problem, however, it’s not SOA governance, though, it’s IT governance. Based on the description provided, it doesn’t seem like there’s any immediate business desire to consolidate the channels to the customer or to stop viewing these units as autonomous. The second governance question is more about the goals of IT. Why is IT trying to centralize everything and strive for commonality? Are solutions not being delivered on time? Are IT costs running wild? If they are, and these costs can be tied back to the redundancies that exist across these autonomous units, then the governance board needs to determine which of these competing goals, business autonomy or IT cost reduction, is more important. If the stakeholders decide that IT cost reduction is more important, then there’s a high likelihood that SOA is going to help achieve that goal. If the stakeholders choose that business autonomy is more important, an effort to adopt an enterprise SOA is going to continue to be in conflict with that desire and may do more harm than good. Individual business units may want to run with SOA within their domains, and IT may be able to take it a bit further under the radar, but keep in mind that those efforts would not be in support of the stated business goals. In other words, even though there may be opportunities where SOA could be applied, if it puts the stated goals of the organization at risk, that’s a problem. I would encourage the leaders of this organization to first read Jeanne Ross’ excellent book, IT Governance: How Top Performers Manage IT Decision Rights for Superior Results
3 Responses to “Centralization and SOA”
Leave a Reply
I also think that discussions about the “IT Operating Model” as described by Weill, Ross and Robertson in their “Enterprise Architecture as Strategy” would have been helpful.
This would have let to questions like:
– to which degree do we need to standardize business processes?
– to which degree do we need to integrate business processes? (and thus share data)
At least it would have turned the decision into a business discussion, rather than just a question about consolidation.
“If the stakeholders choose that business autonomy is more important, an effort to adopt an enterprise SOA is going to continue to be in conflict with that desire and may do more harm than good.”
This assumes that SOA is about centralization/sharing vs. autonomy. SO principles are just a way to segment the solution space. Nothing about SO dictates sharing or centralization.
“A service oriented architecture (SOA) with shared web services and appropriate SOA governance might be their salvation.”
That focuses on the wrong thing, IMO (particularly the “shared web services” part). An architecture, regardless of style, must reflect the constraints being addressed. As Hansen points out in his comment, the business discussion will identify what can be shared (if anything), what will interact and what will be duplicated. SOA isn’t the salvation. A business-focused analysis will be the salvation–whether an SO approach is used or not.
Too many people want to position SOA as the salvation, IMO. There are some nice aspects of SOA but it isn’t all that important in the scheme of things. It alone won’t magically smooth out the disconnects between the various groups within a company.
I’m reminded of the various pay-for-performance (P4P) plans that tout how effective they’ve been at incenting the right behavior. “We reward the behavior we want.” When things improve, they point to the incentive plan as the reason.
But what they overlook is when a P4P plan is implemented, two things are communicated: 1) the incentive and; 2) the desired behavior. Before the P4P plan, item 2 wasn’t communicated well if at all. When 2 is finally communicated, it’s no wonder there is improvement.
Same goes for “SOA as savior.” If SOA is the impetus for the discussion/collaboration amongst groups, great. But let’s not forget that it is the collaboration that is important, not the framework in which the collaboration was structured.