4 tips for implementing consistent configuration and automation standards

The IBM CIO Hybrid Cloud organization has been working to streamline and automate processes using Ansible playbooks. We started the project by analyzing how different departments conduct configurations, identifying the manual steps they're taking, and measuring their impact on the automation process. To assist our automation, we created common configuration and automation standards that can be reused across the organization.

[ Learn best practices for implementing automation across your organization. Download The automation architect's handbook. ] 

In our analysis, we found that application deployments, including server builds, configuration, and deployments, typically involve lots of manual steps and processes. The configuration steps in deployments are critical. They must be consistent so that the automation team can use them consistently and efficiently across environments. This consistency also promotes seamless integration, which reduces cycle time, resources, and cost and improves productivity.

Why common standards are important

Bill Gates said that "the first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency."

We determined that having common configuration and automation standards helps improve customer satisfaction. It also promotes faster delivery of application feature requests and deployments.

A lack of clear configuration standards may cause ripple effects such as:

• Different versions of playbooks to automate the same process
• Increased development and maintenance costs
• Decreased productivity, inefficient operations, and waste
• Ambiguity in defining specifications for automation
• Inconsistent system states and more work to manage and maintain systems (such as server patching and upgrades)

[ Learn 5 steps to automate your business. ]

On the flip side, having common configuration and automation standards offers many benefits, including:

• Supports consistent configuration in the enterprise
• Enables consistent automation standards in the enterprise
• Promotes smooth process flows
• Provides the ability to automate as much as possible and drive toward touchless automation
• Adheres to industry standards and guidelines
• Enables the DevSecOps model and promotes continuous integration and continuous deployment (CI/CD)
• Drives teams to adopt Infrastructure as a Code across the enterprise using an automation platform
• Reduces duplication of effort
• Improves cycle time
• Promotes reusability of configuration items
• Removes ambiguity in automation processes
• Promotes features and customer requests quickly
• Promotes skill sets consistently
• Improves the quality of deliverables

Defining the problem and a solution

Our analysis showed that our configurations and automation scripts were inconsistent. Lack of standards and procedures created a huge impact on business and application deployments.

To solve these problems, we set out to:

• Document standards
• Publish standards
• Disseminate and execute standards and apply them in the automation process
• Measure configuration items and automation standards

We adopted a lean agile methodology and set the following goals to evaluate and implement the solution.

[ Learn more about server and configuration management by downloading Ansible for DevOps. ]

1. Use GitHub

The team designed a GitHub structure to document and publish standards. We investigated various tools and decided that GitHub is the best fit to keep track of versioning and collaborate with broader teams. GitHub allows multiple team members to work on projects at the same time and manages software code and documentation. It also helps showcase our work, tracks changes to code and documentation across versions, and supports Markdown. It is also is well integrated with other tools.

We also looked at the best way to structure standards. Should they be grouped based on domain or functional levels? Should they be aligned based on their core capabilities? We made an architectural design decision to structure and group the standards based on the core capabilities (instead of at the functional level) because if there is a reorganization, our GitHub page's structure won’t be impacted much.

2. Document standards

We structured and aligned our teams with relevant subject matter experts (SMEs) and grouped them by product expertise. We also created a team accountability matrix and defined roles for each product area.

During design-thinking sessions, we designed the GitHub structure to capture standards across the environment with consistency. This process of documenting standards helps us follow proper audit and compliance methods. We also work with other teams to review and validate standards to keep up with automation process changes.

[ Become a Red Hat Certified Architect and boost your career. ]

3. Keep standards updated

The team regularly reviews standards with squads and SMEs to keep the operating system and middleware standards current and compliant with security and other requirements. We created a naming structure for standards to maintain version control for compliance and audit purposes.

The standards form a baseline for maintaining playbooks for consistent automation across the environment. The organization also promotes InnerSource (the use of open source practices to improve internal software) and advocates reusing playbooks. We base the playbooks on common configuration and automation standards. This establishes governance for operating systems and middleware support.

For example, the operations and automation teams decided to support the current and next versions of IBM middleware including WebSphere Application Server (WAS), Database 2 (DB2), and Messaging and Queuing (MQ) and the AIX, Linux, and Windows operating systems. They put prior versions on the path to be unsupported or sunset (the previous version) or decommissioned (two versions in the past). This approach allows the teams to capture assets' state information by running a query in the configuration-management database to determine compliance information.

[ Learn how IT modernization can help alleviate technical debt. ]

4. Measure benefits and results

Having these standards enables the automation team to comply with consistent configuration and versioning standards and reuse them across environments. Capturing state information across environments enables the operations and automation teams to do inventory assessments and generate reports when needed.

We measured the time it took to install WAS, DB2, and MQ manually and with our Ansible playbooks. We based these playbooks on the common configuration and automation standards that we developed.

• Manually installing WAS, MQ, and DB2 on AIX, Windows, and Linux took 1440 minutes.

In comparison, automation decreased installation time to:

• MQ: 20 minutes (AIX, Windows, and Linux)
• WAS: 15 minutes (AIX, Windows, and Linux )
• DB2: 10 minutes on Windows and Linux; 12 minutes on AIX

Achieve true modernization

Automation is a continuous journey. Achieving touchless deployments requires standard configurations, processes, procedures, security guidelines, and other dependencies that you must review and validate periodically. These standards form the baseline that the automation team will adopt and implement. Having a consistent configuration across the environment enables the DevSecOps team to seamlessly integrate those configurations into the automation playbooks without many deviations or changes.

Modernization is not achieved only by migrating applications from a monolithic to a container-based platform or with microservices. True modernization is achieved by eliminating manual steps at each stage, including development, deployment, and operations. Every member of an IT team has a role to play in developing standard, consistent, and reusable configurations across the environment.

[ Check out Red Hat's Portfolio Architecture Center for a wide variety of reference architectures you can use. ]

---

This originally appeared on Hybrid Cloud How-tos and is republished with permission.