DevOps and the Next Bottleneck: Architecture

If you have read any of my articles over the years you will know that I subscribe to the definitions of DevOps that focus on outcomes and business value, not the definitions that focus on tools and engineers. Having said that, I have frequently written that DevOps is about continuous learning and improvement and removing bottlenecks from the software development lifecycle (SDLC).

As I look back over the last 10+ years since the term DevOps was coined, I have witnessed a pattern of removing bottlenecks from the SDLC in the following order (usually):

CI/CD -Continuous Integration/Continuous Delivery

In the early days, DevOps was mostly focused on solving the bottleneck of inconsistent builds and environments. Practitioners focused heavily on tooling and automation around the build process and infrastructure. This is the primary reason why many people think DevOps equals CI/CD, but as you will see in the rest of this article, it has moved way beyond that. CI/CD is a commodity now and an area that many organizations have solved yet are still continuously improving over time.

Test automation

As practitioners beefed up their skills in perfecting the build process, they looked to solve the next bottleneck which was throwing the code over the wall to be tested. A lot of time was being wasted in the back and forth processes required to shake out the critical defects. Automated testing became a standard for the CI process from this point forward.

Most companies who have been on their DevOps journey for a few years, have a solid track record with CI/CD and automated tests in the build process and are now focusing on one or more of the next bottlenecks.

Security

Yes, the dreaded DevSecOps term. Practitioners who removed many of the bottlenecks caused by inconsistent builds, unrepeatable deployments, and lack of test automation now look to remove the next big bottleneck which is usually security. A lot of work is happening in enterprises to involve security teams and security architects in the SDLC from the start. Security code scans are now part of many CI/CD pipelines. Security policies are being baked into cloud platforms and continuous security monitoring and alerting is becoming the new norm.

Operations

Traditional Ops is being totally rethought. We see a lot of movement around SRE (site reliability engineering), observability, platform engineering, chaos or resiliency engineering and many other modern approaches to running apps and platforms in the cloud.

Governance and Compliance

Nothing says bottleneck more than governance and compliance. Many mature DevOps shops are focusing heavily on culture change in this area. Some companies are creating governance and compliance teams that focus solely on the cloud and act as a liaison back into their respected COEs (Center of Excellence) in corporate IT as a way to speed up approvals and decision making.

Tier 1-3 Support

Another major bottleneck is problem resolution and MTTR (mean time to repair). Many companies are shifting support left, closer to the people with the proper context of the application so that problems are solved faster. This usually requires a culture shift to product centric mindset as opposed to project centric mindset and t-shaped management structures where the same manager who is responsible for building the software also owns supporting it.

What about Architecture?

While I have watched this unfold over the last 10+ years, I often ask “why aren’t we talking about architecture?” All the automation, op model changes and process improvements in the world do not solve for bad or overly complex architectures. At the DevOps Enterprise Summit in 2019, I watched a great presentation by architect Scott Havens that nearly brought tears to my eyes. Finally, someone was talking about architecture as a bottleneck and prescribing a way to address it. He discussed functional programming methods and ways to avoid or simplify complexity in systems. If you are technical and have 30 minutes, I recommend watching this video (he starts around the 7-minute mark).

I wish more architects would be more pragmatic like Scott. I have seen too many instances where architects run to microservices as an end-all be-all solution to solve all of their problems only to create a complex mess of unmanageable chaos. Microservices are only as good as the architecture they are deployed in. The same can be said for any of today’s hot new technologies such as Kubernetes. I run out of fingers and toes to count how many times I have seen teams run off and go dark on the business as they spend precious dollars and hours building Kubernetes clusters for the sake of Kubernetes, not for the sake of the business.

Microservices, Kubernetes, Cloud, AI, ML and all other hot technologies are all force multipliers and can be powerful business enablers, but all of them are only as good as the architects and the architecture for which they are designed and deployed in. Take a page from Scott’s talk and design a well thought out architecture to avoid complexity and solve real business problems.

Call to action

DevOps is all about working together to build more reliable software with more agility while delivering business value. As we mature along our DevOps journey, we must focus on continuous learning and improvement while we change the way we think about systems, the way we work and the way our culture embraces change.

While we focus on our people, process, and technology bottlenecks, let’s not forget that our success can be severely limited by the complexities caused by both or legacy and new architectures. As we run to new tools and technologies to achieve our technology nirvana, let us not forget that a pragmatic architecture that limits complexity, anticipates and recovers from failure at all layers and focuses on delivering business value can be one of the best ways to remove bottlenecks from your entire SDLC.

Great architectures minimize technical debt thus freeing up staff to contribute to even more business value. Refrain from using tech for the sake of tech and start creating real business value with a focus on architecture, not tools.

About Deloitte

Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee (“DTTL”), its network of member firms, and their related entities. DTTL and each of its member firms are legally separate and independent entities. DTTL (also referred to as “Deloitte Global”) does not provide services to clients. In the United States, Deloitte refers to one or more of the US member firms of DTTL, their related entities that operate using the “Deloitte” name in the United States and their respective affiliates. Certain services may not be available to attest clients under the rules and regulations of public accounting. Please see www.deloitte.com/about to learn more about our global network of member firms.

This publication contains general information only and Deloitte is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or other professional advice or services. This publication is not a substitute for such professional advice or services, nor should it be used as a basis for any decision or action that may affect your business. Before making any decision or taking any action that may affect your business, you should consult a qualified professional advisor. Deloitte shall not be responsible for any loss sustained by any person who relies on this publication.

Copyright ? 2020 Deloitte Development LLC. All rights reserved.