There is a great deal of talk about the crucial role culture plays when a company undertakes a Cloud Native transformation. But what does that really mean, and why is it so important?
Cloud Native is more than a tool set. It is a full architecture, a philosophical approach for building applications that take full advantage of cloud computing. In this context, culture is how individuals in an organisation interact, communicate, and work with each other.
In short, culture is the way your enterprise goes about creating and delivering your service or product. If you have the perfect set of cloud platform, tools, and techniques yet go about using them wrong—if you apply the right tools, only in the wrong culture—it’s simply not going to work. At best you’ll be functional but far from capturing the value that the system you’ve just built can deliver. At worst, that system simply won’t work at all.
Culture: The Sum of Our Actions
How do we know what we are talking about when we talk about a company’s culture? What does the word even mean inside an enterprise? The answer is surprisingly concrete for such an abstract concept.
Culture is the sum of the daily actions that you take. Your routines. If you talk to people, you have a collaborative culture. Being required to seek permission before trying something new means you have a hierarchical culture.
Add up all the things you do in the course of a normal work day, and then step back to look at them from the perspective of the collective, but most often unexamined, assumptions that shape and drive these actions. These assumptions, about how work gets done and how people interact in your company, will show you your culture. And this is not fixed or immutable—culture is slow to shift, but it can be done.
If you change the actions, you change the culture.
A (Brief) Field Guide to Organisational Culture
The three major types of culture within enterprises are Waterfall, Agile, and Cloud Native. A quick primer:
Waterfall organisations are all about long-term planning. They deliver a large, solidly built and tested project bundling many separate services into one deployment every six months to one year (perhaps even longer) timeframe. They are risk-averse, with a long decision-making chain and rigid hierarchy. There are a lot of managers, including project managers. Waterfall organisations tend to have specialist teams handling very specific skills—security, testing, database administration, etc.
Although market estimations (from vendors of Agile tools and solutions) suggest most companies have adopted at least some Agile practices, our own estimation is that about 80% of software today is still produced using Waterfall development style.
Agile organisations recognise the limitations imposed by monolithic long-term releases, and have adapted to deliver faster by using an iterative, feature-driven approach to releasing in two- to four-week 'sprints'. Agile development breaks applications into their functional components, each of which is worked on, start to finish, by a single team.
Instead of handoffs between specialist teams, Agile has cross-functional teams whose members hold all the skills necessary to design, build, and test the service they are responsible for developing. The result: There are wide responsibilities in a team, but a very narrow responsibility for the team. Scrum is the functional implementation of Agile, and scrum masters facilitate between the different process-owner teams.
Cloud Native organisations are built to take optimum advantage of functioning in cloud technologies (clouds will look quite different in the future, but we also build to anticipate this). Applications are built and deployed in a rapid cadence by small, dedicated feature teams made up of developers who also know how to build in networking, security, and all other necessities so all parts of the distributed system become part of the application.
Meanwhile, a platform team sits off to one side, designing and assembling the platform the devs will deploy to; this highly automated platform uses an orchestrator like Kubernetes to manage the complexity. Cloud Native architecture centers on microservices architecture, i.e., decomposing applications into small, loosely coupled services that operate completely independently from one another. Each of these services maps to smaller, independent development teams that release iterative software updates as soon as they are ready, i.e., Continuous Integration and Continuous Delivery. Rapidly releasing software creates a tighter feedback loop, allowing enterprises to easily adapt and respond to customer demands and desires.
Although Cloud Native is powerful and can provide a serious competitive edge in many cases, it is not automatically the 'right' solution in every case. By the same token, Waterfall is not automatically wrong or bad. There are times when Waterfall is absolutely the best process for the situation at hand—when, for example, there is a strong product that is stable and will require few future changes, riding along on Waterfall is effective and efficient. Agile, too, has circumstances where it is the optimal choice. The problem comes when a 'right' solution gets applied in the wrong context—or when a mishmash combination of solutions conflict, undermine, and ultimately gridlock each other.
These are the situations we find when we get called into a company to rescue a stalled cloud migration.
The Culture Clash Conundrum
In software development, as in real world geopolitics, the worst problems happen when cultures clash.
The issue is not so dramatic in companies merging Waterfall and Agile practices. Despite some surface differences, there are many functional similarities that enable such a hybrid approach to work. Both share the very strong presence of product owners to decide what should be built.
In Waterfall, architects and managers are expected to understand the entire product with all its complexity, while teams need understand only the part they are specifically responsible for. Similarly, in Agile, each team only needs to understand the component of the product it is charged with delivering (which will create strong separation for that part from all other parts due to Conway's law). But in both cases, teams are still not really in charge of what they are building, only how to build what they have given to build.
Furthermore, both Agile and Waterfall require coordination across teams to deliver the separate parts together. The only difference is frequency, with Agile delivering much more frequently than in Waterfall. And while Waterfall teams are building a single monolith, Agile teams are effectively building a number of monoliths.
In a typical Agile organisation, the number of independent components is between three to 10, with one team—or sometimes two—working on each. This does mean that Agile teams can take three to 10 times more complexity on themselves compared to Waterfall teams, but they are all still building monoliths. So you can see how, in some ways, cultural differences between Waterfall and Agile are actually compatible.
The most common culture clash we find, when we are called in to help save an attempted Cloud Native migration gone wrong, is where a company has tried to add one element of Cloud Native while not changing anything else. ('We will keep delivering software the same way we always have, except now we will have DevOps!')
Can you do DevOps in a Waterfall organisation? Sure. On the Dev side, you can apply Cloud Native practices to optimise and accelerate your development process. Meanwhile, on the Ops side (remember our platform team?) you can automate deployment to make your provisioning and infrastructure faster and more efficient than ever before. This is all great . . . except for the fact that your beautiful containerised microservices and their state-of-the-art platform won’t actually get in front of users until the next release cycle is completed, many months from now. Yes, you are doing Cloud Native right—from inside Waterfall. All that speed and efficiency? Simply wasted.
(You are also failing to capitalise upon the abundant Cloud Native open source ecosystem of tools. One powerful advantage of Cloud Native is that we externalise development costs to the community. If you don’t update your stack, or try to update only one isolated component, you lose this advantage).
The culture clash conundrum works backwards, too: You can’t have otherwise full-on Cloud Native culture but not have microservices. If it takes you six months to deliver, you can’t be truly distributed. There is nothing to be gained in simply recreating a monolith on the cloud—yet companies do it all the time.
Which Brings Us Back to . . . Culture
This is why understanding your own organisational culture is critical for functioning well in the world—i.e., succeeding as a business. Knowing your culture means being able to choose the path that best fits your organisation . . . or not choosing some hot new tech that, however promising, conflicts with your organisation’s fundamental nature.
Cultural awareness also grants the ability to start changing your organisation from within, by a myriad of small steps all leading in the same direction. This allows you to evolve gradually and naturally alongside a rapidly changing world. 'Long-term direction' is literally the definition of strategy. So small steps towards this direction are strategic steps. It’s a myth that strategy is 'big'. Egos are big. Strategy is setting a long-term direction and taken steps on that direction.
So: Your culture is the sum of the practices that add up to and define how you function. You can identify these forces that shape your organisation so fundamentally by examining the actions that define your day-to-day operation. Then you can decide the best next steps. This is far from new advice. Long, long before Cloud Native, Confucian philosophy advised us that, in order to slowly change one action over time, you must first change yourself—and then those around you.
Really it all comes down to two simple words: Know Thyself.
Previous article
