The Importance of Application Delivery Standardization in the Cloud


This article was originally published in The Doppler by Cloud Technology Partners.

No plan survives first contact.” During my days as a young soldier, my platoon sergeant barked these words incessantly – imploring his troops to prepare for situations as if their lives were on the line. His message got through. We planned things out painstakingly, moving plastic soldiers and Tonka trucks around a small sand table. Then we rehearsed the maneuvers over and over, and before long, we could do them in our sleep.

The sergeant’s slogan applies just as well to the technology battlefield as it does to the military one. Technology project plans do not need to be rigidly orchestrated right down to the final detail. But they do need to be thought through, tested and rehearsed before they make first contact with the marketplace.

Application delivery standards and strategies set frameworks for the successful releases of products or services. These key components cannot be assembled at the last minute. They need to be defined by the technology organization well before a project is initiated, and need to be based on a technology strategy that is focused on delivering business value.

Cloud projects, of course, require extensive planning. Whether you are migrating legacy applications to the cloud or building new cloud applications from scratch, you need to develop a technology delivery strategy that establishes the application development framework, project cadence and production standards. These standards serve as the foundation for the application, but they need to be flexible enough to avoid being a barrier to team agility. Determining these standards once you are in development, which is often the case, only increases the risk of the plan not surviving initial customer contact or release.

The Pros and Cons

What are the benefits of coming to the table with a well-organized plan? Essentially, you can prepare for unforeseen ambushes – which, yes, usually happen. You can mitigate cost overruns. You can ease the workload of developers by allowing them to focus on building good code rather than carrying the technical burden of establishing/deciding infrastructure and operational standards. You can develop team cohesion among technology leaders, operations and delivery groups. You can shorten build-to-market timelines, since application development standards are well established before project kickoff. And by implementing standards and toolsets across technology teams, you can reduce frustrations, freeing up teams to more easily incorporate new talent to their product group.

The drawbacks to not entering a battle with a well-developed plan are clear. When a development team, rather than the technology organization, establishes the application delivery foundation during development, the developers find themselves combating two types of bugs during testing: application code bugs and bugs with development/operational tools. In addition to debugging code, since this is the first time the team is using these tools is during the project build, they are also debugging production pipelines, or logging and monitoring tools. This can result in increased application delivery time and project scope creep, developer frustration and siloed solutions and decisions on application delivery standards.

To execute a successful technology project, you need to have a plan and execute it. You have to do three things:

  • Build the right tech team for implementation
  • Establish your organizational plan for the tools and the development process you are going to use
  • Identify your operational and maintenance plan

Build the Right Tech Team for Your Implementation

Application delivery teams should focus more on the product than the project. At project kickoff, rather than assembling delivery teams from various parts of the enterprise, the organization should assign project teams as subsets of their original product delivery teams. This ensures team cohesion and a unified overall project vision for a product as the delivery team is already familiar with the product’s nuances.

The business level also needs to define a series of stakeholders, including the following:

  • Product managers who are part of business leadership. They set the project vision, sell that vision to C-suite, make the business case and cross collaborate with sales. Each product manager works with product owners across delivery teams to ensure that requirements and user stories are developed. The manager also prioritizes when business feature sets will be delivered and keeps a finger on the pulse of parallel developments and releases.
  • Enterprise architects who ensure organizational design standards are implemented and acted on during delivery.
  • Product owners who write and prioritize user stories for the development teams, based on business unit requirements.
  • Project managers who track the progress of feature sets against the product roadmap and manage the dashboard/product delivery metrics.

The technology level, as well, has several key stakeholders:

  • The agile delivery team, consisting of a software delivery manager, software engineering team and a test engineering component.
  • A scrum master who tracks the progress of development against the sprint roadmap/plan and manages agile dashboards and technical delivery metrics.
  • The technical or solution architect who coordinates with the enterprise architect to develop designs that align with the enterprise architecture design.
  • The site reliability engineering team.

Plan Out the Tools and Processes You Are Going to Use

Establishing tool standards for application development ensures that development teams are not implementing toolsets in silos which have not been vetted by the technology organization. Tool standards also ensure there is broader organizational knowledge of the toolset as subject matter expertise is spread throughout the technology groups. Be sure to decide on these tool standards before the application delivery piece is done.

The technology organization level includes three basic components, starting with infrastructure. To set up this component, organizations need to answer a series of basic questions. Are you cloud native, on-premises or hybrid? If you are going to go all cloud, what cloud, and under which criteria will you select a cloud vendor? What are the scenarios that would make you choose PaaS, SaaS or IaaS? If you are making a commitment to infrastructure as code (IaC), will you use a tool such as Terraform, or cloud native tools such as AWS CloudFormation?

App delivery principals need to: decide which languages are used for development and why; define a “done” development as one that has been thoroughly tested and is ready for release; and consider the adoption of Twelve-Factor App methodology. They need to look at production pipelines (what is manual versus automated?), and, if they are making a commitment to DevOps, decide whether that means standardizing on CI/CD. What tools will they use to track the development/testing tasks and bugs? And how will requirements be tracked, maintained and groomed?

For planning roadmap standards, issues to consider include: defining stakeholder communication and engagement intervals; scheduling production and deployment rehearsals before release to simulate go live; iterative delivery milestones where customers can “touch” the product feature sets as they are built; and internal end-to-end testing before customer end-to-end testing and full product go live.

Identify Your Operational and Maintenance Plan

Start with the end in mind. In addition to customer satisfaction, the end to strive for should be a product that is easily maintained in an operational environment. Do not reinvent the wheel about how you are going to transition into operation. There should be a transition plan to use for every application delivery, which can then be tweaked for particular projects. For example, before runbooks are created, and well before the product is live, application ownership for production and maintenance should be established. The operational readiness plan should include security standards and ensure that alerting and monitoring standards are established and incorporated as tasks in epics that are completed during development, not after. There should be requirements to test operational tools prior to their release as milestones in the development plan. And documentation should be in place, establishing standards for knowledge transfer and tracking tools/update cycles.


Proper planning, as described in this article, for a product’s first contact starts well before the project is budgeted. Application development standards should be part of any technology organization’s strategy. This is not about risk removal, but rather risk reduction. Though technology plans may not survive first contact, they will give organizations clarity and at least reduce the number of fires that could be raging at any given time.

Published on December 11, 2019

Starr Corbin is the Founding Partner of Corbin Solutions Group. Follow her on LinkedIn and Twitter @StarrCorbin.

%d bloggers like this: