What Enterprises Can Learn About Cloud Adoption from Project JEDI | Blog
Enterprises must consider many different factors when building their cloud adoption strategy. It’s not easy, but the decisions are critically important. Learning the smart – and not so smart – choices other organizations have made can be enormously valuable. Project JEDI is an example of what not to do.
The background
In 2018, the U.S. Department of Defense (DoD) launched the Joint Enterprise Defense Infrastructure (JEDI) project to accelerate its adoption of cloud architecture and services. The contract was written to award the US$10 billion deal to a single commercial provider to build a cloud computing platform that supports weapons systems and classified data storage. With this ambitious project, the Pentagon intends to drive full-scale implementations and better return on investment on next-generation technologies including AI, IoT, and machine learning.
Here are key learnings from Project JEDI that enterprises should take very seriously.
1. Not to do: Pick a single cloud provider without evaluating others
To do: Explore a multi-hybrid cloud model
The JEDI contract’s fundamental issue arose from the fact that it considered a single cloud provider to chart out its entire cloud strategy. This caused great stakeholder dissonance, in large part because alignment with just one provider could result in losing out on ongoing innovation from other providers.
Because a single cloud strategy offers advantages including lower upfront cost and streamlined systems, enterprises often adopt this approach. But a multi-hybrid architecture allows them to tap into the best of multiple providers’ capabilities and stay ahead on the technology curve.
A well-planned multi-hybrid cloud strategy offers the following benefits:
2. Not to do: Ignore open cloud options
To do: Consider application interoperability and portability in cloud design
Project JEDI is completely dependent on a single cloud model, which exposes it to significant lock-in risks such as threat to transfer of data, application, or infrastructure. All of these can have a lasting negative impact on business continuity.
An open cloud model allows application interoperability and portability, and saves enterprises from vendor lock-in. Enterprises should be open to exploring open source or open design technologies for cloud. They should also consider implementing DevOps tools, container technology, and configuration management tools, as they will allow them to deploy their applications to diverse IT environments. All these options reduce the lock-in risks that stem from proprietary configurations, and enable organizations to easily, and with minimal technical costs, switch between providers based on business objectives.
3. Not to do: Be biased towards an incumbent
To do: Evaluate cloud vendors by aligning the service portfolio to workload requirements
The Pentagon recently awarded the JEDI contract to Microsoft. However, in the initial stages, the project garnered massive attention for its alleged preference to Amazon Web Services (AWS,) which has been involved in multiple government contracts for providing cloud support. Critics of the contract cited that an alleged unfair relationship between DoD employees and AWS would lead to inherent bias and rigged competitive bidding.
While existing relationships are important and can deliver strong value, enterprises should carefully evaluate their vendor portfolio against their workload needs. In most cases, a combination of different vendors will provide the most optimum solution. For example, Java workloads are known to work best with AWS, .NET workloads work best with Microsoft Azure, and Google Cloud Platform (GCP) is most suited for analytics workloads.
4. Not to do: Lose sight of stakeholders while moving ahead
To do: Have all stakeholders on board
A wide range of stakeholders are involved in selecting a cloud provider, and each of their needs, interests, and pre-existing biases must be addressed to avoid project derailment. For example, President Trump’s distaste for Amazon is cited as the prime reason that the JEDI project was awarded to Microsoft rather than AWS.
One of cloud project leaders’ most critical responsibilities is identifying and understanding stakeholders’ vendor biases and bringing them into alignment with business objectives if the biases are based on something other than facts.
The DoD’s approach to Project JEDI led to a prolonged delay in its aspirations in adopting cloud architecture and services and developing leading cloud-based AI capabilities. Avoiding the DOD’s missteps will help enterprises more quickly shape and secure a cloud-based contract that satisfies all stakeholders and supports their organizations’ business agenda.
What are your thoughts around the JEDI case and what enterprises can learn not to do, and to do, from it? Please share your thoughts with us at [email protected] and [email protected].
For example, under the NHS’s RightCare initiative, the NHS may look to accelerate the adoption of value-based care. Funding is focused on allocative value (how well assets are distributed to different areas of healthcare), technical value (how well resources are used to achieve valid outcomes), and personalized value (determined by how well an outcome matches patient expectation). Additionally, with increasing demand for telemedicine, NHS trusts will be on the lookout for providers that develop mobile applications aimed at remote healthcare management to support the growing importance of care at home for chronic conditions.