Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
“Individuals and their interactions ... over processes and tools!": venerable EA frameworks and methods such as SADT and its successors such as ArchiMate are shaken to their very foundations, not to mention TOGAF in its 9.x versions. This trend is not specific to IT and shares common ground with the Lean Management and Design thinking mindset. All share the idea that smaller is better whether it enables agile delivery, persistent improvement, or solution thinking. This idea of smallness within bigness is not new and has already been coined a couple of decades ago by F. Schumacher2 under the catchphrase small is beautiful. Schumacher argues that “when it comes to action, we obviously need small units, because action is a highly personal affair, and one cannot be in touch with more than a very limited number of persons at any one time”. It is no coincidence that Schumacher wrote his book in 1973 when the energy crisis was spreading on an international scale, as an emergence of globalization. At a larger scale, he acknowledges the need to bridge freedom to order, which can only be reached by linking local purposes to global purposes.
Indeed, making small-is-beautiful real, leads towards autonomous and self-organized teams which are empowered and given purposeful missions. The key for success is to work at a scale of activity where people matter. As Dan Pink says in his book Drive, “people Work for Purpose, Autonomy and Mastery3”.
This approach manifests a shift of focus from the traditional command and control organization of work, to the organization of purposes. As stated by Conway’s law4 , the structure of products reflects the structure of organizations which produced them. Hence hierarchical organizations lead to monolithic products, One of the core challenges of modern architecture is to account for this parallel split of units of purpose and units of work. As such, if small is beautiful, how do you manage decomposition at the level of the enterprise? Additionally, how do you scale from local purposes to common purposes and ensure decentralized, sustainable business models?
For the architecture discipline to address these challenges, we need to revisit some of its core concepts: what do we mean by purpose? what do we mean by value? what do we mean by being product centric? As stated by Russel L. Akcoff5 , definitions are like surgical instruments: they become dull with use and require frequent sharpening and, eventually, replacement.
In our next post, we will address the challenging concepts of product and service. At the core of agile is the notion of product owner. But what do we mean by products and services?
from product & service to “served outcomes”
Being product-centric is at the core of the agile discipline; It comes along with the notion of Minimum-Viable Product (MVP[1]). 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?
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[2] 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[3].
3.7.5 Output,
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.
3.7.7 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.
3.7.6 product
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 materials are 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.
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[4]. 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[5], 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:
Features[6]:
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[7]. 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[8].
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.
1- Manifesto for agile software development: http://agilemanifesto.org/
2 - F. Schumacher : https://en.wikipedia.org/wiki/E._F._Schumacher
3 - Daniel H. Pink, Drive : the Surprising Truth About What Motivates Us (Penguin, 2011)
4 - Cownay’s law: Conway's law is an adage named after computer programmer Melvin Conway, who introduced the idea in 1967.[1] It states that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."
https://en.wikipedia.org/wiki/Conway%27s_law
5 - Russel L. Ackoff: Towards a system of systems concepts.
[1] Definition of Minimum Viable Product from the Agile Alliance: https://www.agilealliance.org/glossary/mvp/
[2] Product Management in SAFe 4.5 : https://www.scaledagileframework.com/product-and-solution-management/
[3] ISO 9000-2015 : https://www.iso.org/standard/45481.html
[4] Definition of “ability” in WordNet 3.1:
http://wordnetweb.princeton.edu/perl/webwn?o2=&o0=1&o8=1&o1=1&o7=&o5=&o9=&o6=&o3=&o4=&s=ability&i=0&...
[5] See article in Martin Fowler’s blog - Products Over Projects: https://martinfowler.com/articles/products-over-projects.html
[6] SAFe 4.6, Features: https://v46.scaledagileframework.com/glossary/#F
[7] SAFe Requirement Model: https://v46.scaledagileframework.com/safe-requirements-model/
[8] The way service-dominant design changes requirement analysis will be the subject of a dedicated post.
