Juergen Sussner is a Senior Cloud Platform Engineer & Evangelist at Datev eG. Christoph Villnow is a Senior IT Architect at Unique Projects. Both are based in Germany and are active members of the VMware Tanzu Vanguard community. You can read more insights from them here: “Kubernetes as a New Standard for Infrastructure Management.”
A lot resonated with us when we read this recent post on the VMware Tanzu blog, “Three Transformations Powering App Modernization.” At a high level, it captures the trends we’re seeing in our respective day-to-day experiences working within a large enterprise and working with clients that are trying to modernize their IT organizations. It is absolutely true that shifts in infrastructure, application architecture (largely microservices), and roles and responsibilities (DevSecOps, for example) have made application modernization in 2021 a more real—and more compelling—proposition than at any point in decades.
As the old saying goes, however, the devil is in the details. In this post, we run through some of our experiences carrying out modernization efforts. We also offer advice for how to do it successfully, in particular how to avoid the traps that exist any time a major change requires buy-in at all levels of an organization.
Juergen Sussner: People and process matter as much as technology
When I think about modernization from a customer’s point of view—my story in particular—my organization began its infrastructure transformation by transitioning our data center technology into self-service mode. We simply wanted to “get out of the developer’s way,” to not be an obstacle to the process of delivering software. But this was not as easy as just letting developers take ownership of their applications all the way from the local machine to production.
Why? Because modernization entails a lot of soft skills, such as communication and advertising, to sell the concept. That was the first missing element. It’s like the movie The Shawshank Redemption: When Brookes was released from prison after decades, he was lost and not sure what to do; he could not find his way in what for him was the new world. Neither, it turned out, could some of our developers. Some of them even asked for the old regulations and limits to be reinstated. The process of learning DevOps, believe it or not, is still ongoing.
In terms of the applications themselves, modernization is necessary to be able to iterate and deliver faster. In order to execute a modernization strategy, you need to tear down monoliths and transform them into apps with bounded contexts. I try not to use the term “microservices” because it implies that a service is as small as possible, which may not always be the case. Instead, I refer to “apps with bounded contexts,” as this means an app can be developed and operated by a single team. Whatever you call applications, modernizing them is a long-term process, because you cannot stop delivering features for customers while you rewrite the whole application landscape into more manageable pieces.
After transforming all the infrastructure, responsibility, and architectures, you still need to address the most critical part: the company’s structure. It can be difficult to successfully execute modernization when the company structure remains stagnant and there are, for example, separate operations and development departments with differing goals. What’s required is that the organization—from the top down—accept and adopt these new transformations and its leaders take an active role in ensuring they are widely deployed and adopted. This organizational transformation not only affects the teams operating and developing software and data centers; it also affects every level of management.
You know you are on the path to successful change when transformation happens across all of those levels. I often reference the Inverse Conway Maneuver, which I read about on Saurav Omar’s blog. Conway’s Law states that “organizations [that] design systems … are constrained to produce designs [that] are copies of the communication structures of these organizations.” The Inverse Conway Maneuver is about looking at the system and deciding how it should behave in order to create the structure for the teams around it. By doing this, the whole transformation is neither a one-shot task nor a project that has a defined goal—it’s an ongoing change in the way organizations work.
Christoph Villnow: Keeping up with the pace of change requires effort
From a service provider point of view, the process chain in which applications are designed and created is going through a major change. In fact, it has been almost entirely re-created over just the last several years, although that transformation is not yet complete. As it solidifies into something resembling a modern application lifecycle, however, many organizations are still trying to overcome their inertia and catch up.
A few months back, I was chatting with a colleague of mine about job titles and related areas of responsibility—more precisely, about all the new titles that have surfaced in the last few years. These are titles nobody had heard of before, and only a relatively few organizations really know where to fit them into their structures. Google Trends highlights just how quickly technologies and their related job titles and responsibilities can arise, which for many organizations is much faster than they’re able to evolve without some serious assistance.
The emergence of DevOps
The emergence of “cloud engineer”
The emergence of Kubernetes
Today, it’s commonly understood that most of these roles and capabilities are necessary—even if they haven’t yet been staffed—and that there will be many more to come. DevSecOps is one capability for which organizations will need to begin hiring, but there will also be many more needed to fill in between the lines of the cloud native stack. In the end, organizations will need a team of professionals with different experience and skill sets combining their powers to drive the transformation forward.
As this happens, organizations and their leaders will need to adopt new workflows and rethink old behaviors. There are two common responses I get when I’m meeting with customers and talking about how to adopt new technologies. One is to complain about how the executive level isn’t up to speed on any of these possibilities, never mind how they would improve their company’s ability to respond to new requirements. This disconnect leads to uncomfortable discussions about future projects. The other response is that people are happy to speak with their leaders and stakeholders because they understand certain aspects of these technologies and the discussions around them. Most of the time, this common understanding results in a more technology-driven outcome.
This need to adapt and rethink also applies to infrastructure transformation, which, while it can be easier to conceptualize, remains on ever-changing ground. As an infrastructure architect, I know how hard it was to talk about cloud with customers and executives. Today, however, the possibilities for implementing cloud resources, and the simplicity of obtaining them, make clear that rethinking resource management improves productivity. Those benefits, as well as the impact on the day-to-day business of many organizations, has drastically changed the ways people think about the cloud. VMware’s various options for running existing workloads on public clouds make it even easier to sell the benefits of cloud computing because organizations don’t have to wholly refactor applications or rip and replace technologies that still work in order to reap its benefits.
I think the next step is getting everyone from developers to executives up to speed on current technologies and trends up the stack—Kubernetes, DevSecOps, and microservices, to name a few. Once organizations embrace the concepts, get the right pieces in place, and hire for the right roles, they will reap numerous benefits. The organizations that take advantage of these shifts today will be much better positioned to keep up with whatever comes next tomorrow.
