@benjaminm Not if it’s a faster, better, cheaper Betamax/8 track player/rotary phone – value is in the use, not the construction
— Gene Hughson (@GeneHughson) September 7, 2012
I’m sure the person who asked Benjamin Mitchell that question truly believed that “faster, better, cheaper” was valuable. I’d imagine that person values his or her work and considers anything that enhances that work to be beneficial. Unfortunately, that’s not always the case. If I create something that fails to meet your needs, my ability to do so “faster, better, cheaper” is supremely irrelevant. From the customer’s viewpoint, value will come from the capabilities that your efforts enable, not from the work itself. The product is the value, not the project.
It’s no secret that I’m skeptical of emergent architecture. Solving various small problems in isolation is not the same as providing a coherent solution to the overall business issue. In fact, focusing exclusively on lower level details may impede our ability to solve the larger issue:
Intuition does not adapt quickly to new situations and resists changes in scale. A retail cashier who is exceptional at serving customers and processing purchases finds new, perhaps overwhelming, challenges in managing the store. The cashiers natural intuitive ability to diligently manage a single customers purchases is overwhelmed when presented with many customers and many purchases. The culprit is the complexity of detail. Often referred to as an inability to “see the bigger picture”.
Gary W. Kenward , “The Systems Perspective”
Just as a system is more than a collection of components, the product is more than a series of projects. Tom Graves, in the slides for his BCS-EA 2012 presentation noted (slide #8):
Products always imply a service…
- Whom do you serve, and how?
- How will you know you’ve served?
- How will you know you’ve served well?
- Who decides?
The answer to the first and fourth questions, are obviously “the customer”. Questions two and three, however, can be trickier. Feedback is required to answer those. The advantage of frequent incremental delivery lies in the fact that feedback can be gained, both by the development team and the customer/product owner:
We all know the world is not flat, and Scrum is not a linear process. But some Scrum teams use feedback only to improve the process, and forget to apply it to the product. User stories are consequently turned into software without learning from the stakeholders and adapting the backlog. This wastes a massive opportunity: to ensure that the right product with the right features is created.
Roman Pichler, “The Scrum Cycle”
If process improvement is emphasized to the point of excluding product improvement, the feedback is wasted. Each release should be seen as an opportunity to reduce the divergence between the product delivered and the product desired. The smaller the divergence, the greater the value.
Focusing on the product aspect, which meshes well with DevOps practices, enhances application lifecycle management by tying budgets to business value:
Using a product management approach, the organization now has budgets for product teams instead of new development or maintenance. Budgets are no longer lumped together, but are instead dedicated to specific product lines. Each product team needs to make the case why their product needs funding based on the business value that it generates compared to total life-cycle cost. Using this approach, organization can now make business decisions as to which products to innovate on and which to cut or retire.
Fadi Stephan, “You Build It, You Run It”
This kind of holistic approach encourages customer participation in the process, setting up a virtuous circle of increasing value, increasing ownership and increasing satisfaction. Products with a high level of customer satisfaction (not to mention those that work on the teams developing those products) tend to do better over time than those without.
Form Follows Function 
Hi Gene – many thanks for including my BCS-EA presentation in this!
In general, I’d strongly agree. I’d just like to add that questions #1 and #4 – “Whom do you serve, and how?”, and “Who decides” – can also be quite a bit trickier and more challenging, in exactly the same sense as for questions #2 and #3.
At a first level, yes, the obvious answer is – and should be – ‘the customer’. That’s really important. Yet if we also look a bit deeper, we’d note that there are actually two very different meanings to ‘whom [or what] we serve’.
One is the literal customer, the person or other service or whatever to whom we deliver the service (or product, if we start from a product-focus). The link there is ‘horizontal’, the usual value-chain.
The other is the aim of the overall shared-enterprise, the ‘vision’ or ‘promise’ typically indicated by a phrase such as TED’s “ideas worth spreading”. _Everyone in the shared-enterprise is committed to that same ‘vision’ or ‘promise’_ – it’s the _reason_ why the customers connect with us in the first-place, before exploring our ‘value-proposition’ that positions our product- or service-offering in relation to that ‘promise’. We could describe as a ‘vertical’ link.
_Both_ of these dimensions are what and who we serve; _both_ of these determine whether or not we have delivered our service well.
This might perhaps sound pernickety, but it has huge practical applications in business-architectures and enterprise-architectures. For example, it helps us to understand _why_ not every customer is right, or right for us; the balance and trade-off between these two dimensions helps us to identify the types of customers we want and value, and the customers we won’t and don’t. It also helps us to design support-services against both which our service-delivery _and_ the customer’s demands and expectations can be assessed in a demonstrably fair and transparent way – a design-criterion that, just on its own, can save our organisation vast amounts in mitigated risk for litigation and PR-costs.
It’s one step further than most conventional approaches to EA and the like would usually go, but it’s well worth the effort. Happy to talk further with you on this somewhen, if you’d like.
Once again, though, many thanks!
LikeLike
Tom,
Thanks for stopping by…no worries re: persnicketyness, I appreciate the clarifications.
More than that, you’ve provided me with fodder for another post in the future – I’ve previously written about the fact that serving the customer doesn’t mean passively saying “yes sir” to each and every demand (sometimes a little push back is in their best interests when they don’t have all the facts in hand), but I haven’t addressed the idea of the unwanted customer.
Cheers,
Gene
LikeLike
Pingback: Avoiding Platform Rot | Form Follows Function
Pingback: Design by Committee | Form Follows Function
Pingback: The Great Divide – IT versus “the Business” | Form Follows Function
Pingback: Architecture – Finding Simple Solutions Over a Lifetime of Problems | Form Follows Function
Pingback: Fixing IT – Products, Not Projects Revisited | Form Follows Function
Pingback: Avoiding Platform Rot | Iasa Global
Pingback: Design By Committee | Iasa Global
Pingback: Technical Debt – Why not just do the work better? | Form Follows Function
Pingback: Fixing IT – Too Big to Succeed? | Form Follows Function
Gene:
One legitimate view of an organization, I think, is as a collection of capabilities.
It occurs to me that if we ask and answer the question ‘What capabilities does this project impact?’ it might help to identify where actual business value is created, enhanced or diminished (though clearly this is not a goal but a side-effect.)
Just a thought,
Howard
LikeLiked by 1 person
Howard,
That is absolutely a legitimate and IMO, useful view. Likewise, the question; not just regarding a particular project, but in relation to the product(s)/system(s) affected. Increasingly, technology is a major enabler of the capabilities that comprise an organization. Just as those capabilities are long-lived, so should the systems that support them be. In my opinion, taking the long view in regards to those systems increases alignment and understanding between those creating/maintaining those systems and those using them to provide the capabilities of the organization.
Gene
LikeLike