After our three-part series introducing microservices, we’ll now be rolling out our multi-blog series outlining Microservices Foundations. Due to the large and often complex nature of microservices transitions, resources and funding are required from all components of the enterprise that may present some roadblocks. In this blog Ian Vanstone, Chief Technology Officer at IntegrationWorks will be discussing the availability of funding microservices projects for large enterprises and how to work through it.
Microservice architecture, as we know it, is a distinctive software systems development method that has been growing in popularity recently. However, due to the relatively new and evolving nature of the practice, it’s best to give a re-cap on definition provided by James Lewis & Martin Fowler;
“In short, the Microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”
– James Lewis & Martin Fowler, martinfowler.com
The IntegrationWorks Foundations for Microservices includes the following topics:
- Agile funding mechanisms
- Highly flexible organisational models
- Granular Product Management practices
- Decentralised governance practices
- Continuous Delivery practices
- Operational practices and systems
- Leveraging and developing new technologies
- Decentralised data storage practices
- Accessing and developing IT talent
- Traditional delivery and microservices delivery border management
- Security practices
In this blog we cover some perspectives on the first foundation – agile funding mechanisms.
Microservices do not fit well with traditional enterprise IT project funding models – i.e. large capex projects. Agile (of the scrum and especially kanban variety) has suffered here for years too due to the lack of tailored funding processes. Microservices and agile are both reliant on de-centralised and emergent design and therefore suffer in the coarse world of command and control organisations that predominantly feature long planning cycles and shared services delivery structures. The fact that the traditional capex funding model does not fit with microservices theory (or ideology) can make a shift to opex funding look appealing but it also has several drawbacks.
If you’re struggling to tailor your funding process, we outline some high level approaches below. Whilst they won’t all fit your organisation standards and conventions, they are a useful starting point in understanding an organisation’s ability to fund the delivery of microservices architectures.
Permission based capex funding model
This is the traditional IT capex funding model, where funding is allocated coarsely – based on long planning cycles for relatively large projects. It is often used in situations where is it hard to define the link between IT budget and business value (e.g. immature/unclear product/business ownership, shared services org model, ITIL, waterfall project, server based licensing, buy big to handle projected scale for a number of years for example.). The model:
- enforces a typically heavyweight funding approval process (i.e. Permission) before IT delivery.
- creates an inconsistent delivery tempo as per funding approval cycles as a result of the large sizes of projects.
- aligns the capitalised value of assets to the upfront approved funding.
Forgiveness based capex funding model
This model is still focused on capex but funding cycles are shortened by less stringent business casing before delivering and the funding is not tied directly to a forecast outcome/asset. Budget is still controlled but focused more on delivery (and cost) cadence. So IT delivery can occur without a heavyweight business case process and late priority calls can me made on the order of delivery (e.g. Which microservice to deliver/change next from the backlog). So, as well as being suited to long planning cycles for relatively large projects, this model is also suited to backlog driven delivery of smaller deliverables – where a more regular tempo/cadence can be achieved. It also aligns the capitalised value of assets to the value of the outcome delivered.
Opex based funding model
This model does not use capex but instead uses opex – and is suited to backlog driven delivery of smaller assets. It is often used where the lifespan of assets is relatively short. Action under this model can be prioritised as per backlog and no assets are capitalised.
On reading the above I’m sure you can see that there are significant tradeoffs here between these models. For instance, what would our CFO say if we propose to use opex? As well as understand these tradeoffs it is important to take the following questions into consideration:
- How does TCO actually compare between the options?
- What is our modelling, testing, reporting approach?
- What is the impact of options on our company strategy of either approach?
- Can we use multiple models or take a staged or granular approach?
- Can we quantify the benefits, financially or otherwise? e.g. is there an agility or market share advantage to shifting to a new model?
- How can manage risks as we shift to new funding models?
To help answer some of these questions and assess the funding option tradeoffs for your organisation, it might be fitting to talk to the microservices experts here at IntegrationWorks. IntegrationWorks microservices offerings include executive briefings, defining microservices in the context of your business (and how it fits with SOA, ESB, data architecture, API First and Continuous Delivery), identifying costs and trade-offs for your business, roadmapping and POC’s.