Beyond DevOps: Architecture for the XXI century Enterprise

Where DevOps come to play

DevOps while over rated is part of the big picture of the Digitral transformation
DevOps (development and operations) is an enterprise software development term used to mean a type of agile relationship between software development and IT
operations. The goal of DevOps is to create a better collaboration culture between the two functions. However often a DevOps
implementation results in the adoption of a collection of tools that are supposed to automate processes
in software development and operation rather than a real change in culture.

Automation of some processes is laudable, but it represents only a part of the CIOs concerns.

DevOps come in play when software is already being developed and maintained, it proposes nothing
regarding the business strategic planning, the requirement analysis and architecture that precede it.

Moreover,typically a DevOps environment requires a considerable cost to be set up and maintained,
so it represents a strategic capability of the enterprise and should be handled as such.

Because of those factors, we think that DevOps is reaching the infamous
Gartner’s peak of inflated expectations. In this article we intend to link the concept in a
comprehensive framework that extend DevOps to Architecture, integrating Industry Models in
order to facilitate the transition to the Slope of Enlightenment.

Reference architecture

To properly place DevOps in the greater XXI Century enterprise picture, we have created the reference
architecture above. In this reference architecture DevOps is a part of the bigger production line, that, in turn, is one of the elements of the Integration Layer.

Let’s see in how they fit together.

Verticals

The Vertical Layer comes first.
This is the core of the Enterprise.  It describes Biz Requirements that will be supported by the IT platform. Conceptually the vertical layer describes a Capability Model, a Process Model a Service Model and a Domain Model. Often this is very poorly documented, with information that is not maintained, stored in some old repository.

More mature organizations use sophisticated tools like Sparx Enterprise Architect (EA)to support industry architecture as starting point for this layer. Examples of available industries architecture includes  Frameworx (available as an EA content pack for for the Telecommunication Industry); ACORD (insurance), APQC (ranging from Banking to upstream Oil) and CIM
(Energy and Utility) can be consumed as accelerator packs. Consuming those as a model allow to directly link
to the next layer.

Integration

The integration Layer is the middle man “transforming” the requirements coming from the top layer into the Platform Layer at the bottom. We can organize it in 3 sections.

• The Methodology describes the delivery approach, the tool set, the skill set the organizational structure and so on.
• Best practices includes templates, patterns and other forms of reference material that can be leveraged in order to accelerate delivery.
• Finally The Production Line aims to translate the vertical in any supported platform in an optimized, automated fashion. The Production line is where DevOps can be seen as a strategic asset. We will return here later.

Platform

The Platform layer comes last, but not least.

Here we found the set of technological components, that are realized by   Commercial Off-The-Shelf (COTS) and custom solutions. Those application are used for standard operation.

The current technology trend is to go from legacy monolithic systems like ERP, CRM to a Service Oriented Architecture. big/block applications are more and more abstracted by exposing canonical services using ESB that run on the top of BPM executed business processes and rules and Master Data Management.

In this way the presentation layer can be exposed, providing integrated customer experience and employees access to business functions.

Automation is the key

So long, so good. The amount of work necessary to transform the Vertical Layer into
the Platform is what make the difference between successful digital transformation and the 70% failure (according to McKinsey)

While in 2019 it would be unthinkable to build cars manually, as a matter of fact information technology projects perform a quantity of manual activities. This start with the Design.

Design is  typically not addressed by DevOps: the automated process starts only after the code is manually written, reading specifications that are often maintained as MS office documents. Often a poor understanding of the
Agile Manifesto push people to declare that Design is not even necessary. For sure Design is expensive when consist in a serie of manual steps, trying to make sense of information that is all over the places.
A better DevOps starts with the Architecture definition, merging design, collaboration, build, test deploy and run in a seamless, integrated process. This design phase is directly linked in a model with the industry models, providing complete traceability from strategic planning to the run phase. Everyone agrees that a more streamlined approach would be required, but nevertheless this is seldom implemented. One of the reasons is the lack of understanding of the complete picture, that we are trying
to address in this article.How we can go there?

A Maturity Model for the XXI century Enterprise

Many modern enterprises have multiple pieces of our puzzle and are in the process of integrating them together in a coherent picture. DevOps is a crucial part of the digital transformation process. However this is  a journey that cannot be done in a single step, or project.

DevOps should use a Capability Maturity Model (CMM) to address the innovation challenge by providing an effective and proven method for an organization to gradually gain control over, and improve, its change processes.

• Level one, Technology Services, is where we currently are: technology focus DevOps, driven by technologists
• At level two, Optimized Services, DevOps services are optimized across projects and the delivery approach is formulated. Multiple DevOps chain are supported, a level of abstraction is created to separate the DevOps process from his implementation.
• Level three, Architectural Driven describes the architectural integration of the planning aspect with the supporting DevOps production line. The architecture becomes part of the automated production line.
• Level four, Business Driven, introduces the initial ability to automate the business processes and automatically translate them by using the Production Line. the Business is directly linked in the chain. In it only at this level that the ability to react to changes in the business environment is exponentially higher than the previous levels.
• Finally in level Five, Cognitive Driven, the production line is assisted by AI processes, that streamline previous manual activities.

Conclusion

DevOps is only one the gears of a the complex digital transformation clock.

A mature Production Line should take as an input the output from the Vertical layer and produce automatically an output that can be consumed by the IT platform. A capability maturity model, like the one we present in this article, can describe the steps necessary to improve not only the tools set and their integration, but also the processes and roles behind DevOps and beyond.