As mentioned in my last post, Bimodal vs. Multimodal IT: How We Made this Crucial Decision, it was important for the ISS team to take our company’s specific environment into account when adopting the multimodal approach. In the context of what we are trying to achieve, our DevOps thrust was to:
- Maintain a small batch size, reasoning that small, frequent changes carry less risk than a large release train. We also established discipline around putting changes under configuration management (CM), which can be reviewed and deployed by tooling. Further, we implemented anti-fragile patterns to allow us to upgrade live systems during regular hours.
- Fail fast and recover fast. By using repeatable deployment techniques such as Ansible and Docker, mistakes can be made and corrected quickly.
- Improve collaboration and communicate changes in the open. Internal sandboxed CCB systems have been replaced by Open JIRA projects, and Hipchat was brought in to allow automated flow of relevant data into tailored rooms and provide context to the sequence of events.
- Always keep learning. A critical part of our DevOps approach is to look at metrics from a perspective of whether the change(s) had the desired outcome—then making the decision to either pivot or persevere. Additionally, we have introduced a paired programming workstation to enhance our ability to mentor each other and provide retrospectives for any incident or change that didn’t go as planned.
We began this effort early in 2016, allotting a year for the first phase and throwing away the assumption that bimodal tools were only for the “shiny new bits.” While there are certain things we’d never want to try to get a legacy system to do, our premise was to lay a foundation, establish design practices, and find pragmatic, iterative opportunities to constantly improve all facets of the enterprise. Fortunately, having a deep engineering perspective in our IT department gave us an edge. While our progress was slower than we liked, some of our peers at other companies told us that we’ve already hit goals they’ve set for their futures.
Being pragmatic, iterative, and metrics-driven, we’ve given ourselves a year to demonstrate the value of our approach to the business and that every change we introduce is scalable and repeatable. At some point, you don’t even have to think about the initiative in terms of “legacy vs. future.” That’s just good DevOps practice: measure, plan, act, measure, evaluate, and repeat.
When companies like Gartner prescribe bimodal approaches for their Fortune 500 subscribers, we think it’s a mistake to assume that these will be best practice for everyone else. For example, our company—and I’m sure many others—doesn’t have two discrete chunks of technology that neatly fit into the two bimodal buckets. In just the past 20 years of computing, we’ve seen business technology go from mainframes to server farms to PaaS to containers. Some companies still have all four!
This binary approach can make things sound more cut-and-dry than they actually are and doesn’t allow for complexities. I would even go so far as to say that the approach is dangerous when applied simplistically. A facile overlay for what is often a nuanced, case-by-case IT environment won’t work for many, and it certainly doesn’t work for us.
We could have taken a few technologies and run full-tilt bimodal, but we took on the challenge of multimodal because we wanted to go farther together instead of merely faster. We’re going slower in an effort to bring everything (and everyone) along. So far it’s paid off in both progress and team morale.
This article originally appeared on Jobber Tech Talk, February 7, 2017.