This is the first part in a series profiling “the journey” to becoming a cloud-native enterprise. It starts the series by explaining the goal of the journey and describing the three most common types of Pivotal Cloud Foundry customers that undertake the journey Greenfield Development, Legacy Management, and full on IT Transformation.
Editor’s Note: Be sure to check out the rest of this series and other posts on the Cloud-Native Journey including the Greenfield Journey (Part 2), Legacy Journey (Part 3), and the Meatware (People & Culture) Journey (Part 4).
So, How Does One Eat The World With Software?
Most of our customers are looking to becoming a cloud-native enterprise. This has given us the chance to observe how numerous enterprises are transforming and how they use custom written software to run their business.
Each of them is responding to the need to become a software defined business—the pressure from “Silicon Valley” to use agility, cloud, data, and devices to disrupt how business is done. Those pressures are well covered elsewhere, and I wanted to start collecting the highlights of how these companies have been changing and what they’re doing. This concept is often called the “journey,” which is a euphemism for “it takes a lot of hard work and time—you won’t just succeed overnight.” Similarly, building your own home or raising children is a “journey.” There are no easy answers, things “go wrong” often, but setting up a process that continually learns and improves is what ends up addressing the problems, resulting in custom built houses and functioning adults.
So, this article begins to explain what customers of Pivotal Cloud Foundry have been doing to make sure their kids stay out of jail. First, we’ll briefly discuss the goal—the reason companies are looking to become cloud-native enterprises. Second, we’ll look at the three types of organizations we often encounter and how they’re crafting their cloud-native strategies. In future articles within the series, we’ll look at technical and architectural concerns that arise, how those concerns are addressed, and many other aspects of the cloud-native journey. My hope is that you can use this overview to understand why the “journey” matters, what it looks like and how to start planning for the journey to becoming a cloud-native enterprise.
The Goal: Shorter Cycles To Increase Quality And Grow The Business
Our customers want to use Pivotal Cloud Foundry to improve how IT is used within their organization. To run and improve their business and their customer experience, they must become really good at writing and managing their own software. To do this, they are looking to improve the quality of the software life-cycle—from thinking of a new idea to developing it to running it in production. Their goal is to think of a new software idea on Monday and have it running in production by Friday.
I like to reduce the goal down to speeding up the software delivery cycle, as shown in a diagram I use a lot:
Your goal is to make moving code through that pipeline, safely and reliably, as quick as possible. A good goal is every week, but, if you can master small batches and put in all the process and technology rigging needed, you should shoot for daily deployments.
This is the goal to keep in mind as the short and medium term goal for your organization—reducing the full cycle time it takes to get new features into production. The long term goal is to improve not only the quality of your software delivery process, but the quality of your business.
But, first, you need to get your software delivery process in order.
Check-in To See What Situation Your Situation Is In
As mentioned, we see three types of organizations embark on this journey. To get started, your company must know where it is with respect to capabilities and obligations. By knowing the current state, you understand where you are starting the journey, and it helps you determine the next steps and the problems you will likely encounter. Ultimately, it guides your strategy.
To date, I use these three buckets to describe the types of companies—Greenfield, Legacy Management, and IT Transformation.
These groups have very little existing IT process or staff to work with. Some might say, to deal with. They’re given freedom to do anything they want and are often starting from nothing. Most of these companies are smaller, but sometimes they’re a team at a large company that is given the freedom to completely ignore everything and start fresh—a regular skunk-works situation.
They want a platform for developing net-new applications and have little concern about integrating with or managing existing applications. This is a fun group. Their challenge with using Pivotal Cloud Foundry (or any cloud platform!) is that they get excited about building their own custom built platform instead. They resist the need to delegate infrastructure management and cloud orchestration concerns to the cloud platform.
And why not? These teams like building software, but building their own cloud platform tends to trap the team into becoming cloud platform builders. Instead of building the business applications their organization needs, they spend much of their time and money re-inventing an existing wheel. These teams are often focused on “day one” problems (building and finally deploying the first version of the application), and they put off the tediousness of “day two” problems (managing the application in production, ensuring that it’s easy to update as needed, and providing enterprise governance and controls if they’re stricken with that kind maturity).
To me, the challenges here are all about establishing a process of moving fast without building up too much technical debt. Teams must also realize that they’re being tracked and closely monitored for their success. They need to “market” themselves appropriately. If these initial greenfield projects work, the rest of the organization will likely want to replicate the efforts. If the efforts fail, the thinking behind these projects will be quietly swept under the rug.
These groups have a full portfolio of existing IT applications to maintain and grow. There are many “obligations” owed to the past, and they often operate under many more constraints than the other two types of teams. Their challenge with switching to a cloud-native approach is planning out how to methodically “slice off” parts of their existing applications and re-platform them as cloud-native applications. These teams are metaphorically tasked with rebuilding the jet engine mid-flight.
These legacy teams are often looking for fixes to lingering, systematic problems they have (the relational database can no longer scale) and the effects of too much technical debt (“our system is so burdened and fragile that it takes weeks to do a release”). These teams have a challenge—all of their time is taken up simply keeping applications up and running. This leaves little time to work on new functionality. Worse, when there is time to add in new functionality, the legacy system is so ponderous (and often poorly understood) that change takes much longer than it should.
To me, the challenges here are about risk management—knowing when to keep doing “the wrong thing” despite the allure of “the new thing.” Eventually, these teams have to choose either to “give up” or “go for it.” If the risks of making changes are too high, they must quarantine the applications in question. Or, if the risks seem acceptable, the teams have to start systematically re-platforming and re-writing the backing services and applications themselves.
Somewhere between greenfield and legacy, there are groups tasked with actively changing how IT is done at their company. These teams are often driven from the top-down and own the entire application portfolio at their organizations. They’re responsible, at a portfolio level, for building new applications and also maintaining existing ones. What makes them different than just a combination of greenfield and legacy teams? They are actively looking to convert most everything over to the new platform, not just keep the old things up and running or let greenfield applications run without any constraints. They want a common, shared platform for doing everything. I think of CoreLogic as the earliest, most representative Pivotal customer here, but as you can imagine, most Pivotal Cloud Foundry customers are looking at this path to meet their goals.
These teams want a common platform and product development philosophy for all of their applications. They are, indeed, on a long, multi-year journey to move everything, new and old, to that platform. The challenges they face reflect this. First, they have to “rein in” the new application developers and have them develop on the standard platform rather than using whatever they like. Second, they have to push the legacy teams to be more aggressive in changing the architecture of legacy applications. Sometimes, they need to retire legacy applications entirely, completely rewriting them. To me, the challenges here are all about change management for the application portfolio. This is the hardest thing an IT department does. However, this bucket has the largest payoff—naturally, because it’s going after everything.
As you might be thinking, most Pivotal customers are in all three buckets. My recommendation is to start with a greenfield project to just figure it all out. Because Pivotal Cloud Foundry is truly multi-cloud, you can start in our public instance Pivotal Web Services and move to your own dedicated hosting or even on-premises if you want. That is, there’s no technical reason (like having to build your own cloud) that would hold you back from starting and deploying on day one. Again, you can start with our on-demand platform today, deploy to your own single-tenant version in AWS tomorrow, and decide later when to set up and push it to an internal cloud platform. And when it comes to the actual Cloud -Native application development, we also have something to offer in the form of Pivotal Labs where we’ve been working directly with companies for many years to help transform how they do software development, literally pair programming and growing skills together, not just outsourcing coding over the wall.
As you can see, we’ve been learning a lot over the years, especially in the past twelve months where we’ve had record growth in new customers and usage. This article, the first of a series on “the journey,” explains the goal of the journey and the three common types of customers we see. In the next few parts, I’ll spend time detailing different strategic and operational tactics for the three types of journeys, and I’ll also look at some of the higher-level technical changes that Pivotal Cloud Foundry customers are doing to be successful. At the end, I’m hoping you’ll get a sense for what it looks like to be a Cloud-Native Enterprise.
Also, rather than batch-up all this writing into a big release (sound familiar?), I wanted to get the content out as soon as possible to start getting feedback and input. It’d be great to hear how things are going for you and even the questions you don’t know answers to. Please use the comment field below! (Of course, our very own Matt Stine has a done a good job profiling many of the answers in the free book we have on migrating to cloud-native architectures, so that’s a good start in the meantime.)
- Check out the rest of this series: Greenfield Journey (Part 2), Legacy Journey (Part 3), and the Meatware (People & Culture) Journey (Part 4)
- Find out more about Pivotal Cloud Foundry: Product Info | Blog Articles | Podcast
- Read our post-OSCON perspective on the The Cloud Native Journey
- Watch our CF Summit Keynote: Welcome to the Cloud Native Enterprise
- Get the Book: Migrating to Cloud Native Application Architectures
About the Author