Can we leverage architecture in a VUCA business environment?

Publish date:

Businesses today are increasingly operating in a highly Volatile, Uncertain, Complex, and Ambiguous (VUCA) environment. To cope with this change while providing speed and agility, DevOps teams have been set up to deliver software on a regular, sometimes even continuous, basis. So if this is organized well, does architecture still add any value?

Because of VUCA, the way software is delivered has changed dramatically in the last decades. The barriers between software development and operations have been leveled with the introduction of DevOps teams. Simultaneously, continuous delivery methods have cut software development cycles from months, to days, or even hours.

From a distance, everything looks as though it should work fine. However, VUCA software delivery entails a significant risk that I call “Non-Functional Negligence (NFN).” The primary responsibility of a DevOps team is to deliver small pieces of functionality at speed, which often results in neglecting or even ignoring important non-functional topics like re-usability, performance efficiency, and security.

The visible effect of NFN takes time because of the granular evolution of small pieces of functionality. However, at some moment a threshold at which solutions become unreliable due to numerous versions of the same functionality, performance inefficiency, security and legal issues, etc. will be reached. To minimize this risk, three rules should be applied.

First, the delivery platform should be standardized at the enterprise level. This means that for each capability within the platform (especially repository, test, configuration, and change management) an agreed and limited set of tools must be used. If a DevOps team needs to change the platform due to new technologies, this should be assessed at cross-DevOps level before it is incorporated in the platform.

Secondly, an easy-to-use checklist must be applied for each piece of functionality to assess its non-functional fit. This checklist can be used in a formalized way, but informal use is preferred so that potential non-functional issues can be discussed and incorporated into the delivery at the start of the delivery cycle.

Finally, to organize things correctly and sustainably, an architecture role must be in place. The role’s primary responsibility is to standardize the delivery platform in a flexible way and control non-functional topics within individual DevOps team from a cross-DevOps team (i.e., enterprise) perspective. Therefore, I would define this role as “Agile Enterprise Architect.”

By introducing these rules, the distance between enterprise architecture direction and actual solution implementation will shrink, resulting in the delivery of flexible and agile, as well as robust and compliant solutions. Only in this way can complexity be controlled to keep IT aligned with VUCA business expectations.

Related Posts


Delivering faster with better use of micro-frontends in financial services

Date icon September 21, 2021

What works well is multiple SPAs owned by specific DevOps teams that can decide what happens...


No one likes waiting. With Continuous Delivery, now you don’t have to!

Venky Chennapragada
Date icon March 22, 2021

Automated and on demand – here’s how, why, and when you should adopt Continuous Delivery...


How to liberate your legacy applications to unleash powerful, agile next-gen apps

Erik Haahr
Date icon March 1, 2021

Discarding the burden of an existing traditional applications landscape will bring clearer...