This is the second part in a series profiling “the journey” to become a Cloud Native enterprise. In the first part, I gave a brief overview of the types of journeys we tend to see—greenfield, legacy, and transformation. While all journey types intermix, this part goes over greenfield journey, its top goals, and ten factors that can help companies and teams achieve success.
Editor’s Note: Be sure to check out the rest of this series and other posts on the Cloud Native Journey including the Welcome To Your Cloud Native Journey (Part 1), Legacy Journey (Part 3), and the Meatware (People & Culture) Journey (Part 4).
What’s a Greenfield?
When I think of “greenfield,” it describes application development projects that have little, if any, connection to existing systems. Unlike “legacy” situations (which we will cover in another part), there is no existing code to evolve into the next release. The product team has the thrills of blankness in front of them—a blank white-board to start planning, blank post it notes to start tracking requirements and stories, and blank screens waiting to be filled with code.
In many ways, this is the dream situation. Developers have little in the way of constraints and no technical debt. We read the most about these types of projects, but, as any one who regularly talks with “enterprises” will tell you, it is the least common in the field.
Some of the ideas here will apply to all types of cloud journeys (like having full test coverage), but I’ve pulled them together here because they are particularly applicable to greenfield projects.
The Three Strategic Goals of Greenfield Projects
Before I get into some general advice for greenfield projects, let’s go over their goals. The overall goal is to deliver a product, but we need to think beyond that. You need to think forward to what you do after the greenfield journey. How can you ensure that your greenfield work helps improve and transform the whole company over time? In that “what’s next?” sense, the goals of doing greenfield projects are:
- Earn trust by showing success—Pick an appropriate, valuable, and low risk project to experiment on and learn from. It will be hard to continue expand into larger transformation work if you fail.
- Establish a continuous delivery pipeline and cloud platform—These will be some of the core technology assets you will re-use after your greenfield experiences. Once setup, they will enable you to release smaller batches of code on a more frequent basis—one of main operating points on the Cloud Native style.
- Learn by doing and educate the rest of the organization—Much of your work is the hard task of learning a new way of planning, managing, working, and interacting with customers. “Culture,” as the kids call it, ain’t easy.
If you can achieve these three goals, you will get to move onto to the next journeys.
1. Get Your Head Straight & Set Realistic Expectations
Using Cloud Native technologies is the simple part—changing how your organization uses those technologies is the hard, grueling part. Give yourself the space to learn, fail, learn, fail, and start succeeding. Doing this with a large project is dangerous and not required. Start with a small project and grow from there. Overly ambitious, amateur knife throwers get cut a lot, or worse, tend to impale others while learning.
While the benefits of a Cloud Native approach are wondrous—innovate new features and beat the competition with the power of deploying software safely multiple times a day! It takes work to get there. Plan out a few quarters. Allocate resources to the greenfield project, but stay conscious of the fact that you’re learning. Set expectations for everyone, including upper management, that things will not go perfectly at first.
2. Selecting Your First Projects
If you’re a small team, or a small company, selecting the project to work on is likely easy. You probably just have one application, so select that! In larger companies, there are often 100’s, if not 1,000’s of application and projects to pick from. Pick one with direct value to customers—one where you will get feedback once you deploy it (i.e. people will use it a lot, it won’t just be shelf-ware). You also want to pick a small enough project so it can get into production in a short amount of time, let’s say 3 months at most. Finally, if things go poorly, you want it to be a somewhat low profile project so you can sweep it under the rug.
This last point is no doubt contentious to the purer minded of y’all out there, and I can sympathize. We should strive for truth and transparency! I’m sure you’re lucky enough to be in a corporate structure that rewards the value of failing (read—learning), but think about your peers. Many are not so lucky and work in caustic corporate cultures that punish any type of failure by “promoting” the former VP of “Having a P&L” to VP of “Special Projects.” In such environments, you’re given the chance to advance to the next place on the board by success. So, you will want to pick projects accordingly. Of course, “failing fast” should help you change said caustic corporate culture around…hopefully. While a bit dated, the 2010 booklet, The Concise Executive Guide to Agile has helpful details for picking your initial projects.
Alternatively, there’s another project type to choose—what I like to think of as a “moribund” project. It fits all the criteria above but already exists and just needs to be shown some love. One of our customers, Humana, did this. Their Vitality project wasn’t getting the engagement levels they wanted—just 3% of potential users. They wanted to triple engagement. As they detailed in their keynote at this year’s CF Summit, they increased engagement to over 30% after reviving it with a more agile and Cloud Native approach. This success was parlayed into two other, small-but-important projects and the company is now on the path to transform how applications are delivered company wide.
3. Staffing the Project
Team organization is a big change with Cloud Native approaches. It’s easy to dismiss the funny-sounding talk of “two pizza teams” that Cloud Native pioneers like Amazon have recommended for so many years, but the sizing and composition of the product teams is critical.
Not only do you want to keep teams small—somewhere between 6 and 12 people—but you want them to have all the skills needed to for the full life-cycle of the product, including development, testing, design, and operations. Keep in mind—this team size will be possible because the infrastructure provisioning, configuration, and ongoing management will be powered by a highly automated cloud platform.
The team needs to be dedicated to the project, full time. For many companies, this is a hard pill to swallow. Everyone is so busy with various projects that they can’t be dedicated to just one thing! Well, if operating in that way is getting you the delivery speeds, product quality, and uptime you think you should be having, perhaps there’s no need to read on—sounds like you have it all figured out! To put it more gently, dramatic, Cloud Native results require some dramatic changes. Dedicating a small, skilled team is key, and it works.
To cite one of many examples from Pivotal’s customer-base, CoreLogic has proven that this mentality gets proven results:
When planning the first product developed on Pivotal Cloud Foundry, CoreLogic allocated a team of 12 engineers with four quality assurance software engineers and a management team. The goal was to deliver the product in 14 months. Instead, the project ultimately required only a product manager, one user experience designer and six engineers who delivered the desired product in just six months.
The other “people concern” is assigning one individual as the key stakeholder in charge of the project. At this stage, you will need someone who can be decisive and cast the deciding vote on any given decision to keep things moving. If you’re moving from a culture where people are used to being told exactly what to do (most corporate cultures, I’d argue), without a definitive person in control, people will fall back to their “bad behavior” of doing nothing when there are not clear directions. Thus, if there’s not an individual who has ultimate responsibility, you’re likely to see lax discipline and attention to roadmaps. As you move into the later stages of going Cloud Native, your organization will take on more and more shared responsibility driven by clear goals from management across departments, but, in the greenfield stage, it’s good to ensure that everything is going well by assigning an individual to that role.
4. Use This Chance to Change Your Process
Many large companies are looking to do Cloud Native development, but they are not following best practices for agile development, continuous delivery, and DevOps. Indeed, a recent Institute for the Future study of 3,600 business leaders showed how only 25% of respondents felt their companies were agile enough. This of course leads to a declining value of IT to business. Read: not good if you’re IT in these software eating the world days!
So, if you’re lucky enough to take a fresh start, be as strict about adopting agile practices as possible. They are best practices because they work. Start by defining a weekly release cadence, using whichever variant of agile works for you, practice open, shared project management (likely with a Kanban-inspired tool like Pivotal Tracker), automate as much as possible, and, most importantly, follow the continuous learning loop of trying something new for a short time and evaluating if it’s working or not. Psychologically, large organizations tend to view “process interrogation” as a sign of management weakness. This couldn’t be further from the truth! High performing IT departments are continually studying, tweaking, and learning how their process works. Low performing IT departments are rigid and never question process.
To that end, we recommend learning through immersion, for example, by working with Pivotal Labs. We can thoroughly soak a team in agile product development, and many customers rely on introducing our culture to reinforce new development habits. There’s a wealth of information out there on this model, consume it and try it out. This is your chance to try something new if you’re in that 75% of people who feel like their organization is not agile enough.
5. Avoid Technical Debt with Strict Testing
Until you experience the effects of near 100% test coverage, it’s hard to appreciate the worth of all that work. Automated test coverage won’t solve all your problems, but it will definitely make it much easier to move fast, refactor your code, and add new functionality to your application. If it takes you days—if not weeks—to test changes, even just a line of code, you’re going to slow down your release process. Also, without tests, you’ll find it hard to make changes to your code. And, since you can’t quickly and accurately test changes, you’ll start to ignore older parts of your code base for fear of breaking functionality. This turns into a spiral of building up technical debt as more and more parts of your application are surrounded by signs that say “don’t touch!” Very quickly, you’ll be immobilized and unable to change your application’s behavior and add in seemingly simple changes. Thus, in a highly automated Cloud Native application lifecycle, you need the ability to quickly test nearly everything. As you’re starting with a new project, don’t cut corners by cutting down tests. Getting broad, accurate testing in place is key to moving fast and helps set an example for the future.
The recently published Leading the Transformation has helpful advice on figuring out the wicked problems of test coverage across different domains if you find yourself stuck. Also, keep in mind that the highly automated and speedy capabilities of a Cloud Native platform will also speed up your ability to test everything. In general, there’s little excuse to skimp on automated tests, and you’ll certainly damage your overall project agility if you do so.
6. Cloud Native Development: 12 Factor
With the benefits of that blank screen staring at you, you can start your application architecture and development in true, 100% Cloud Native style. In addition to enabling all of the deployment speed and operational benefits of a Cloud Native approach, a greenfield situation allows you to road-test new development styles. The guiding principles for development style are encapsulated in the 12 Factor App.
The 12 factors describe design principles that ensure your application will be Cloud Native. For example, you can’t depend on local storage, configuration should be injected into your application on-demand rather than shipping with it, and apps should be built as stateless processes, to name just a few. It’s important to hew closely to these principles because they form a sort of “contract” between the cloud platform and your application. If your application obeys the contract, it can be run and managed properly by the cloud platform.
7. Cloud Native Architecture: Microservices
Microservices are the other important development style consideration. This architectural style breaks down applications into as many, independent services as possible. It also focuses on the end goal of breaking process and technology dependencies between each service, making them stand-alone. These services could be things like displaying “you might also like” recommendations, storing a user’s profile information, or providing a service that queries your inventory system. The idea of decomposing your application into subsystems is not new; what’s new about microservices is the emphasis on how decoupled and small those services are not only technologically, but also with respect to people and process.
In the large view, a microservices exists and can evolve on it’s own. The development team responsible for it can use whatever technologies to implement it that they choose and can follow their own road-map. As with much Cloud Native thinking, this focuses on speeding up release velocity. The size of the service is, well, “micro.” Some joke that all the code for a good microservice should be about as tall as your head if held next to a screen. Others size it by how long it should take to re-write the service—3 to 5 days at most. The point is that to maintain agility, you need to keep each component independent and small enough to comprehend quickly and work with easily.
Taking a microservices approach is the right decision in the long term. In the short term, though, because of the drawbacks of microservices, it can be helpful to do your initial project with a more traditional, monolithic approach. This approach allows you to start learning-by-doing a little bit, and then ramp up for your second project. The larger the project, the more important microservices are for project stability and ensuring sustainable agility.
That said, many of the drawbacks of microservices are addressed in Pivotal Cloud Foundry. For example, if you’re developing in Java, the Spring Framework has a lot to offer that’s tightly integrated with Pivotal Cloud Foundry. Spring Boot can be used to create a self-service, microservices-oriented “tool store” for developers, while Spring Cloud can be used as the foundation for your microservices approach. Check out Matt Stine’s book on Cloud Native architectures for more detail.
8. Staff Growth and Retention by Participating in Your Ecosystem
Eventually, it may be hard to retain the key staff responsible for this transformation. With their track record, they will be highly sought after by competitors and technology companies. To abate this, it’s important to start “making stars” of these key staff members. It is actually easier than it seems. Just let them engage more publicly about what they’ve been doing.
While some employees will still end up leaving, many more will stay if you allow them to start contributing to open source projects and the ongoing conversation in the Cloud Native community. Equally important is finding new staff to fill your Cloud Native needs. By participating in activities, like open source projects and conference presentations, it’ll also help address recruiting needs. And, of course, getting more involved in open source will also get you closer to the code you use and, if you’re lucky, improve the quality of it. The point is, you want to become part of the overall community, which means participating as much as possible. Doing so will help tremendously with staffing.
9. Get a Platform, but Avoid Building Your Own Platform
The biggest greenfield project misstep and risk I generally see is succumbing to the urge to build your own, non-standard approach and cloud platform. What I mean by “cloud platform” is the system that manages everything from the infrastructure up, defines how applications are packaged and deployed, defines how services (like databases, identity, queues, etc.) are provided, and provides capabilities to run, monitor, and otherwise operate in production. And don’t forget that you’ll want the benefits of multi-cloud portability—to move your applications to whatever type of infrastructure you want—private, public, dedicated, “real” cloud, or just plain old virtualization.
Developers love to build all this on their own. It’s fun! But in the Cloud Native era, this akin to writing your own web server, or worse, operating system. Instead, you’ll want to save time by using a standardized cloud platform like Pivotal Cloud Foundry that’s geared to solve all these problems and let you focus on developing.
Many of our customers went down the route of building their own platform, relying on automation technologies and containers to create them. This works at first, but cuts off access to the continual stream of innovations you’ll get when using an open platform like Cloud Foundry. For example, once Netflix’s microservices stack emerged as a solid framework for cloud architecture, Pivotal added it into Pivotal Cloud Foundry. As negative example, one of our customers had built a cloud platform on their own that only supported Java, and their platform team could never seem to find the time to add other languages.
This last point is key as well. Are you in the business of building platforms or building the software that runs your business? You’re going to need a highly automated cloud platform that supports the entire application life-cycle—development, QA, staging, production—and that task is likely best left to a third party (or ecosystem). Using a cloud platform will also force you to follow architectural, Cloud Native discipline, like following the 12 factor app guidelines and breaking up your application into microservices. Remember, this stuff is proven to work, but if you deviate from the standard Cloud Native practices—your mileage may vary.
10. Mainstreaming the Greenfield, Internal Marketing
Finally, as you start demonstrating success with your greenfield projects, consider how you might help the rest of your company. First, you should do some internal communications with lunch-n-learns or even internal hackathons and summits. Go over the stories (good and bad, corporate culture permitting) of projects, explain the processes you’ve been doing, and hopefully create a conversation with other groups who would like to improve how they deliver software. We’ve seen Pivotal customers like Humana do this to start spreading company-wide improvement. And, indeed, an even larger step is to create dedicated “labs” teams, like Humana has done, to help spread the improvement.
Think back to the three goals above, and you will see why this internal marketing activity is valuable. It will help you build up support to keep going and also helps you spread the benefits of Cloud Native to the entire organization. It’s downright responsible and leadership-y, if that’s your thing.
What’s Next?
After incorporating these ideas, you’ll have hopefully succeeded at your greenfield projects and, equally important, have gotten your feet wet learning about the Cloud Native mode of operations or “life-style,” as we might say in a school of thought that loves to bandy about the word “culture.” The next task is to think larger, tackling larger applications which probably necessitate working with “legacy” code and services. This leads to an enterprise view of change, transforming the entire company into a software defined business. We’ll be covering this next in the this series.
In the meantime, I’d love to hear feedback about your Cloud Native journey and hear your. That’s, selfishly, the reason I’m writing these blog posts and I’m appreciative of the feedback all y’all have given so far.
Learn More
- Check out the rest of this series: Welcome To Your Cloud Native Journey—Part 1), 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
- Check out all the Pivotal blog posts, both technical and business oriented, on Cloud Native
About the Author
