DevOps – a term bandied about by all, understood by few, and delivered by almost no-one. Why? Partly because there are many different flavours of DevOps, and not all of them are workable or desirable.
The Anti-Patterns
Dev and Ops silos – the classic ‘throw it over the wall’ split between Development and Operations. It means that story points can be claimed early (DONE means ‘feature-complete’, but not working in Production), and software operability suffers because Development do not have enough context for operational features, and Operations teams do not have time or the inclination to engage Development in order to fix the problems before the software goes live.
DevOps team silos – The DevOps team silo typically results from a manager deciding that they “need a bit of this DevOps” and starting a ‘DevOps team’. The members of the DevOps team quickly form another silo, keeping Development and Operations further apart than ever as they defend their corner, skills, and toolset from the ‘clueless Devs’ and ‘dinosaur Ops’ people.
Dev don’t need Ops – this topology is borne of a combination of naivety and arrogance from developers and development managers, particularly when starting on new projects or systems. Assuming that Operations is now a thing of the past (“we have the Cloud now, right?”), the developers wildly underestimate the complexity and importance of operational skills and activities, and believe that they can do without them, or just cover them in spare hours.
DevOps as tools team – in order to “become DevOps” without losing current development teams’ velocity (delivery of functional stories), a DevOps team is set up to work on the tooling required for deployment pipelines, configuration management, environment management, etc. Meanwhile Operations folks continue to work in isolation and Development teams continue to throw them applications “over the wall”. Although the outcomes of this dedicated team can be beneficial in terms of an improved tool chain, its impact is limited. The fundamental problem of lack of early Ops involvement and collaboration in the application development lifecycle remains unchanged.
Rebrand SysAdmin – this typically occurs in organisations with low engineering maturity. They want to improve their practices and reduce costs, yet they fail to see IT as a core driver of the business. Because industry successes with DevOps are now evident, they want to “do DevOps” as well. Unfortunately, instead of reflecting on the gaps in the current structure and relationships, they take the elusive path of hiring “DevOps engineers” for their Ops team(s).
Ops embedded in the Dev team – The organisation decides it does not want to keep a separate Operations team, so Development takes responsibility for infrastructure, managing environments, monitoring, etc. However, doing so in a project or product-driven way means those items are subject to resource constraints and re-prioritisations which lead to subpar approaches and half-baked solutions. The organisation shows lack of appreciation for the importance and skills required for effective IT operations, such as reliability, stability, compliance with regulation etc.
Dev and DBA silos – this form is prominent in medium-to-large companies where multiple legacy systems depend on the same core set of data. Because these databases are so vital for the business, a dedicated DBA team, often under the Operations umbrella, is responsible for their maintenance, performance tuning and disaster recovery. The problem is when this team becomes a gate keeper for any and every database change, effectively becoming an obstacle to small and frequent deployments (a core tenet of DevOps and Continuous Delivery).
So What?
If companies are not willing to consider DevOps in terms of culture, organisation AND development lifecycle technology optimisation then it simply becomes a rebranding exercise of the SysAdmin role. Unfortunately, this is becoming more and more widespread with unscrupulous consultants and recruiters presenting candidates with automation and tooling skills as DevOps architects – they’re not!
