Introduction

Once there has been some real degree of success and adoption of the platform, it’s time to fine tune the definition for it to be able to meet the requirements of the future. Focus is on more advanced platform and adoption related capabilities. We spend more time standardizing things such as the development experience and onboarding, an investment which pays-off in the long term. The features we now build reduces the effort regarding maintenance and allows a much higher adoption rate of our platform.

Overview

Zoom into this picture for details.

Overview

People

  • Product owner - We have a person who is overall responsible for our automation platform. This role is commonly called a product or platform owner. This is the person who plans the development and implementation of this very operational model which you are now looking at.
  • Platform engineers - This role is called many different things in different organizations. SRE, platform engineers, system engineer, system administrators, etc. These are the people who makes sure that the platform works as it should. They also work together with the product owner to develop the platform. In some cases they are doing all the technical heavy lifting.

Community of practice

There are many different names for this, for example Centre of Excellence, DevOps Dojo, or etc. It’s simply a community which you build around your platform. Here we describe resources related to people and your community.

  • Community of practice core team - This is commonly made up by the product owner and platform engineers, but as you have created a community of practice (devops dojo, center of excellence, etc), you may want to invite some people from your community to take on leading roles.
  • Community of practice members - The community consists of people who are interested in automation and your platform. You gotta catch em all to get get a strong and growing community, but it’s good to start small, as there is a lot to learn here.
  • Chat channel - Community of pratice members needs a place where they can talk to each other.
  • Re-occurring meeting - Schedule a meeting every other week or weekly, where people can share and interact with each other.

Process

AAP platform processes

Processes tightly coupled with your Ansible Automation Platform.

  • Disaster recovery - We ensure we have a functioning process for Disaster Recovery. When significant parts of the organization depends on our platform, we need this.
  • Automated onboarding - The process for onboarding should be an automated one, this allows us to quickly onboard people and teams and create change while the iron is hot.
  • Assessment of teams and workloads - When you onboard new teams it’s important that you do some type of assessment of what type of automation this team will create. Automation workloads are an important source of requirements for things such as availability, capacity and security. You can start small and simply just interview new teams, or have them submit some standard information as a part of the onboarding process.
  • Training - You now do standard training for people who you onboard. What is that standard training? You decide.

Onboarding process

It’s time to improve the onboarding process so that the throughput of new teams can be increased.

An overview of a common onboarding process can be viewed below. Please note that the graphics describes all three advancement levels of onboarding. Overview

  • Automated onboarding - In order to speed up the onboarding process, it is key that you automate as much as possible. This will also decrease the risk that something is not properly configured, such as RBAC configuration in AAP. It’s important that people do not have to wait to long to get onboarded, as having to wait for long periods when you are motivated to get something done can easily demotivate people.

  • Initial assessment of workload - As new team are onboarded you need to do assessments of the team and their workloads to be able to provide a good service and speed up adoption.

  • Resource assessment - Ask the team some simple questions related to how many things they think they will automate and what type of automation they are considering. This will help you do capacity management. As an example, if the new team to be onboarded wants to automate 5000 new network switches, you may have to add new Execution Nodes in your Ansible Automation Platform cluster.

  • Training assessment - Just providing someone a tool, without any instructions about how to use it will hurt adoption and can create all sorts of long term challenges. Assess what type of training the new team needs.

  • DevOps training required - It is common that newly onboarded teams needs training related to why we automate, modern development practices, version control, testing, CI/CD and such. This will be key for them to understand. If you fail to catch this type of training requirement that will negatively impact overall adoption of your platform.

  • Ansible training required - Does the team getting onboarded need training related to the Ansible language, how to create roles, Molecule and Ansible Automation Platform? It’s good if you have some hands-on training regarding these things.

  • Training - This is the delivery of the training. If you cannot deliver this yourself, many companies, including Red Hat - has training available.

Development processes

