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

agile

Enterprise’s valuable resource is data in the digital world

Shivakumar Balasubramaniyan
Date icon September 27, 2018

Data is a vital resource for an enterprise. Read this blog to learn more about the economics of...

AI

QA budget trends analysis

Kumar Balasubramaniam
Date icon September 24, 2018

Discover the key factors that should be considered before deciding on a QA budget for achieving...

agile

Do you feel that agile is losing you?

MICHEL BURINI
Date icon September 19, 2018

Quality is the correct expression of a project well done. But how do the testers put it at the...

cookies.

By continuing to navigate on this website, you accept the use of cookies.

For more information and to change the setting of cookies on your computer, please read our Privacy Policy.

Close

Close cookie information