Yes, this is an odd sentiment to have as a Cloud-native software company but hear me out. We spend a lot of time talking to organizations about adopting Cloud concepts and approaches. The large majority of the discussions land in one of two categories:
- Help me move stuff to the Cloud to save money and time. This line of discussion quickly focuses on technology and tools:
- Which Cloud should I pick?
- Should I use Kubernetes?
- SaaS or PaaS or IaaS?
- What are the Cloud equivalents to my current stack?
- I’m skeptical of Cloud, so help me understand:
- Is Cloud secure?
- Will it actually save me money?
- What about vendor lock-in?
- Will my stuff run in the Cloud?
- How much work will it be to move?
When we dig deeper with our clients to try to answer these questions, we always end up exploring more fundamental IT organizational challenges instead. Why? Because talking about Cloud is talking about the destination rather than whether we have the capabilities to make the journey.
Imagine if a hockey team focused on moving into a new arena to improve its record and attendance rather than investing in its coaching staff and players?
That’s exactly what we’ve been doing in the IT industry: being fixated on where our apps run rather than how we build and operate them.
“Modern Software” not just “Cloud”
Cloud isn’t some revolutionary invention that just appeared one day. It is effectively an ongoing refinement of hosting technologies and business models that are enabled largely by two things: scale and automation. These are the same things that drove the Industrial Revolution. Therefore we should be viewing the rise of Cloud being indicative of the modern industrialization of the software industry.
So instead of talking about how we get to Cloud, we should really be talking about how we build modern software and what that really means.
What Does Modern Software Development Mean?
Traditional or legacy software principles were developed during a time where compute power was limited and optimization of CPU performance, memory, and storage was top of mind. In modern software development, we recognize that compute is cheap and so we should optimize for business outcomes instead. How quickly can we respond to changing user needs? How well can we scale if our software is wildly successful? How do we remain resilient to failures? How do we build and maintain user confidence? How do we control development costs with constant change?
Just like how the Industrial Revolution changed manufacturing, modern software means industrializing our process of building software along the same lines:
- Focus on software frameworks rather than programming languages to minimize “building from scratch”
- Automate the mundane and repetitive (e.g., CI/CD, test execution)
- Design for modularity
- Build for scale
- Exhaustively test for quality
- Constantly iterate for improvements and allocate budget for it
- Instrument the process and measure velocity; then improve it
- Design assuming failure will happen
- Assume and embrace constant change
Development and Operations are Intertwined
Many of the operational issues associated with traditional software development (e.g., chronic underfunding, tech debt accumulation, rust out, performance degradation) can be attributed to having too clear a delineation between development and operations. User needs, organizational priorities, and technologies are constantly changing. Therefore software development is never done.
Operating a software solution and developing new features or addressing technical debt must be an ongoing and integrated process rather than distinct activities. Concepts like DevOps aim to address this, but the change in approach involves the entire organization down to how software investments are funded.
Build People Not Widgets
Cloud migrations or app modernization initiatives are too often structured as outsourcing engagements where organizations feel the only viable path to success is to hire some experts to do it for them. This is frankly a shortsighted approach and I have yet to see it really work out, especially over a year after the project ends. Client teams are often left woefully unprepared to inherit and support the hundreds of applications which they’re no longer familiar with.
These big programs should be seen as an opportunity to upskill and reskill the organization’s technology teams instead. Expert teams can be brought in to work with the organization’s internal teams in a player-coach capacity to adopt modern software development methods and tools. The organization’s IT governance and management processes should also be adapted for modern software outcomes such as agility and velocity.
Let’s stop talking about Cloud and talk about investing in our people’s ability to build modern software instead.