Great video, and I really appreciated hearing the concerns around losing focus on the service aspect. I echo those concerns, and while I appreciate and agree with the desire to have a blended approach, my concern is that if taken too literally in refactoring CSDM this could ultimately lead to a loss of focus on service outcomes. Thanks for delivering a balanced approach in this, including both Product and Service, and both ITIL and IT4IT.
@ CMDB Whisperer If you're referring to Digital Products when you say taking the focus off the services, I have a different perspective. I think digital products will be more of a focus during the early part of the lifecycle, and services will still mostly be what gets delivered. I see many issues with the development and configuration in the early stages of digital services today. There needs to be a better set of standard development practices that developers can use to deliver services. The main issue is how services are delivered keeps getting reinvented, and there is a pile of technical debt in that early part of the lifecycle with tools and processes. Digital Products help solve this problem.
With Digital Products, the focus becomes delivering digital outcomes agilely. The big changes are moving from project management to product management and focusing on the outcomes, which are services for most industries and products for others. Besides process shifts, Digital Products also suggest organizational shifts that align people to products, essentially sets of digital outcomes. Done correctly, Digital Products should remove barriers to producing good modern services. Google, Amazon, ServiceNow, and Microsoft all sell products that can be used to deliver services and have perfected that delivery chain. Digital Products are about doing more of what they do and removing the old structures that focus on traditional project delivery.
I used to be a product manager, and my focus would be 10 to 20% on what was being built and 80 to 90% on what we would do to improve on what was being built. That's another big part of the shift. My focus was on how we would build, buy, or partner with other companies to acquire technology to improve the digital outcomes for my customers. Lastly, I had to put end-of-life to things in my portfolio that devalued my product or products when I had a portfolio of products. When we talk about Digital Products, that's the way I look at it. Digital Product teams should deliver better digital services faster and reduce costs.
Not sure where "project" comes into play here but my focus is on the differences between Services and Products and how that comes into play in the CSDM in particular. Since it is not published yet, we can only guess at what it will look like in reality, but the way it is described, it seems as if Services are actually being discarded in favor of Products, and that we are not going to make a distinction between Applications and Services, and we're going to combine them into a single class. The fact is that the current CSDM and traditional Service Management work very well when you focus the Services on the actual outcomes you are delivering, and then you focus the Business Applications and Application Services on the Software Products you are using to deliver those services. In my view there is no need to conflate the Applications, Products, and Services in order to achieve a Product-centric approach if that's what you are after. We should not sacrifice a Service-centric approach in favor of a Product-centric approach at the data modeling level. I can see the value in supporting different models depending on your approach, but fundamentally refactoring the Services to be Products seems unnecessarily limiting. They represent different things. A service describes the value being delivered. An application represents the computer programs used for the purpose of delivering those services. A product (digital or otherwise) represents the output of some process (development, manufacturing, service delivery, etc.). Obviously they all work together, so bringing them together from a management and visibility perspective is definitely beneficial, as the DPM product is starting to do. But refactoring them so one thing replaces the other -- i.e. services become products -- seems to inherently subtract the benefits of describing and managing services as services. I come from a background in both service management and software product development, and to me they are different things. They should be brought together and managed together, but one cannot replace the other. It's clear to me in watching this video that there are two different perspectives on this -- one is coming from people with more of a product focus and one is coming from people with more of a service management focus. This just underscores my concern: replacing one mode of operating with another mode of operating isn't the solution. We need to enable both. I'm hoping this conversation will continue to include multiple perspectives and that the platform and the CSDM in particular will continue to enable a truly service-centric model.
IT4IT has come a long way, I would not look at it as a "replacement" for service management, it's simply a more holistic lens. Even looking at ITIL 4 today, it simply does not really manage digital services as something that required product management and consistent evaluation against business terms and outcomes. Instead, it focused on defining the people and processes needed to manage services, at least in my opinion. Which is only a part of the whole when you look at CSDM, Digital product management injects a business orientation around WHY IT exists as the basis for turning the situation around.
@HY2 I heard it put this way, which makes sense to me. "IT4IT is an excellent framework for telling you what to do to manage digital products and portfolios, but It doesn't tell you how to do it". For example, it tells you where Architecture is needed, but you need a standard like TOGAF to tell you how to do the architecture.
I agree, I think it also unlocks the doors for distributed/adaptive governance models to exist where the architecture team(s) are given latitude to govern architecture according to their best-practices and standards and DevOp teams to theirs, etc. Becoming ever-so more agile and cross-functional, Matrixed teams working in "pod" like manner can do what's best for their offering in their function as opposed to a more traditional monolithic governance.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
