VALUE IDENTIFICATION

Value should be a measurement of the whole, not the part; not solely what you can offer, but an amalgam of what you and your supply-chain can offer your customers.

Whilst customers may not always explicitly state it (Functional Myopicism), they expect certain qualities in the software and systems that they use (and purchase); such as stability, Security, accessibility, Performance, and Scalability. Customers who directly foot the bill for your service probably also appreciate efficient (and cost-effective) software construction and delivery practices.

TABLE STAKES

When viewed, these system qualities are often seen as Table Stakes, and may be glossed over during sales discussions. However, that doesn’t make them irrelevant.

Most businesses rely heavily upon the software platforms and services of others; and as a business, we inherit traits and qualities from those suppliers (e.g. platform stability, or instability); yet we can’t necessarily Control any of these aspects themselves. And if customers value the whole, not the part, then logical deduction suggests that these inherited traits also hold customer value. The figure below shows some examples of inherited traits (value) that suppliers may offer you and your customers.

Some might question the merit of these qualities, so let me present you with some examples based upon my experiences.

EXPERIENCES

EMBEDDED WEB SERVERS/CONTAINERS

Web servers/containers are used to host software and serve out web requests. Historically, they have been treated as entirely independent entities, embedded within the deployment and runtime software delivery phase, rather than the construction phase; however, those lines are now being blurred.

Embedding web containers into my day-to-day engineering practices had profound benefits on my software development habits and productivity over my original working practices. Bringing development, testing, and deployment activities closer together enabled me to do more of what I had typically invested less effort into (not through choice as much as through necessity), and to do so sooner.

For instance, prior to the switch, these were the steps I would typically follow:

1. Write the code.
2. Build and package the code.
3. Stop the web container.
4. Copy the runtime artefact.
5. Navigate to the correct folder in the web container, and paste in the artefact.
6. Start up the container.
7. Wait for it to start.
8. Execute runtime acceptance tests.

Whilst I performed some form of incremental development involving deployment and runtime test phases, it was numbing and laborious, and rife with start/stop/navigate/wait activities. Embedded web containers changed all that, and also allowed me to embrace TDD practices.

I estimate these practices improved my delivery performance by around 25%, enabling me to deliver functionality (of greater robustness), sooner, through more rigorous testing.

MAVEN

Whilst Apache Ant was a significant step forward over its predecessors (e.g. “make files”), it was — for me — Apache Maven that was the real trailblazer. Maven is a build automation and dependency management tool that uses an elegant, easy-to-follow syntax, sensible conventions (e.g. a standardised location for source code and unit tests), has fantastic dependency management (a key problem to minimise duplication and “versioning hell”), and strong plugin support (see my point about embedded web containers). The end result? Increased Productivity, Uniformity, and (release) Reliability.

MOB PROGRAMMING

Whilst initially sceptical of this approach (a group — or mob — work on the same work item together for an extended period, until complete), I soon found it to be a great way to align teams around a domain and/or a problem, gain new skills, collaborate, build trust and acceptance, grow in confidence, and increase business scalability and resilience (having a pool of people with sufficient expertise to solve similar problems increases flexibility and enables the more reliable sequencing of project management activities).

DISTRIBUTED ARCHITECTURE

The introduction of a distributed (Microservices) application architecture enabled me to innovate (use a range of different technologies to solve a problem), isolate change (increase Productivity) and therefore reduce risk, support evolution, and embed TDD practices into my day-to-day work.

THE CLOUD

The Cloud has had a significant impact on many technology-oriented businesses. Need I say more?

LINKS AND ENABLERS

Most of these technologies/techniques have close associations or interrelations; and one often becomes a direct enabler to the next. For instance, in a previous role, I couldn’t gain the benefits from embedded web containers (or Maven), until we broke the monolithic architecture into smaller “Microservices”. Once that approach became available, I could more readily apply a TDD mindset to many problems, resulting in better quality code and swifter future change. That TDD-driven mindset supported a marked increase in automated test coverage, which subsequently promoted continuous practices, like CI/CD. Once that was in place, I could look at Canary Releases etc etc.

My point is that there are almost always second and third-order effects to any decision, and you can’t necessarily know what the downstream impact of introducing one idea/technology will be. As I described, the introduction of one innovation may lead to many others, leading to a flood of innovation, and cultural improvements across the business.

PERCEIVED VALUE

Surely some, if not every one of these innovations has value? So, why are they given a second-class status within so many organisations? I can think of several reasons:

