The term AllOps was coined this week in a blog on Dyn.com. Tom Daly, the author, says the motivation for AllOps and not just DevOps has to do with 'the blame game'. Even if the developers and operations break down their silos, there's still an opportunity to blame other departments outside of the DevOps team:
For too long, IT organizations have been plagued with the blame game, which is what the concept of AllOps aims to eliminate. Tell me if you’ve heard of or been part of one of these scenarios before…
- Engineering develops products to run on systems and when something goes wrong, the systems folks point fingers at the engineers for too many bugs in the software.
- The systems team cannot move data around the network fast enough, so they blame the network/infrastructure group for delays with data backups.
- The network/infrastructure team cannot grow the infrastructure fast enough due to budget and/or time constraints and cite the business team for the constraints. --Tom Daly
So should we start thinking about AllOps now? Certainly, but I think that DevOps should really be about a narrower focus on the best practices and tools for synergistic collaboration between just developers and operations, because that facet of 'AllOps' deserves close attention for many of today's IT companies.
I think that Agile, BPM, DevOps are all pieces of a general theory of what it means to run an optimized tech business. Agile focuses on methodologies that can be very focused or very broad. DevOps focuses on the interactions of IT and Development departments as code goes to production.
What we're looking for is something like the notion of a 'string theory' in physics, which is an attempt to unify the theory of broader laws of General Relativity and the smaller scale laws of Quantum Physics. Is "AllOps" a name for that general theory of everything? Who knows. But once this theory gets a catchy, buzzword name, I'm sure it will go far.