Transcending the CapEx – OpEx dichotomy
There is a mismatch between the reality of modern software and digital products development and the binary separation between CapEx & OpEx. Let’s see how modern approaches overcome that.
In software and digital products development, the traditional, most common, and obsolete approach to CapEx and OpEx revolves around a special event in time, the release of the product. It is a heritage of when the software was stored in mass storage mediums (floppy, CD, DVD), packaged, shipped and sold.
The activities that typically come before the release (new product and/or features development) are considered CapEx, the other activities that typically come after (maintenance, support) are considered OpEx.
While evolving the product (bug fixes, patches, service packs, new minor and major versions) has been a grey area ranging from OpEx to CapEx on a case-by-case basis.
This way of thinking often sees 2 separate software development “project” teams (*):
– one rewarded for quickly creating a new product/features (and new bugs)
– one rewarded for quickly bug fixing, support & maintenance.
Where quickly often can be interpreted as cutting corners.
And where the software development teams are seen as an external function that is subordinate to the business and plays an enabling or supporting role to the business. Outsourcing the teams is pretty common in this space.
The continuous regeneration of software & digital products
Nowadays software and digital products development are released online and frequently updated. They require a constant effort to keep them up to date with the constantly accelerating rate of change of the security threats, the evolution of the tech eco-system they are intertwined with, and the constant evolution of users’ needs, wants, habits and expectations.
While this idea of software ageing is not new (see software ageing) the surface of the ageing (security, libraries, frameworks, services, platforms, business domains and users) and its speed have grown by orders of magnitude, creating a new dynamic that requires a new approach.
Without a new approach of continuous regeneration coming from continuous maintenance and evolution of the software and the product, they would wear out, deteriorate and rot over time, as Giulio Vian has recently pointed out. When this happens, then the software and the digital product needs a form of rejuvenation, as recently pointed out by Uberto Barbini.
This continuous regeneration, which is indistinguishable from new product development, is a capital investment needed to sustain the continuous maintenance and evolution of the product. And this leads to a new approach to transcend the traditional CapEx – Opex separation.
Together with this way of thinking, it is common to see software development Product teams (*) practising DevOps (the real thing, that is a mix of a culture of collaboration across developers and ITOps, automation practices, monitoring and measurement and transparent sharing, not the “DevOps team” theatre). Those teams are taking care of the whole end-to-end life-cycle of the digital product. Here software teams play an essential differentiating role for the business or they are even one and the same with the (digital) business.
Here below an example of how different activities fall in the CapEx or OpEx category:
CapEx
- Development of a new product, its infrastructure (e.g. cloud set-up and solution design) and new features
- Evolution and improvement of the product and its features
- Refactoring of the product
It depends (Middle Earth)
- Adaptations related to changes in the business domain or of the users’ needs and wants and expectations
- Maintenance and refactoring of the product including updates related to its security, adaptations to changes of the external tech-ecosystem (libraries, services, etc.)
- Small changes made as a consequence of support requests from users
- Bug fixing of defects discovered after the release, during the development, evolution or maintenance
- Bug fixing of defects discovered after the release, by monitoring and any other quality inspection
- Bug fixing of bugs reported after the release by end-users
- Salaries
OpEx
- Operating the product
- Leasing and maintenance of the production environments and cloud services
- Users/customers support
Just looking for example at the cloud, its set-up and the design of the solution that employs the cloud, make give us an example of how much design decisions can reduce the CapEx side of that cost (a simplified cloud solution may take less time to be realised and may need less skilled and so cheaper professionals) while increasing the OpEx side (that solution may lead to much higher Cloud bills), or the other way around. Not to mention that the adoption of hybrid cloud infrastructure (using private and public cloud services together) may throw the whole cloud chapter into the Middle Earth.
When someone wants to stop any investment in a product and just wants to keep the lights on, the items in Middle Earth still need to be taken care of, so in a sense they are OpEx.
On the other side when someone wants to continue to invest in a product, without the items in Middle Earth it won’t be possible, so they are also part of the CapEx.
So paradoxically they are both CapEx and OpEx. Or in practical terms at every accounting period, a determination must be made based on what is going on at that time.
Same for the salaries of the product team members that may work both on CapEx and OpEx.
There is no need to track the CapEx and OpEx work at individuals or backlog items level, it is sufficient to sample the backlog, estimate the percentage of the different Items and where they fit in CapEx and OpEx terms and then account for the salary of the whole team in CapEx and OpEx accordingly to those percentages.
Specific accounting regulations, that can typically be late to catch-up with the fast-changing tech world, may apply and may differ from country to country as well as for the type of company (internal software development, embedded software created and used by a product company, a Software house selling software).
Then there are conventions that tend to be even slower to evolve but not mandated by any binding regulation, other than the “we have always done it this way” regulation…
_______________________________
(*) Product over Projects, Projects to Products principles, Journey to Product Teams
Develop Technical Excellence that delivers.
See how we can help.
You, your team, your Tech.