I have promises to keep. I've told numerous interested folks over the past few months that I would "soon" have some material out on Enterprise DevOps. So, here is the first in a series of posts on the topic.
To start: Semantics matter. What would we mean by Enterprise DevOps? And in particular,
how is "Enterprise DevOps" a value-adding, distinct category within the broader world of DevOps?
I think so. At least three dimensions come to mind:
- Size
- Timescale
- Product portfolio
Scale matters. Small enterprises have fewer internal/procedural constraints than large enterprises, in general. Corporate governance, regulatory compliance, architecture standards, and internal controls all may complicate DevOps in ways specific to large enterprises. The sheer volumes handled by enterprise systems also present particular challenges; e.g. reliable automated testing of high volume interactions across distributed architectures.
The elapsed years matter. Greenfield development differs from the ongoing evolution and maintenance of systems representing intricate, decades-old legacies of codified enterprise experiences.
Finally, variety matters. There is a significant distinction between a team using a small set of readily available open source languages and tools, versus a team building and running enterprise systems based on the vast array of commercial products released over the past thirty years.
Here is a list of technologies which I have not seen discussed much in the DevOps literature to date:
- Mainframe & midrange platforms. CICS, JCL, ISAM/VSAM/IMS, Tandem/Nonstop, AS/400/iSeries/IBM i, etc
- ERP platforms and functional modules: SAP Basis/ABAP, Oracle Forms/ADF/etc, PeopleTools, and all the stuff that's been built thereupon.
- Data management - beyond core DBMS & trendy things like Hadoop. What about ETL & BI platforms? MDM? OLAP?
- Middleware frameworks - messaging, EAI, BRM, BPM, etc.
- Shared production services - ops consoles, service monitoring, scheduling/workload automation, backup, security, etc
That stuff is not going to magically go away anytime soon, and I believe there is value in a detailed examination of exactly what products are compatible or incompatible in which specific ways with DevOps general practices. A key theme here is the tension between customization and configuration. We need a community DevOps "bestiary" which discusses in detail which can be managed from an "infrastructure as code" perspective and which can't.
(Clarification: I am not saying nothing has been written on the above topics. There's a number of very cool posts and case studies. But in general the quantity appears light. Would be interested to find that I'm wrong about this.)
In sum, one strawman definition of Enterprise DevOps would be
"DevOps, applied at the scale, and within
the technology and governance constraints
typical of, large, long-lived enterprises."
I think the term "long-lived" is key. We know that DevOps is succeeding at companies who have been able to scale rapidly in recent years (Google, Amazon, Facebook). However, the atypical, green-field nature of those efforts put them somewhat outside the zone of what I mean by "Enterprise DevOps." They are inspirations, but in these discussions I'll be focusing on the problems faced by companies whose IT practices started well before DevOps was codified, and whose lines of business are the traditional verticals: retail, finance, healthcare, energy, transportation, manufacturing, food, and so forth.
Some possible topics:
- Technology constraints of Enterprise DevOps
- ERP, COTS, and DevOps
- DevOps and the mainframe
- Governance constraints of Enterprise DevOps
- DevOps and legacy systems
- Continuous integration across complex distributed systems with high volume interactions
- DevOps and the IT/business synthesis
I would also like to cover culture and enterprise transformation, but cautiously. One reads many subjective and loaded assertions about "heavyweight" or "bureaucratic" enterprise cultures. Such discussions can generate more heat than light, in my experience, unless grounded in observable phenomena. One person's bureaucracy is another person's balancing feedback loop.
Thoughts?
-Charlie
=========================================================
Related links:
I recommend as a concise primer this Cutter Consortium report, which as of this writing I was able to access for free as a promotion.
I also have previously proposed a reference architecture for a enterprisee IT DevOps pipeline.
