Digital Products - replace or complement apps and services?

[Miklos Palfi]

Currently we are working on introducing the digital products concept into our data model. There are some very valuable contents out there on the topic including the recent Digital Services Forum meeting Digital Product Management & Foundational Data - Recorded April 11th 2024 

Our main question is the change from services and applications to digital products.

IT4IT v2.1, ITIL4 and TBM - in our opinion - all build heavily on the service portfolio and hierarchy. IT4IT v3.0 tries to make a step in the agile / DevOps direction (and comes with that closer to DevOps / SAFe world) by replacing the services and applications with products. (This was also well discussed in a previous Digital Services Forum session: 

IT Operating Models of Tomorrow - Presented on May 23 2022 

But how can we keep compatibility to the current models and frameworks? Shouldn't we keep the services and applications layer (not only the offers/service offerings) as a second view? What about putting the services and applications under the products as child-objects/tables? Actually we also sync many of our applications into the service table, because that's what customers (and the business users) know and name for the servicedesk.

So the question is replace or complement apps and services with digital products in the data model?

[Fred Jonkhart]

I like your top left PRODUCT MANAGEMENT area, which seems to underpin the 'digital product' abstraction.
What I do not like in CSDM is the 'unbalance' where shared / foundational / factory automation products are not represented in the product portfolio, but only in the MANAGE / OPERATE / BUY area. Any product should flow from product portfolio, to design/develop, to operations. With platform engineering gaining momentum, platforms can be strategic in my view and should follow a very similar value delivery flow as business applications, the difference is that the customers are internal. I think CSDM 5 tries to correct this unbalance.
We have put both Business Applications and Technical Applications in the Business Application table (e.g. DevOps tools are considered Technical Applications). We currently struggle to put all Technical Building Blocks somewhere (e.g. what to do with infra-as-code products? Are these Software Models?).

[Miklos Palfi]

We haven't found a really good model to represent infra-as-code yet. We already use Terraform for many applications (and their backend), but we do not consider that code as a separate item from the application itself. I would be definitely interested in best practices handling infra-as-code in the model! (Maybe worth for on other forum question/thread?)

[MrSmitty]

Thanks for the draft screenshot.  The amount of objects you have coming from LeanIX is a lot more than I ever considered for that tool!  

[Miklos Palfi]

That other tool is not necessarily a better or worse tool for so many objects. It is more a contractual situation which resulted in using that for so much more. First we evaluated APM, SPM and ins-pi. All of them were having many pros and a few cons in our IT4IT landscape.

[Barry Kant]

Good day Miklos, 

the thought process behind the Application Service name (change) is that is reflects a level that make be more than only applications. It represents a stack of an IT depending solution. Some of us consume the model to the letter and thing it is apps only. Another name might be confusing as well so it is key that people understand what it can be. (app, ATM, crane in a harbour, ...)

Similar for Digital Products. This can be goods as well as services. So the changes make it a bit more flexible. So a Service is a type of a Digital Product if you will. 

BR,
Barry