Hit in the pocketbook, governance and budget priorities

Found some notes from earlier this summer from some blog reading...I can no longer find the original reference...so if anyone can help me track down the original so I can attribute....

However, while these notes were originally captured because of their relevance to service granularity; they also suggest the some of the responsibilities of the enterprise from a SOA governance perspective.

"Some who have started down the SOA route have soon found that coming up with popular services that expose data – previously hidden away behind obscure stored procedures and SQL requests – hits the wrong departments in the budget. Services often prove to be too popular – and the people who like them are not, necessarily, the ones who have to foot the bill for them."

Is this indicative of a service approach that is overly granular? If these services are really functions, then yes, this is a problem at the outset. However, services should really be aligned and defined by business/mission functions. Perhaps this burden of popularity is really good market research that indicates where there is a competitive competency that is waiting to burst out from the organization who pulls the data together.

First, to note that the organization suggested by this 'burden of popularity' might not be the office who owns the data. Rather it is the data steward or the office that puts enough together to create value with the data.

From another perspective, it sounds as though there is a missing element in this scenario in which there is no clear understanding or organization of capabilities within the organization. Perhaps the switch to services, which reduce the barriers to interacting with services through standard interfaces and detailed specifications, is only emphasizing what is broken in the organization. This seems to resonate with me. It isn't that the technology is broken. Rather it magnifies problems, or lack of awareness, that exists in the organization already.

If individual groups offer services to other parts of the organization, they have to get away from the idea of throwing services out and seeing what happens. Experts in this area all insist that SOA needs an architectural overview in the first place. And it needs to commit to service delivery and financing that genuinely looks at departments or groups as providers of actual services, rather than lumps of code that happen to have been tagged with the name ‘service’...You need to educate people about what it means to expose services and look at the commitment it needs. Commitments have cost implications. Where you see that happening it has a more positive effect on IT in how it is governed

I think the distinction come into even clearer focus if we talk about brick and mortar capabilities. You don't just throw out retail products to 'see how they'll do', you don't just 'start focusing on a market segment without a well thought out strategy for addressing the needs of that market segment and a understanding of how the core competencies of the organization provide values to those customers.