DevOps in the middle: what enterprise architects can learn from the English Channel
The best approach to DevOps could be to align in the middle.
Remember the days when IT architects plied their trade on information technology, focusing only on hardware, operating systems, programming, networking, applications, databases and the like? While they had their eye on the business operations, those details were in someone else’s domain. That, however, proved too limiting and in the last few years, many IT architects have broadened their scope. Now known as enterprise architects, their work encompasses all the structures and operations within an organization – everything from organizational and business processes to data classification and yes, hardware and software.
It should be no surprise that enterprise architecture has come to include application development, and many enterprise architects now find themselves struggling to understand something called DevOps. But that’s easier said than done. DevOps, after all, is an emerging discipline. Many don’t even know what DevOps is, and some think it’s nothing but hype. Others believe it simply isn’t significant to their organizations. From my perspective, I think it is something to which every enterprise architect should be paying close attention.
DevOps is designed to strengthen communication and collaboration between developers and IT operations to accelerate development times and deliver quality applications that work right out of the gate. With today’s ever-changing technology environment and competitive pressures, this acceleration of app development and deployment is critical. Consider mobile apps, which often need to be updated every couple of weeks. Traditional 18-month development cycles simply don’t work.
Since many organizations are still adjusting to (or even struggling to believe in) DevOps, it’s a tall order to ask enterprise architects to factor in the discipline as they draw up and implement the Enterprise Architectures for their organizations. That shouldn’t stop the progress, however. And with careful planning and consideration, it won’t.
Perhaps the first order of business is weeding through all the noise – you can’t peruse IT media without seeing some article on DevOps, and many vendors are using DevOps now in their product names or their product marketing. Plenty of services firms are establishing DevOps consulting practices. The good thing is all this noise gives enterprise architects plenty of information. But before engaging any of the noisemakers, it is important to determine just how to get started with DevOps. Conceptually, enterprise architects understand the intersection between developers and IT operations, and they understand goals and collaboration. They also understand that leveraging DevOps will require changes among many parts of an enterprise architecture, including organization structures and IT tools. But from which side should the efforts kick off? Development? Operations? It’s a bit like building that tunnel underneath the English Channel. The best approach is probably to start from both sides and work your way to the middle, but you’ve got to make sure both sides line up when they come together
Another touchy area enterprise architects will need to consider is in the area of measurements and rewards – things that, frankly, are fundamentally opposed between development and operations. Development is measured by speed, and creativity is rewarded. Operations is measured by stability, and conformance and control are critical.
Lining up the two sides and establishing metrics requires a top-down focus, so enterprise architects need to make sure they have upper management involved. And enterprise architects should analyze their companies’ organizational structures and how they align; it might be wise to align operations teams and developer teams symmetrically, perhaps around application tiers. For example, the tier one application operations team, with its focus on apps critical to the enterprise, comprises some storage, network, systems and security people and so forth. There needs to be a clear line of sight all the way back to the development side for people with those same roles. While enterprise architects don’t typically run company reorgs, one of their core responsibilities is to see how the different pieces fit together, and it is absolutely within the focus of the enterprise architect group to make those recommendations back to senior leadership who have the ability to change things.
Finally, there’s probably no better place to guide DevOps than within the enterprise architecture. After all, enterprise architects are in the business of defining conceptual blueprints that eliminate inefficient and redundant processes and optimize the use of organizational assets. All of that sets the stage for reaping DevOps’ benefits of improving an organization’s adaptability to changing demands or market conditions and accelerating the development of applications.