In the database automation space, there are several axes that often have a push/pull relationship. The two that I see dominate decisions and cause debate are: standardization versus customization, and speed of adoption versus accomplishing all goals.
Take standardization versus customization. If I told you we could take your existing processes, across 15 teams, and automate them in a single way, but 3 teams would have to change their workflow, is that better than two implementations with minimal disruption to existing workflows? Which route would you take? What would the criteria for a decision be? Ease of adoption is a good goal, but is team interoperability part of the long-term goal? Who shapes these decisions between developers and operations and DBAs? Not every organization faces the same problems between those functions.
What if we add a 0 to the number of teams, to 150 teams to support? Should we create a self-service center of excellence where teams can pick and choose their flow, or constrain their inputs to a pre-defined set of criteria (branch, repository, project setup, etc)? I’ve seen both models implemented brilliantly and I’ve seen both models fail.
Customization increases complexity. Complexity increases adoption time. What is the tradeoff between solving 60% of a big problem this quarter or solving 90% of a big problem over a longer initiative?
In my experience, there is no right or wrong generic answer to these questions, but there may be right or wrong plans for an organization’s goals.
My advice? Think in phases. Understand the one to two year vision, but find a way to get a win this month and build on that success. Think about how teams must work together when ad-hoc decision making needs to be formalized. Fundamentally, automation is the formalization of the informal. It has benefits but also leads to negotiations between teams with distinct and sometimes conflicting goals. You cannot automate chaos, but you may need to inventory it before laying solid foundations for a better process.
