Author's Note:  For the purposes of this article, when I refer to DevOps (Development and Operations), I am also including the Agile SDLC (System Development Life Cycle) and PM (Project Management) practices that are an intrinsic and critical constituent of this approach.

I regularly come across articles espousing DevOps as key to establishing IT alignment to the Business, for application lifecycle management, and even for driving strategy.  I find this belief quite concerning and, in this article, will explain why it is not only wrong, but quite impossible, to expect DevOps to be effective for any of these purposes.  I will also provide an overview of the wealth of existing and effective best practices that will ensure this alignment, when competently executed. 

DevOps and Strategic Alignment

DevOps has its place in the continuous build cycle of a project or a product that is actively evolving, and (through Agile practices) is helpful in keeping a nice, tight loop with the business users of the application.  But keep in mind that these front-line business staff, while being a great source of tactical direction for requirements, are simply not the stakeholders who drive the business strategy.  The big mistake I see being made by DevOps/Agile proponents is to think they are supporting business alignment simply because they are giving the front-line business what they want.  While it is important that the users are happy and the solution is aligned to what they need to do their job, that is not remotely the same thing as being aligned to business strategy and enterprise needs. 

DevOps sits at the tail end of a chain of decision-making that occurs long before a project is ever launched to develop a product, let alone when it is operational.  All of this strategic decision-making occurs way outside the visible horizon of DevOps;  this means that DevOps effectiveness doesn't extend much beyond the incremental and iterative evolution of an application — especially when compared to the best practices that should be employed instead.  This is why DevOps/Agile must be constrained to the details of the solution and not the intent of the solution.  If the intent changes then the project must be stopped and reviewed at a higher, more strategic layer of the company (typically, the portfolio or program level). 

Solution Architecture is the proper touch-point between DevOps and strategic alignment.  The Solution Architect (SA) is not just there to provide a high-level spec for the development team:  the SA is involved with the active evolution of the product and, through their collaboration with Portfolio Architects, will have visibility into new and changed business processes that may yield new stakeholders and required new functionality — functionality that has been vetted for its strategic worth.  Conversely, the SA is in a position to put the brakes on ill-advised adventures in development because their visibility into the strategic needs of the greater organization (again, through the other Architects) allows them to identify redundant, strategically mis-aligned, and low-value development ideas.

NB  If not DevOps, whose role is it to ensure strategic alignment?  See the sidebar for the answer.

DevOps and Application Lifecycle Management

It is definitely important to understand the cascade of effects from server to application to business process to business function — which is why Information Technology Infrastructure Library (ITIL) for decades has promoted the configuration management database (CMDB) as a key element.  ITIL (being a Service Management framework) and Application Portfolio Management (in which the Portfolio Architect is intimately involved) are best practices to strategically manage the lifecycle of all applications (Application Lifecycle Management — ALM).  ALM is much more than keeping the application refreshed and evolving; knowing when to invest, and when to stop investing, in that app is even more important, and those value assessments are made based on strategic decision-making at the Portfolio (or sometimes even Enterprise) level, outside the visibility of DevOps. 

So, while DevOps is an important contributor to the "live" phase(s) of the application's lifecycle, it is only relevant to that portion.  In fact, nesting DevOps within the larger umbrella of ITIL governance (Service Transition and Service Operation phases) is a great natural fit. 

The Chain of Strategic Decision-Making

Strategic application and infrastructure investment decisions are outputs from portfolio-level strategic planning and roadmapping, which are informed by enterprise-level strategic objectives and priorities.  Even though strategic, the people making these investment decisions are making them within the visibility of their portfolio.  For that reason, these investment ideas must be submitted to a cross-enterprise process (Demand Management) in a competition for funding that assesses all the investment proposals in terms of their relative value to the company, and does so from multiple dimensions (including strategic alignment, legal compliance, avoidance of risk, etc.).

When an investment proposal is approved by senior management through the Demand Management process, it is sent to the Project Management office to be scheduled and executed as a project (possibly under the scheduling and management of a Program).  Only then does this whole thing start to enter the horizon of visibility of DevOps!

Conclusion

Some people reading the above description may think that this is a whole load of bureaucracy and inefficiency.  And it can be, if it is not executed competently (just like anything else).  However, these best practices work together to ensure that what is operating and what is being delivered into the operational environment are fulfilling the needs of the corporation — this is something that DevOps could never do. 

What DevOps can do, though, is ensure that robust applications are delivered as rapidly as possible, and that the details of how the applications work and what they do are kept closely in tune with the needs of the front-line workers who use those applications on a daily basis.  That is incredibly important as well, and it should be more than enough to satisfy the ambitions of the DevOps (and Agile) evangelizers. 

# # #