Over the last few months, members of the SOA Consortium’s Community of Practice have been discussing concerns, practices, tips and gaps related to creating and maintaining a vibrant service portfolio. Discussion topics have included service investment, definition, reuse, rationalization, payback, governance, marketing, operations and asset management.
In recent weeks, these discussions have converged on the concepts of “management units” and “portfolio management”. From our working notes:
“Taking a service-oriented approach fundamentally changes IT’s basic management unit from an application, to services, or a bundle of services that represent a business capability (component, segment, flow or function), and can be applied to many applications, business processes and/or domains.
This unit shift ultimately forces changes to funding, project management and asset management practices. Most notably, organizations will need to be deliberate in the realm of product portfolio management, understanding the business capabilities offered in the portfolio, how those capabilities are instantiated via software and information assets, and how/where those capabilities are packaged into products (applications, processes) that solve a business need.”
This week, I distilled our on-going conversation into the diagram below. [Click on diagram to enlarge]
As you can see, and probably expect, the diagram spans business architecture, IT planning, IT delivery, IT operations, and service portfolio management concerns.
The arrowed lines show the connections between concerns. For example “Business solutions provide business capabilities” and “Business solutions consume services”.
The purpose of this post is two-fold. First, we want to share our in-flight work, particularly the diagram, in case it can be helpful as you enter into service management discusses across your organization.
Second, we have some questions that we’d love the broader community’s feedback on.
1. Has your organization’s management perspective shifted away from business solutions (applications, business process implementations) to business capabilities/functions? If so, in which areas: IT funding, IT delivery, IT operations, and/or IT product management?
2. Are you engaging in service portfolio management practices, such as service value prediction and assessment, marketing, sourcing, rationalization, refresh, and retirement? If so, what techniques and/or tools are you employing?
For example, to manage service sprawl that began from federated service development and was compounded by a merger, one of our members is considering marketplace techniques, both real and predictive, to let developers choose which of a redundant set of services survives, rendering the less popular obsolete.
3. Who manages the service portfolio? How does this compare, contrast with the management of the business solution and IT asset portfolios?
Given the convergence of SOA and Cloud Computing, I did a quick extension to include consuming cloud services. The extensions are in yellow. [Click on diagram to enlarge]
Obviously, an externally sourced cloud service is not an IT asset. However, since the cloud service does instantiate business capability, it is a member of your service portfolio. The question becomes which service portfolio management practices and policies apply to an externally sourced (and controlled) cloud service? I’ll be thinking that one over myself, and would love to hear your thoughts.
Please share any thoughts on the post, and/or our direct questions, via comment, blog post, or discussion forum. Just link to this post, we’ll find you.




Brenda -
This is exactly the kind of issue that we've been solving lately. Once SOA-based implementation goes live, the management paradigm - including such thorny points as annual planning and budgeting - must change to account for what CAN be assembled out of all the bricks and patterns that have been delivered. That leads to continuous reprioritization of planned/in-flight bricks and patterns to constantly adjust to external pressures. This challenge applies to other technology approaches, provided they are model based (MDM, BPM, EDA, BI, and UX, just to add a few more acronyms to the post).
So the fundamental idea of a management unit must change from service or process or system to a capability. If IT is a business unit, then just as any other business unit, the full value is not captured in services that IT provides, but rather in capabilities that this unit enables in profit centers - no different from other enabling units like Finance and Human Resources, to name a couple.
This approach resolves the question of cloud-sourced services - whether "true" cloud (external) or internal cloud. The trick is to sufficiently describe all of these services in a way that allows for easy assembly of services into capabilities, and capabilities into capability portfolios. Call it a semantic service bus for organizational interactions. A lot of very interesting work in this area has been done in DoD utilizing RDF/OWL to create these descriptions. While that resolves the management aspect, the actual discovery and translation of processes, services, and organizational structures is still an art.
Regards,
Aleks
Posted by: Aleks Buterman | July 24, 2009 at 07:44 PM