Without mapping the organisational context (business models, operating model, capability model) how would any of these abstractions be validated to actually work? Product terminology has only served to make organisations more confused and IT orgs second guessing their value proposition. This can make things more complicated and frustrating for the non IT stakeholders as they perceive IT practitioners on a different planet, chewing the cud on how these abstractions would fit their specific org. I think you need to start with enterprise patterns first - modern business designs that enterprises are wanting to adopt and let that lead this vocabulary using business architecture, service design etc. My suggestion is to drastically simplify the common data model and then use patterns and cases to demonstrate realisations and evolve from there. And the fact is that every business will have a different topology and have their native languages. I believe through doing the above, it will bring insight into even the foundations of the paradigm here. Thanks for sharing and loved the discussion. Look at Susanne Kaiser's work that brings together Team Topologies, DDD and Wardley Maps to guide dynamic evolution of solutions and the teams that deliver them while delivering FLOW - this will stretch some of the thinking. Full disclosure - I am an Enterprise Architect.
The suggestions are spot on, as I'm working on a Guidance document in The Open Group to address the Team Topology / Wardly models in how you staff and manage these Digital Product teams. We plan to have that guide in DRAFT form at the October Open Group meeting in Houston, and published by Q1 2024. The Open Group is where we are vetting our ideas, creating the standards and guidance out in front of incorporating them in our products.
