Forklift All The Legacy Apps You Want, But Don’t Forklift Process!
A large organization “going cloud” will quickly confront what to do with all its legacy applications. The cloud native development style has several requirements and conventions—a “contract,” if you will, as outlined by 12 factor app principals and a microservices approach that conflicts with “traditional” practices like using local storage, embedding configuration in applications, following a monolithic architecture, relying on networking outside of HTTP, and so on.
When sorting out your application portfolio, you’ll find applications that are overly obstinate about moving: either it’s technologically not feasible or it doesn’t make business sense. After you’ve screened for these apps, you’ll have a bucket of hopeful left-overs. There are methods for massaging these differences out in the code and packaging to make moving applications to a cloud platform like Pivotal Cloud Foundry not (too much of) a problem.
Put your meatware up on the wall, check it out for a while
Moving existing applications like this is often called “forklifting” and we’ve seen many of our customers do it successfully alongside net new application development. But, as you’re migrating legacy applications, be very mindful of accidentally forklifting your process. You don’t want to ruin your new, pristine, cloud native program by marbling your software and hardware with rotting meatware.
Keep in mind that the goal of your cloud native transformation is to start innovating faster, doing so with a small batches mindset, while relying on a cloud platform to cut as much waste out of your overall “software factory” as possible. Most of the waste will be in the “meatware,” and if you just forklift your process and organizational structure from your legacy organization, you’ll likely see a quick plateauing in the benefits of the cloud native approach. Indeed, most surveys checking in on digital transformation find that people, not technology, are the biggest barriers to full ROI:
The top of the stack has to change just as much
Changing over to a small batch mindset at scale requires management to mindfully explore, implement, test, and analyze new processes and structures. This means that management’s job now is to change management, not just checking in on statuses, or even at best, which is setting goals. Sure, any half-competent manager would rightly say they do much more: but those activities (along with occasionally laying off and rewarding people) are about all that any individual sees managers doing in traditional organizations. We’re used to thinking of IT as a drop-in, or a fix-something tool that you can just forklift in to solve a problem. So it’s little wonder that the “upper levels” don’t realize that they too need to change what they’re doing and how they’re doing it, to get full ROI on their cloud native investments.
I’ve written about what these changes are and there’s plenty more to say about which behaviors to start imbuing into your organization. The point here is to avoid thinking you can simply forklift everything over. Some applications, sure, but be mindful of your “legacy” process, mindset, and overall organizational culture.
Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced and incorporated continuously through development and innovation, because good software is never finished.