• Features are — to put it bluntly — more interesting to most people than non-functional qualities, and therefore drive more interesting discussions.
• Customers infer many of these qualities as Table Stakes, so they may be glossed over and easily accepted in sales discussions. This is a double-edged sword — it allows sales discussions to be steered by the key drivers (e.g. functionality), but it doesn’t necessarily promote these as important qualities in the minds of leading internal executives. Not asking about something, and not caring about it are two different things.
• Many of these traits aren’t easily contextualised (Value Contextualisation).
• Customers don’t appreciate the ramifications of the absence of a system trait (to my last point about contextualising) until it’s too late. A failure in any one quality can cause severe embarrassment, reputational harm, or even a business’ demise (consider the reputational harm done by businesses suffering from a data breaches). I’d place a bet that most of the executives within the organisations that have suffered a significant security breach are now deeply aware (contextualised) of failings in the Security quality.

WHAT’S THE MINIMUM?

Good ROI is mainly about doing the minimum to satisfy Table Stakes, whilst investing the remainder on creating diverse functionality that excites customers. You want prospective customers to leave with the perception of a high quality product (which it hopefully is), and balance effort (and therefore ROI) by doing just enough Table Stakes to be successful. But how do you measure what’s the minimum? It’s rather subjective.

We can perceive value from two alternate angles:

1. What external parties (customers) perceive.
2. What the internal business — offering the service — perceives.

See the figure below.

The external and internal parties perception of value are rarely identical, and can often be radically different. There’s no hard-and-fast rules in how different stakeholders perceive value. For instance, whilst some customers may perceive value lies with Functionality, Reliability, Usability, (and possibly) Security, internal stakeholders may perceive value lies in Functionality, Reliability, Scalability, Security, and Productivity. Much of these views comes down to our ability to Contextualise, yet perception may also shift over time, as people gain new learnings, or by the stimulus of some tumultuous event, causing us to reassess our previous beliefs.

We might visualise the problem as two distinct sets of perceived value, intersecting where the two parties are in agreement. See the figure below.

For instance, if both parties viewed Security as being of prime importance, then that quality would lie within the intersection, and should therefore be accorded an appropriate amount of energy from both parties. Ideally, there would be a large intersection (a commonality) between the two, representing a close alignment in goals and virtues between the two parties (you and your customers); such as in the figure below.

To my mind, this scenario better represents a partnership between aligned parties, rather than the typical hierarchical customer-supplier model that’s been a mainstay of trade for centuries. In this partnership both parties are deeply invested in building the best product or service; not because it benefits the one party only, but because it benefits everyone: 1. your business, to build a world-class product to sell widely, and 2. the customer, to allow them to reap the biggest benefits from that product.

As Adam Smith put it:

“It is not from the benevolence of the butcher, the brewer, or the baker that we expect our dinner, but from their regard to their own interest.” [1]

“INTERNAL VALUE? — WHY SHOULD I CARE? I DON’T PAY FOR THAT”

External customers may be of the opinion that they don’t pay for internal value. They’re paying for functionality, not some seemingly vague notion called Maintainability, Scalability, or some other “ility”.

Whilst I understand that viewpoint, it seems rather myopic, and — to my mind — not entirely valid. In one way or another (whether in its entirety, or through some SAAS-based subscription model), external customers pay a share for the product or service that is delivered. And ALL software has production and delivery costs. And what about innovation?

If the supplier is slow (because they have inefficient construction or delivery practices), the external customer “pays” in the following ways:

- They’re investing in the time for that business to do things other than produce functionality, or (for instance) the further stabilisation of the platform.

- They’re not getting innovation quickly enough. Consider this a bit longer. I’ll wait… Innovation is key to the existence of many businesses; without it, many would have shrunk into insignificance. And if your competitors (using another supplier) can out-innovate you, then surely that represents a problem?

There’s also something to be said around Brand Reputation. As a customer, you should be able to ask the tough questions about scalability, resilience, security, productivity etc. Misinterpret these and you’ll pay for them too; whether in fines, lost revenue, share price, or simply embarrassment. Don’t believe me? Do a quick search on some of the big organisations who’ve suffered a major security breach, or the airlines that have suffered system availability/resilience issues, and analyse the outcome.

SUMMARY

My point? Different parties perceive value differently. The greater the discrepancy, the greater the chance of that partnership (eventually) failing. Some modern businesses have dismissed the rather one-dimensional, and deeply hierarchical, customer-provider business model, to favour one of a collaborative partnership, by aligning on what’s truly valuable (the qualities intersection) and learning from one another, to build long-term relationships of mutual benefit.

We dismiss the value that (upstream or downstream) suppliers can provide from our regular productization practices at our own peril; they offer benefit internally and externally; platform upgrades should be given a first-class status alongside internal product improvements.

However, to appreciate value, we must also be able to contextualise it; the subject of the next section (Value Contextualisation).

FURTHER CONSIDERATIONS

• [1] — The Wealth of Nations — Adam Smith
• Flow
• Table Stakes
• TDD
• Functional Myopicism
• Control
• Value Contextualisation