DevOps tools are well-known as a means of enforcing deployment discipline. Many believe they are destined for a...
broader role as companies move from simple application lifecycle management and operations management to disciplined Agile delivery, or DAD. DAD arguably brings DevOps consideration all the way from operations back to enterprise architecture, uniting traditionally separate activities.
Much has been written about EA evolution to support DevOps, but there are steps that can be taken to promote the role of DevOps in that architecture. These make it necessary to connect development and deployment with the business process lifecycle, link ALM and operations back to business processes and use DevOps to identify technical debt.
Agile isn't the problem
Many believe that Agile delivery and even componentization have made development teams too shortsighted. Expediency often encourages quick fixes that fit the short-term business goals but fail in the long term, even when long-term trends are available. DAD, which adds discipline specifically to Agile delivery, is supposed to encourage a longer-term view of programming requirements' relationship to business goals. This is what creates the explicit link between DAD and EA.
The challenge for many enterprises is that they already have Agile delivery, don't have DAD in place and don't have a mechanism to deal with the projects already deployed under the older, undisciplined system. DevOps can help to retrofit DAD principles to projects by using DevOps to link them back to EA. The key to creating this link is to expand the normal connection between DevOps and applications, usually embodied in ALM processes, to connect with business processes through the EA model linkage. The role of DevOps as the EA-to-DAD link is critical.
The business process lifecycle connection
EA is responsible for defining business processes and linking those processes to applications. Agile delivery practices have focused on accelerating the application portion of that linkage, without paying much regard to the business process side. DAD proposes to impose business discipline on the application lifecycle, which effectively ties it more tightly to the EA business processes. This has been understood in theory, but it's often been difficult to put into practice.
DevOps tools require that operations understand two things: what specific components must be deployed for a given application and which components are deployed autonomously as services to multiple applications. Applications can be tied to business processes, and so DevOps supports business processes and EA through these ties. Shared components represent IT support for shared business processes. A key role of DevOps is to provide these critical links, and if DevOps is properly tied to EA, then it can support the transformation of EA business practices into applications.
How DevOps models should be structured
Every DevOps model should be linked to any application that it supports, and businesses should then identify the EA business processes that those applications support in turn. This lets enterprise architects map out a zone of business impact for each DevOps process, and this mapping should be as fundamental a part of DevOps documentation as the target applications or components impacted would be. That way, the impact of DevOps changes on business processes -- even if the impact is simply a risk of disruption during the change -- can be assessed. That requirement will also insure that development teams understand the business process lifecycle, or even lifecycles, that their application lifecycles may impact.
While the discipline to require that EA-to-application linkages are documented in DevOps is important, it may not be sufficient if DevOps models are not developed properly. The critical requirement is to ensure the models are hierarchical, where application deployment is defined as a series of referenced component deployments rather than some vast monolithic structure. Hierarchical DevOps encourages component reuse and even helps identify components that should be considered as multiapplication services by highlighting comparable deployment and connection requirements.
Avoiding unsynchronized changes
Getting EA and application development to synchronize during development is important, but application and business changes are an opportunity for both the business process lifecycle and application lifecycle to become disconnected. Since both EA and development respond to their own priorities, changes may be made on one area without fully reflecting them in the other. During ALM development and deployment processes, the DevOps linkage to EA should be used to test any business process lifecycle impacted by the application changes. Since companies should always treat a DevOps change as an application change for ALM purposes, this will link the two lifecycles together effectively.
ALM itself can benefit from a feedback chain with EA generated by DevOps and a record of application linkage to business processes. It's easy for ALM to become a kind of technical lake, where developers and operations review impacts and test changes without fully recognizing the business process impacts that EA would call out. A DevOps-generated link to EA will allow those who design the ALM processes to relate them to the business processes and even identify and notify the line organizations that will likely be impacted in each ALM procedure. That fully tests each application change in the best way: with the people who use it.
Technical debt issues
Technical debt management is the final, and perhaps most complex, point in DevOps support of EA. The term is used to describe a growing load of suboptimal IT strategies that emerge because development teams don't look far enough ahead to recognize the optimality of a given IT strategy. There is increased interest in giving EAs an advocacy role for the long-view suitability of a given technical component design or role.
This is logical given that EAs are custodians of the longer-term business requirements, but it means shifting some technology requirements into EA missions, a departure from the sharp division between EA and application architects. Another role of DevOps should be to help facilitate the shift in role and minimize friction between the two groups.
Conclusion: Continuous delivery needs DevOps
Many enterprise architects and application architects believe that the combination of cloud computing, shadow IT and continuous delivery will ultimately blur the boundary between EA and application architects. Even in the near term, it will surely generate more cooperation across the border and the role DevOps should be to form the basis for that cooperation.
Take an inside look at the DevOps movement
A guide to working with Agile and DevOps
Learn why DevOps hinges on a continuous delivery pipeline