The Business Value of the Back End

In my experience, most companies are good at recognizing the value of customer facing, revenue generating features and not so good at recognizing the value of back end, platform features.  Which is a real shame, because without the platform there can be no customer facing features, and beyond that, if you invest in platform you can squeeze even more value from it through quicker time to market, more availability, and growth at better marginal cost.

I can see why we're in this situation - it's easy to judge the business value of customer facing features; you can count revenue, wallet share, registrations/conversion, ARPU and stickiness quite simply.  Capability, which is the primary deliverable of platform, is tougher to describe in measurable ways.

Perhaps at this point we could just agree to disagree, but it's not that simple.  As engineers, we know that there is a certain amount of effort we have to spend on platform just to keep the business running.  We also know there is a certain amount of effort we should spend on platform, which would result in tools that lead to better quality.  And, to be fair, we also know there is time we could spend on platform that would take us into diminishing returns.  Ensuring the business commits to the have to effort and helping to get better trade-offs for the should do investment is why we can't settle for mutual incomprehension - we need to get better at selling this.

It should be easy, because there is business value in the platform things that we, as engineers, want to do - after all, if there wasn't, we wouldn't be proposing them.  To me, the answer is in how we describe what we want to do.  If we can articulate the business value better then we level the playing field between features and platform.  This enables decision makers to compare apples with apples when deciding how to spend the organisations resources.

Some simplified examples:

• Refactoring some old products into loosely coupled services = a more granular failure model = more consistent service to customers (you can't take revenue through a 404).
• Improving the throughput of a database server = quicker market settlements = customer funds returned sooner (they'll trade again more times that day).
• Separating UI components and content management = more front end flexibility and editorial control = more marketing and promotional opportunities without software changes.
• Providing a simple, abstracted data storage and retrieval interface = less complexity for engineers building new products = quicker time to market for new features.
• Implementing a messaging infrastructure which presents core components as APIs = more reuse and isolation of features = more concurrent workstreams and easier outsourcing (because of the natural boundaries created).

We can never guarantee people will make the decisions we consider "right" but if we use the language of the business when we're describing the platform capabilities we want to build we'll at least have removed the primary barrier to understanding.

For any web business to work, everything has to be a balance of customer facing features and back end capability - the key is that balance being determined by a true comparison of value.  I think we'll know that we're on equal footing when capability gains are celebrated when released, and pursued when missed, with the same ferocity and dedication customer facing features are.