Thinking of Services as a "Center of Excellence and Expertise (CoE)"
In reading Beth Andres-Beck's blog post the other day, I was reminded the W3C notes the purpose of a service is to "provide some functionality on behalf of its owner -- a person or organization." This is a nice parallel to considering a service as a "center of expertise" for functionality it exposes.
In continuing the prior post in this series, when "Feature "X" (as shown in the diagram) is rationalized across Apps A, B, C the corresponding functionality is moved to a shared service. By way of example, if "Feature X" is currency conversion, there are a few implications of moving this to a service:
- Apps A, B, C will use the same logic and mechanism for performing currency conversion
- I.T. and Business stakeholders for Apps A, B, C will no longer need to be experts in Currency Conversion. Implies human expertise for this function could be realigned.
- I.T. and Business stakeholders for Apps A, B, C will need to be consulted if there are changes to the Service, particularly ones that are impacting.
- "Silos" are minimized or eliminated.
- I.T. and Business stakeholders must align on priorities. At times, the service owner might not be able to enhance the service for multiple applications and multiple stakeholders at the same time.
Step back and think about what a common, shared service really represents. A service represents "expertise"--both business expertise and I.T. expertise--provided for others to leverage.When a piece of functionality once replicated across the organization is moved to a shared service, ownership questions naturally abound. In a silo'd organization in particular "who should own shared services?" can become an ever present question.
One approach could be to move these shared services to a single support organization. This can be an issue due to sheer scale. It is not necessary or required to move all services to a single support organization (it is quite important for responsibilities of a service owner to be clear as this is critical to success).
If functionality is duplicated across the organization this implies human expertise is duplicated as well. When applications are reoriented to use a shared service to minimize duplication it is possible the organization should consider reorganizing in some manner. The purpose of this would be to maximize benefits of the service--business and I.T. experts supporting the service and the entire organization effectively.
It is not always practical to shift functionality to a shared service with no regard to the associated human expertise. In order to maximize benefits it is necessary to ensure I.T. and Business experts have ownership and provide necessary support.
Rather than ask "Who should own the Currency Conversion Service?", ask a slightly better question: "Where is the expertise for Currency Conversion?". From this hopefully ownership can be identified more effectively.
Why Focus On Expertise?
As a logical construct, a business service embodies the associated business and I.T. expertise. And exposes functionality to share across apps and business teams. A business service without its backing expertise does not maximize benefits.
Bottom Line: If the company's experts are organized "behind" the service, why use anything else (such as building your own duplicate functionality) to deliver a solution? If you find yourself in a debate over ownership or adoption, step back and see if there is a bigger picture.
Why Focus On Expertise?
As a logical construct, a business service embodies the associated business and I.T. expertise. And exposes functionality to share across apps and business teams. A business service without its backing expertise does not maximize benefits.
Bottom Line: If the company's experts are organized "behind" the service, why use anything else (such as building your own duplicate functionality) to deliver a solution? If you find yourself in a debate over ownership or adoption, step back and see if there is a bigger picture.
