Let’s talk about IT service management (ITSM)‘s service portfolio and DevOps. I’ve often heard of IT work being described as a “factory” or a “conveyor belt.” I’m not particularly fond of these metaphors, because I think it devalues the skills and expertise of the individuals doing the work. On the other hand, these metaphors illustrate the need for flow, and the removal of friction and waste within IT when dealing with technology demand from within a business. This has to be a good thing.
But IT is (or has to be) more than just the taking of a business order at one end and the spitting out of new code or products at the other end. IT needs direction.
But where does this direction come from? And how does work get on the IT “conveyor belt”?
Possible Options for Direction and Work Selection
It’s not the backlog – the backlog just represents open requests or requirements for current development activities.
It’s not the project list – the project list represents the status of authorized initiatives.
Is it the product owner? While the product owner may be knowledgeable about business needs and providing the “definition of done” for a specific initiative, I don’t see how a product owner can possibly be all-knowing about emerging and current technology needs across an entire organization.
Is it the customer – the *real* customer – that pays money for the goods and services provided by the organization? While the customer certainly has influence, it isn’t just the customer. If that were the case, GE would still be making refrigerators.
Ultimately, how are decisions made for investments in IT? How can the organization determine the value of its investments in technology? How does the organization know when a particular IT service has met the end of its useful life? And how can the organization identify such services?
There is a way – it’s time for me to introduce the service portfolio…
The (Usually Ignored) Service Portfolio
Something needs to tie IT actions to business strategy. Something needs to enable value discussions and establish a shared understanding of what value is. That “something” is a service portfolio.
ITIL defines a service portfolio as a database or structured document that describes the complete set of services managed by a service provider (often meaning IT). The service portfolio represents investments, contractual commitments, new service development, and service improvement plans. It may even include third-party services as well.
Some people mistake an applications portfolio or a project portfolio for a service portfolio. But an applications portfolio simply represents the inventory of applications. And a project portfolio represents various defined, time-boxed demands for the temporary use of IT resources to achieve some objective. Plus, projects are only in the project portfolio while the project is active; when the project ends, the project is removed from the project portfolio.
Neither the project portfolio or the applications portfolio provides the comprehensive view of the investments, ongoing costs, services, and capabilities of an IT organization. Whereas a service portfolio, defined in business language, presents that comprehensive view of IT, and provides a basis for informed decision-making.
DevOps Addresses Some Significant Business Problems
Effective DevOps solves some significant problems faced by organizations in their use of technology, in particular it:
- Allows the organization to respond in a timely manner to changes or learnings during development activities, resulting in an organization being more responsive to business needs.
- Breaks work into smaller, more manageable chunks, resulting in faster times to value realization.
- Done well, it brings all parts of the service provider organization (development, operations, security, and quality) into the development and deployment of value from the beginning, resulting in better quality products. Issues can be detected and corrected early in the development cycle. And operational needs can be accommodated from the beginning, and later as part of implementation.
DevOps deals with the tactics – the “how” things get done.
However, in my opinion, these solutions cannot be realized without having a strategy for the use of technology.
A Service Portfolio addresses a significant DevOps problem
A service portfolio solves a significant DevOps problem – because it helps both the service provider and the business it serves to understand and agree on the “why.” In particular, a service portfolio:
- Is a mechanism to align service capabilities with business operations, customer interactions, and business strategy.
- Helps the organization understand the value and cost of IT services. DevOps typically deals only with a portion of the overall technology value stream – developing and implementing new or changed solutions. The service portfolio not only encompasses that aspect of the technology value stream, but also the ongoing costs for maintaining the total value stream – the delivery of a service from point of origin to point of consumption – for all services.
- Helps the organization make informed decisions about technology investments. Can current services be changed or repurposed to accommodate emerging business needs? What services can be decommissioned as a result of implementing new services or functionality? The service portfolio helps answer these questions.
- Provides a basis for needed governance of technology resources. Any investment or use of technology must be done in compliance with company values, visions, goals, and standards. Just because something can be done doesn’t mean it should be done.
Defining your Service Portfolio
I often describe defining a service portfolio as like eating an elephant – you can’t eat an elephant in a single bite.
And organizations can’t just stop everything that they’re doing from the technology perspective to define their service portfolio. But what all organizations must do is make informed decisions about investments and commitment of resources in technology.
So here are my suggestions for defining your service portfolio:
- First, define the service catalog. I like to start here because organizations generally know what they are delivering now. Keep in mind that the service catalog is not a listing of everything that IT does, but describes how IT delivers outcomes and value to the business.
- Identify business value streams, then map how technology contributes to those value streams. This exercise will do two things – first, it confirms what you’ve identified in (or have omitted from) your service catalog. Second, it identifies technology and infrastructure that does not contribute to business value streams – it’s potential technical debt.
- Identify technical debt. Most organizations have some technical debt – some organizations have a lot of technical debt. Technical debt is a drag on the organization, resulting in unnecessary costs. This technology and infrastructure that does not contribute to business value should be placed in the service portfolio as “retired services.” Keep in mind that this does not necessarily mean that the technology is not in use (poor change management practices may have resulted in infrastructure that was not properly retired!). But it does mean that business could potentially stop investing in these services.
- Review this year’s business goals and objectives. These initiatives are the initial entries for the service pipeline, and can then be evaluated against the service catalog and retired services. Ask: What is the potential demand for technology? How does that demand align with current services (the service catalog)? How is technical debt impacted?
- Define the process for how the service portfolio will be maintained. Done regularly, the service portfolio is key to providing the direction needed by IT.
A service portfolio enhances DevOps by providing the reasons “why” for the “how.” Exploiting technology for business success is neither inexpensive or easy. But the direction enabled by a good service portfolio, combined with the speed of good DevOps, will result in the velocity that the business demands.
Doug Tedder
Doug Tedder is the principal of Tedder Consulting LLC, and is an accomplished and recognized leader who is equally adept in interactions from senior leadership to day-to-day practitioners.
Doug holds numerous industry certifications in disciplines ranging from ITIL, COBIT, Lean IT, DevOps, and Organizational Change Management. An active volunteer within the IT Service Management community, Doug is a frequent speaker and contributor at local industry user group meetings, webinars, and national conventions. Doug is also a member, former president, and current board member for itSMF USA as well a member of HDI.