Processes related to the development of automation.

  • Documentation - You have requirements related to what you should document.
  • Contribution to other’s repositories - How do you deal with cross-team contributions? Get inspired by how open source works.
  • Contributions to your own repositories - How do a team work with the development and maintenance of their automation? Does everyone have the same branching strategy? Is there specific roles such as maintainers?
  • Testing - Doing automation is simply just doing development. That means that you need to do testing of what you develop. But how?
  • CI/CD - In order to automate your development processes, you need CI/CD. But how do you work with CI/CD?
  • Ansible best practices - It’s common that you have a standard for how to write a programming language. If you have no idea, perhaps just let ansible-lint decide what is acceptable.
  • Automation integration process - This is a very important process. In order to prevent that various people in your organization simply say “NO” to automating something - you need a process. This process will put people who wants to automate, automation experts and typically the corporate security team - in the same room. The process allows for people to raise concerns in an orderly way - and then have those concerns addressed. At the end of the process, something is automated. It’s important that this process is backed by the organizations leadership.

Technology

AAP architecture

Infrastructure design

AAP design

Design of how to use Ansible Automation Platform features

  • Example organization - You have implemented an example organization, where all things are setup like you prefer them to be. A good soft way to guide how things are done.
  • Event Driven Ansible - You have given Event Driven Ansible some thought and have standards for how to create event driven automation flows.

Onboarding

Technology implementations related to onboarding.

  • FAQ - You have a Frequently Asked Questions section as a part of your onboarding page.
  • Learning path - You have a documented learning path for people who onboard to the platform. It includes how to you can enable yourself and up skill.
  • Internal training - You describe what internal training is available.
  • External training - You describe what external training is available, such as paid and free trainings from Red Hat and others. Perhaps you point people to the free Ansible online labs and the official paid Ansible training and certification from Red Hat.
  • Launch team trainings - People who are already Red Hat customers can reach out to their account managers and ask to get help from the Ansible Launch team, who can deliver standard and custom trainings for existing customers.
  • Books - There are a lot of good books on the topic of Ansible. Link a few!

Development tool chain

Design related to the development tool chain.

  • IDE - You have standardized the Integrated Development Environment, the program automation developers use to develop Ansible. For IDEs you prefer you may have standardized installations including plugins for Ansible. Such as for VSCode where we have the Red Hat supported Ansible extension.
  • CI/CD, CI and CD - You have a standardized CI/CD platform which you use for the purpose of developing Ansible.
  • CI, Testing - For continuous integration, you have a standard implementation for doing testing, perhaps using Molecule.
  • CI, Building - There are things in the world of Ansible which needs building, such as Execution Environments and Ansible modules. You have implemented standard solutions for doing this.
  • CI, Security gates - You have implemented some security gates for the Ansible development workflow, such as signing your Ansible artifacts using ansible-sign with Ansible Automation Platform.
  • CD, Security gates - You have some type of security checks before deploying things, such as scanning execution environments for security issues.
  • CD, Deployment - You have a standardized approach to deploying automation in production. Perhaps you have test and production organizations, project, repositories, etc or completely separate environments throughout the development tool chain.

Platform management

Administrative features which helps with the development or maintenance of the platform.

  • AAP Success Plan - There is a basic success plan in place for the platform, outlining what KPIs we want to impact. We are often lacking performance monitoring for these KPIs.
  • KPIs (Master doc) - You have a document describing KPIs which we monitor, if they are not a part of the overall AAP success plan.

Brand

Features related to building branding and identity of the platform.

  • Name - Give your platform a catchy name which people can refer to. Gather key stakeholders and brainstorm a list of qualities your project’s name should have. Then develop a list of possible names. Identify your top choices. Determine if any of your favorites are already in use.
  • Logo - Your platform will benefit from a visual identity. Follow a process similar to the one you followed when developing a name. Sketch some ideas. Seek stakeholder input. Don’t forget to research prior art.
  • Merchandise - Common type of merchandise which can help make your platform popular are: stickers, t-shirts, and digital badges.