• 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 develop-
ment 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 technol-
ogy organization. Tool standards also ensure there is
broader organizational knowledge of the toolset, since
subject matter expertise is spread throughout the technol-
ogy 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 scenar-
ios 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” devel-
opment as one that has been thoroughly tested and is
ready for release; and consider the adoption of Twelve-Fac-
tor 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 rehears-
als before release to simulate go live; iterative delivery mile-
stones 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 Mainte-
nance Plan
Start with the end in mind. In addition to customer satisfac-
tion, 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 oper-
ation. There should be a transition plan to use for every
application delivery, which can then be tweaked for partic-
ular 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 stan-
dards, 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.
Conclusion
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 organiza-
tions clarity and at least reduce the number of fires that
could be raging at any given time.
Starr Corbin is a Founding Partner at Corbin Solutions Group.
SUMMER 2019 | THE DOPPLER | 69