Assembling a Docker Enterprise PoC cross-functional team

As prescribed earlier, it is best to bring Docker Enterprise into an organization with a phased but agile crawl, walk, run approach. The agile part of the description comes from leveraging a backlog, where a prioritized list of phase-appropriate tasks is used to provide the building blocks to plan each phase. Furthermore, we sift and sort the priorities of the backlog items depending on each organization's unique needs and requirements. Docker, Inc's Professional Services (PS) team has developed a comprehensive and proprietary backlog to support their enterprise adoption methodology to support customer PoCs, pilot, and production journeys.

Throughout this book, we draw a parallel to Docker, Inc's phased, agile approach as validation of and an introduction to the approach. We therefore intend to introduce and support Docker's approach by presenting some sample paths and important concepts, but this book is not meant to be a substitute for the Docker PS team's experience or intellectual property. Please contact Docker, Inc. for more details and professional service assistance.

The main objective of a Docker Enterprise PoC is to share an initial experience with a small, cross-functional team in an enterprise. The PoC core team normally includes one or two representatives from the application development, DevOps, platform, and governance functional areas. Ideally, the functional representatives are influential, hands-on team members with enough experience to understand which issues matter, and hands-on enough to perform the PoC work or at least closely oversee the PoC work at a detailed level.

Keeping a PoC team small and hands-on usually leads to shorter timelines for the PoC. The timeline for a PoC should be several weeks and NOT several months. Ideally, a PoC has a core team of four to six doers and, with some expert guidance, should be able to deliver the PoC in 3-6 weeks. The learning from the PoC should roll right into a pilot step, keeping the momentum going.

In Figure 1, you can see the various organizational areas who need to be involved in the agile adoption process. It is not just some developers or a handful of system admins. The enterprise adoption of containers will have a direct impact on governance, operations, application development, and DevOps areas, starting with the PoC:

Figure 1: PoC Cross Functional Concerns

Representatives from the governance team will lead the efforts to do the following:

  • Facilitate shared learning and collaboration (that is, Wiki or MS teams)
  • Solicit and document objectives and success criteria for the PoC
  • Begin to solicit and document compliance, security, and access requirements for the pilot phase

Representatives from the platform team will lead the efforts to do the following:

  • Prepare Docker Enterprise PoC nodes, network, and storage
  • Install the Docker Enterprise PoC engine with optional logging configured 
  • Install Docker Enterprise PoC Universal Control Plane (UCP) 
  • Install PoC Docker Trusted Registry (DTR)
  • Configure clusters for PoC users and resources

Representatives from the application team will lead the efforts to do the following:

  • Pick a sample application to containerize and deploy during the PoC
  • Containerize the PoC application using official Docker Hub images
  • Create a YAML file for Swarm and/or Kubernetes to deploy the PoC application

Representatives from the DevOps team will lead the efforts to do the following:

  • Prepare a DevOps user Docker Enterprise CLI for remote access to the Docker Enterprise/Kubernetes APIs 
  • Script the PoC application deployment using the Docker Enterprise/Kubernetes APIs 
  • Script PoC application updates using the Docker Enterprise/Kubernetes APIs 
  • Run a PoC demo during the PoC wrap-up presentation

Many books have and will be written on enterprise transformation governance and DevOps. So, for the purposes of this book, we will mostly focus on the concerns of the platform and application teams.

上一章目录下一章