Being product-centric is at the core of the agile discipline; It comes along with the notion of Minimum-Viable Product (MVP). To support MVPs, architects are struggling to provide corresponding MVAs: Minimum Viable Architectures. In the introduction to this series on agile, we have mentioned that MVPs are scoped around the mantra that smaller is better. It sounds compelling to apply the same principle to MVAs: Minimum Viable Architectures become small chunks of architectures that can address MVPs. MVAs are then refined through iteration cycles along with MVPs. Sounds great, right?
Antoine Lonjon, Chief Innovation Officer, MEGA International
MEGA was a Platinum Sponsor at the 2018 Enterprise Architecture Conference Europe.
View the event gallery here. This article was previously published here.
While often discussed, this approach falls short. An architecture is an architecture of something. The question is not about the size of an Minimum Viable Architectures but about its content which should at least include:
✓ A bit of the architecture of the problem regarding customer expectations.
✓ A bit of the architecture of proposed solutions regarding implemented features.
✓ A bit of the architecture of experienced solutions by customer
For instance, it might be useless to provide a robust solution architecture if the goal is only to test new features with customers through disposable prototypes. For architecture stakeholders to make such decisions, it is necessary to clarify how architecture relates to product and, more precisely, what we mean by from both the problem and solution perspectives. SAFe 4.5 itself doesn’t have a direct definition of product. SAFe states that product management is responsible for the program backlog which is described as holding upcoming features. Features are themselves described as a service that fulfills a stakeholder need. It sounds like we need a clarification of these related terms of products, services and features for which we will provide definitions and practical guidance in this series.
A starting point is to address the ambiguous relationship that sits between product and services. Both are indeed placed on equal footing as the saying goes “companies provide products and services”. This is clearly stated in the definitions provided by ISO-9000:2015.
Result of a process (3.4.1)
Note 1 to entry: Whether an output of the organization (3.2.1) is a product (3.7.6) or a service (3.7.7) depends on the preponderance of the characteristics (3.10.1) involved, e.g. a painting for sale in a gallery is a product whereas supply of a commissioned painting is a service, a hamburger bought in a retail store is a product whereas receiving an order and serving a hamburger ordered in a restaurant is part of a service.
output (3.7.5) of an organization (3.2.1) with at least one activity necessarily performed between the organization and the customer (3.2.4)
Note 1 to entry: The dominant elements of a service are generally intangible.
Note 2 to entry: Service often involves activities at the interface with the customer to establish customer requirements (3.6.4) as well as upon delivery of the service and can involve a continuing relationship such as banks, accountancies or public organizations, e.g. schools or hospitals.
output (3.7.5) of an organization (3.2.1) that can be produced without any transaction taking place between the organization and the customer (3.2.4)
Note 1 to entry: Production of a product is achieved without any transaction necessarily taking place between provider (3.2.5) and customer, but can often involve this service (3.7.7) element upon its delivery to the customer.
Note 2 to entry: The dominant element of a product is that it is generally tangible.
Note 3 to entry: Hardware is tangible and its amount is a countable characteristic (3.10.1) (e.g. tyres). Processed materialsare tangible and their amount is a continuous characteristic (e.g. fuel and soft drinks). Hardware and processed materials are often referred to as goods. Software consists of information (3.8.2) regardless of delivery medium (e.g. computer program, mobile phone app, instruction manual, dictionary content, musical composition copyright, driver’s license).
Note 3 in 3.7.6 provides a classification of products which ranges over hardware, processed-material and software. They are denoted as tangible elements, which we shall consider as artifacts, that is, man-made objects. Can we then say that services are produced the same way artifacts are produced? Shall services be themselves considered as outputs on equal footing as products considered as artifacts (tangible elements)?
Digitalization offers daily illustrations of operational differences between products understood as artifacts and services. For instance, a video (a software and a processed material in the ISO vocabulary) traditionally had a hardware substrate – such as a DVD – to which is associated a title to goods. This title to goods is itself correlated with a right of using the DVD on devices that can decode and play the registered video. Today, with video streaming, there is only a right of viewing the video which requires a service (activity at the border of the supplier) to make the video-stream available. Not only are the notions of title to goods and right of use deeply affected but also the very nature of the customer / supplier relationships.
As for artifacts, they have the quality of being identified as objects, whether in hardware forms (DVD) or in intangible forms (an application software). They have modes of production and modes of management related to their object nature: an object can be possessed, damaged, modified, destroyed, yielded. As for services, they establish a dependency relationship based on a delegation of activity in order to deliver an expected outcome. This affects the operating model of agents involved in their delivery and as well as the operating model of agents involved in their usage (customers). In conjunction, services have unique qualities such as continuity of service, quality of service, service execution modalities. The modes of delivery and management of services are necessarily different from those of artifacts: there is indeed no such thing as “product continuity” or “product execution modalities”.
At this stage, we could conclude that products and services are disconnected notions so long as their characterization is grounded on the tangible/intangible criterion. At least, we shall recognize that services are not mere outputs which ISO examples clearly demonstrate:
<..>a hamburger bought in a retail store is a product whereas receiving an order and serving a hamburger ordered in a restaurant is part of a service. <..>
Shouldn’t we consider the selling of a hamburger as a service which outcome is a purchased-tasty-hamburger? Thereby, how can a service be an output if any output requires a service?
The solution to the product and service dilemma lies in a shift from the production/output-[product or service] couple to the serving/outcome-[tangible or intangible] bundle. The shift is twofold: from output to outcome and from production to serving. The need for this new bundle comes from two facts:
✓ The nature of the outcome (tangible/intangible) is not a criterion that delineates product from services.
✓ There are no outcomes without some servings leading to these outcomes (purchased-tasty-hamburger).
Instead of talking of products and services, we shall rather talk about served outcomes.
From products & services to served outcomes
The journey towards served outcome enables a better separation of the problem space from the solution space.
The problem space viewpoint aims at defining expected qualities of served outcomes. They come twofold: qualities of serving and qualities of outcomes. In this context, serving is considered as a capability: an ability to perform an outcome. It provides a response to the question ‘what do we want to be able to provide? In the case of the hamburger, for instance, the outcome is the burger itself. Some of its expected qualities are “being tasty”, “being well cooked”, etc. Other aspects that influence the hamburgers quality is how long it took the customer to make the purchase. Was there a long line to buy the burger that was frustrating? . The overall offering of a purchased hamburger includes not only the quality of the hamburger itself but also the quality of the purchasing capability: a serving quality.
As for the solution space, it describes how things work: the operating model. It addresses served-outcomes from the perspective of how the provider acts and interacts to fulfill offered capabilities. In the case of the bought hamburger, the operating model describes how the retailer operates. This includes interaction points with the customer – self order kiosks or cahiers – as well as the retailer’s internal organization and supply chains. Descriptions of what makes-up an operating model will be delivered in further posts.
Most current architecture frameworks, such as ISO-9000, have their roots in the production-dominant design. They come from the manufacturing-oriented economy of the 19th and 20th centuries. Even when they add service aspects to their approaches, the legacy of production-oriented architecture is still at the core of their foundations. This explains why both products and services are conceived as outputs and segregated according to the tangible/intangible criteria.
The paradigm shift to served-outcomes provides a foundation to address both agile product-centricity and customer-centricity. In the marketing domain, product-centricity sometimes conflicts with customer-centricity because of its association to the production-dominant mindset criticized above. But in the agile crowd, product-centricity conflicts with project-centricity: products over projects, or we can say purposes over projects. The notion of product is understood as the raison-d’être of software system: their purposes. While this meaning of product is not explicitly defined in agile frameworks, indications can be found in the SAFe glossary around the feature concept:
A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI).
SAFe features are indeed, fine grained software capabilities and belong to SAFe requirement model. As such they lie in the problem space of served-outcome (stakeholder need): what do we want software systems to be able to do? What are its purposes? This approach provides a far better support for what is usually under the umbrella of requirement analysis.
The clarification of the notion of product in SAFe reveals its weaknesses in terms of architecture description: the entire field of operating model architecture is indeed left aside.
As for the served-outcome approach, it provides a full coverage of the problem space and the solution space of purpose-based architectures.
For now, we have limited ourselves to an inside-out perspective. The goal was to clarify the difficult notions of product & service. A complete service-dominant design approach requires to include a customer job perspective into the picture. SAFe uses customer stories to do so. But is this enough to address customer experience with an outside-in mindset?
In the next post, we will describe how served outcomes, value and experience come together.
Antoine Lonjon is Chief Innovation Officer at MEGA International. He has contributed to the foundation of the HOPEX enterprise architecture toolset and is also involved in standard organizations, such as the OMG and the Open Group
Copyright Antoine Lonjon, Chief Innovation Officer, MEGA International
 Definition of Minimum Viable Product from the Agile Alliance: https://www.agilealliance.org/glossary/mvp/
 Product Management in SAFe 4.5 : https://www.scaledagileframework.com/product-and-solution-management/
 ISO 9000-2015 : https://www.iso.org/standard/45481.html
 Definition of “ability” in WordNet 3.1:
 See article in Martin Fowler’s blog – Products Over Projects: https://martinfowler.com/articles/products-over-projects.html
 SAFe 4.6, Features: https://v46.scaledagileframework.com/glossary/#F
 SAFe Requirement Model: https://v46.scaledagileframework.com/safe-requirements-model/
 The way service-dominant design changes requirement analysis will be the subject of a dedicated post.