As companies embrace digital and look to leverage their data, processes and products to create new value streams software is becoming more and more important. Being able to deploy to a variety of devices is key to creating a digital business; mobile, web and server are all common platforms for software and now even desktop is making a come back.
I’ve seen a trend recently; some companies are beginning to ask the question, if we are using much of the same code on different devices, why not re-use it?
The cross-platform economy is a phrase I think best describes how organisations can build a suite of re-usable and modular code that can be deployed to multiple platforms (web, mobile, server and desktop). It will allow the same code to enable integration across many customer touch points and integration systems.
It allows businesses to unlock the deep value of ‘process’ described in code and progressively leverage this monetary worth across disparate internal architectures, applications and departments. It also allows business processes to be extracted into independent modules and these can be licensed to partners or even competitors.
In a digital economy the information captured in code represents an underlying asset in the monetary worth of a company much the same as property, equipment, ip or other assets.
Traditionally, software mal-practice leads companies down an ever winding road of replacement and rewriting. They need to target a new platform or create a new product; so they get some developers to create it.
Over time; requirements change, developers come and go, the infrastructure needs to be updated forcing code to fall inline and the codebase inevitably declines. It becomes fragile. Each piece of software which serves a specific purpose becomes fragmented and this in turn leads to a decaying and depreciating asset. Companies are stuck in a cycle of re-writing software; and this is expensive!
If we want to build the next generation of digital businesses built on software I ask, does it have to be this way?
Digital assets enable the creation of value and wealth in a business. In a modern digital company we can see correlation to history; much the same way in the age of the castle; military assets were used to protect territory and supplies in order to serve the economy of land, in the modern era IT assets are used to protect market share and exploit new opportunities of digital. We know this by the term; digital transformation
We see a wonderful illustration of how systems of intelligence (software and ai) actually form a power centre around data in the digital economy and how this correlates historically in Geoffrey Moores article.
I go further to say that it isn’t just data which is at the centre, but it is also process which becomes encapsulated in software which is at the heart of the 4th revolution we find ourselves in: the digital revolution!
Creating software is like creating the glue in your organisation; it holds the rest of it together. We can begin to consider that code is an investment into the intelligence of your organisation.
It should be protected in much the same way as any other asset. You wouldn’t erect a building and expect it to fall down every 10 years so why do it with software? It’s so important that you invest and maintain it because in this modern era it is your company.
A look at a recent article from Business Insider shows that software companies are now the most valuable. This goes some way to support my argument that software is an important part of modern businesses!
Instead of the old scratch and replace mindset where we keep re-writing software every few years we can think carefully about the time and attention we pay to crafting our digital systems. We should get it right, we should do it well; because every year these systems hold more and more value in our enterprises; and the cross-platform economy is one way of looking at our position from a business perspective instead of a technical one.
In order to understand the economics of my proposed model we need to evaluate it against the traditional model, which I like to know as; the mothball model.
In order to write software, companies turn to one of three methods. They either hire some permanent developers to help them create it, or they contract in some independent contractors (on short term contracts) give them a spec and let them heave-ho, or they work with an external software consultancy.
All three models are open to, and often do, exhibit detrimental factors that end up with software that is written to specifically solve a problem. The systems are often developed independently to be standalone, once they are finished they hit the BAU (Business as Usual) which are maintenance teams who supposedly keep on top of them and upgrade and enhance them.
Then after a few years the systems become bigger, they become more cumbersome, the code quality declines and they end up with excessive technical debt. Typically, managers are assigned to the management of these systems but do not actually fully integrate their management expertise at the code level. They simply manage it from a staffing and resourcing level.
Because no one is actually assigned to manage these systems from a ‘code level’, in terms of their strategic objectives; the code slowly decays over time. It will eventually be re-written or ‘mothballed’. This is just natural, managers manage, developers develop and in time the software will decay or loose relevance. It’s amazing to me how companies are happy re-writing systems every 10 or so years. It’s a total waste of money!
The traditional mothball model exhibits the following characteristics:
In the re-usable model a different approach is taken. At this point the first thing that is done is a competent technical leadership team (who can read code) is given strategic oversight over the software to be written.
They are tasked not with creating the systems per se but in managing the direction of the quality and the organisational specification that the systems ‘could’ meet.
For example; on some of our recent projects we have begun to establish which parts of a new piece of software could be leveraged against other business objectives - so that we can take a ‘strategic approach’ to our development efforts.
What’s important to note here is we still develop systems to meet only one requirement at a time, but we keep in our objectives the ability to build re-usable code. This is built into the specifics of our Agile and Continuous integration environments from the outset.
The re-usable model exhibits the following characteristics:
Knowing the difference between these two strategic approaches to building systems is important if we want to create a software enterprise. If software is powering the intelligence in our business we can begin to rationalise the value that is locked in it. When we understand the difference we can see the difference.
Let’s do some maths!
If we consider that the cost (per line of code), multiplied by it’s impact to the business (per line of code) leaves us with value (per line of code) we can see that in the mothball model the value of code actually declines over time because for every line of code we add more maintenance on a 1:1 basis.
This means the impact always stays the same. As projects become stretched managing multiple software code bases that all do similar things drives cost up. As we increase cost for every line of code the value of our entire code ecosystem goes down!
However in a re-usable context many lines of code are ‘used again’, every time we add a feature we begin to consolidate down common solutions into a single re-usable library. We slowly build out our systems with care, so that we can service multiple platforms and applications. The economics of re-usable code work differently. They mean that the value per line of code actually goes UP not DOWN!
The equation works like this :
The cross-platform economy builds on the concept of re-usable and modular code and uses emerging tooling and languages to be able to package up this code and deploy to multiple target platforms. It works with two basic objectives:
Instead of simply writing independent standalone systems, re-usability becomes key! We begin to target all of our platforms using ‘common code’; slowly adding more value over time not reducing it. This is the essence of cross platform economics and we can begin to see software as a deep asset that we can capitalise on!
We have established how software components can be re-used in multiple platforms. We can build web, mobile, server and even now desktop using the same code. But how?
At the heart of re-usability in software is making a decision to use a single programming language - so you can remove duplication. You can’t re-use code unless you do this. Duplication is one of the biggest challenges in creating robust software. Removing it helps us re-use it.
For example; using the server side engine (Node.js) we can now power distributed microservices and application based infrastructures.
In the diagram we have extracted common code out into shared modules and simply imported into the correct platforms during our developer build process. This encapsulation of the core business process (the order) into re-usable code is at the heart of the cross platform economy since it allows us to leverage the same code to remove duplication : cool!
My collaborator Andy Ng is starting a movement called CLean (Contemporary Lean) in which he talks about his experience creating re-usable systems in consultancy, media and investment banking. In it he goes into depth about a team structure that promotes diversity but keeps re-usability at it’s heart. You can see it here.
There are other deeper aspects of creating re-usable code and some of it reaches into advanced object oriented design, type safety, microservices and test driven development. I will look to cover these in a further article. So make sure you write to me and let me know what you want!
I believe software is broke. We spend millions writing and maintaining terrible systems. We find it hard to put the right resource into place that will help us manage our technical assets; at the same time as looking at the strategy of the physical code we write.
We come up with many high-falutin IT movements which attempt to improve software: but software development isn’t working for many. I think we should try and design high quality code bases which keep re-usability at heart.
In this article hopefully I have distilled down another approach to systems development which:
Request a call back and let's see if we are a good fit...