There’s been a lot of discussion amongst the technology community about the rise of microservices, as engineering teams at companies like Netflix, Amazon, Uber, and eBay embrace this popular approach. While it has many different names and shades, what’s most important is for CIOs to deliver on the value that microservices promises: “Delivering innovation to business faster.”
High-velocity development has always been the goal of technology leaders, and microservices is one of the latest means to that end. An important aspect of this approach is being able to do more with more developers. It’s a hard truth that most teams don‘t become faster just by adding more developers. In fact, they too often become slower. Turing award winner Fred Brooks (who managed IBM’s development of the OS/360 and later founded the University of North Carolina at Chapel Hill’s computer science department) famously said "adding manpower to a late software project makes it later" in his definitive book, the Mythical Man-Month. When it comes to software engineering, true scale is only achievable if teams work independently from each other.
Many technology organisations are turning towards parallel delivery approaches in order to untangle the complexity of interdependent, release-based development, testing, shipping, and production. These companies recognise it’s time to make the transition from monolithic architectures towards loosely coupled, component-based systems that increase IT flexibility and strengthen its links to revenue-generating business units. What’s more, these practices enable critical organisational changes necessary to achieving the kind of speed all companies need and want.
Technical groundwork and agile principles go hand in hand. CIOs need to ensure they excel in both to drive the velocity of a company’s innovation. In my experience, here are the three most important areas to watch out for:
1. Tear down the wall between “planning” and “building”
In order to move faster, many CIOs restructure their development organisation from big, interdependent groups into small, flexible, autonomous teams. These tight, interdisciplinary teams encompass business and IT roles – not only the full development chain (delivery/devops, operations, and testing), but product owners as well. Responsibilities are shifted so priorities stay tightly aligned to business value and frequent feedback loops help reduce development effort.
Some helpful KPIs to track during an organisation transition like this include requirement sizes, implementation cycle times, and developer productivity. When creating micro-teams, it’s important they have clear ownership of their respective services. There will inevitably be some overlaps and redundancies, but the time-to-delivery improvements that they will gain from working in parallel will more than compensate. As teams work independently, they can focus on adhering to just their own plans, which eliminates coordination bottlenecks and shortens their time to success (or failure).
2. Break up applications into smaller pieces
Companies also accelerate delivery cycles by breaking their monolithic applications into independent code units (ICUs) to quickly create, iterate, and destroy services on top of their core applications. By deciding how to break up each application, and getting visibility into where conflicts exist (such as when more than one team is working on a code area), changes can be deployed independently and frequently, and the ICUs are better able to cope with failure. If one service fails, the rest of the application remains unaffected.
Some helpful KPIs to monitor the move away from monolithic “elephant” applications, towards building (or rebuilding) much smaller services or ICUs might be how much business logic is reduced in monolith applications and increased in microservices; the number of architectural areas being modified by more than one team; the percentage of development effort still going into monoliths; and whether quality levels are maintained.
During this process, each ICU should have a limited scope that supports a single value chain. The key here is to innovate rapidly and terminate further development if the value chain proves unsuccessful. The small, self-contained units of code can be easily removed, rewritten, or replaced without other services being affected.
3. Automate the development chain
At the end of the day, you can’t fully speed cycles with smaller teams and code units unless you also automate testing and continuous deployment. As developers start releasing less code more often, you need the following steps in the process to move faster as well – from Q&A and testing, to production releases and operations.
Some helpful KPIs to track your success when it comes to continuous deployment are cycle time; how much test code is built up; the test coverage of code units deployed to production; or the number of updates to the live platform.
As you make progress on use cases like these, you can reveal valuable insight by analysing the footprints in your codebase. Over time, CIOs should measure whether velocity objectives are met by asking questions such as:
· Are we improving time to market?
· How responsive is our delivery organisation?
· Are we getting more value for our money?
· How much effort is spent for each new service or ICU?
· Are we maintaining code quality?
· Where are there still deviations from the service-oriented model?
Few would argue that in the age of digital transformation, fast time-to-delivery is critical for every business in all industry domains. As leading management expert and author Gary Hamel noted, “The world is becoming more turbulent than organisations are becoming adaptable. Organisations were not built for these kinds of changes.” This business agility – especially when it comes to a company’s software – is a leading indicator of future success in today’s digital economy.
However, the waterfall hierarchies typical within most large enterprises hinder agile mindsets, and I’ve found that there’s often a perception from the business side that “IT is slow” to deliver. That’s despite engineering teams being the first in an organisation to adopt agile best practices like those I’ve described above. Bear in mind that bottoms-up, free-floating agile can only get you so far if your development teams are working with unwieldy business requirements that end up changing before much progress can be made. Unless product owners also speed their cycles and invest the time needed to revisit product direction on a daily or weekly basis (as opposed to just handing off requirements quarterly or annually), software innovation will stagnate.
In order to survive, your business must rapidly react to new opportunities and implement new requirements and functionality faster than your competitors – and this requires highly adaptive software infrastructure and teams in every part of the organisation.
Johannes Bohnet, CPO, Seerene
Image source: Shutterstock/Kalakruthi