The Need for Business Agility

New business opportunities arise all the time, as does the need to react to disruption in the market, such as ‘Black Swan’ events. Agility is required, to be able to pivot plans, for teams to reform around new goals and, often, changes in technology direction. Collectively, such step-changes are often badged as digital transformation.

Given this context, it’s unfortunate that a traditional technology architecture function can be seen as a hindrance, especially to agile teams that want to deliver quickly, to burn through backlogs, adapt to changing customer needs and pivot to focus on new features. When engaging with such teams, an architect can find themselves a bit out of place, feel undervalued and excluded, or worse, perceived as a blocker in bringing a layer of ‘bureaucracy’ where the team just don't want it. Unchecked, this dynamic can quickly create tension, division and, ultimately, politics creep in.

It really shouldn’t be this way. Making the right architectural decisions is critical so that engineering teams can focus on solving the right problems and delivering business value, not having to make decisions that belong outside their immediate brief. With the correct architectural engagement, teams can deliver services that mesh correctly, utilise shared services effectively but still work autonomously, i.e. without constantly having to liaise with other teams or wait for them to deliver dependent functionality.

What is an Architecture Practice?

It’s common in many organisations to find a dedicated architecture team or practice with responsibilities that sit outside the day to day software delivery process. The work of this team is typically to determine the best technology enablers to meet business needs; to advise on build-vs-buy decisions and select appropriate 3rd party products and services; maintaining technology service catalogues such as applications, databases, integrations and system configurations. The architecture practice will often compile policy documents and guidelines, and define a set of core principles for the IT function to adopt.

Unfortunately, this modus operandi of ‘architecture’ isn’t very well suited to the degree of business agility that digital transformation needs, especially when the architects are used to working in an organisation that lacks any form of internal engineering capability.

If we strip back the core being and motivations of technology architects, we find that underneath an often perceived bureaucratic facade there sits an essential purpose, which is to think of the IT services supplied to the enterprise not just in terms of the functionality that is provided, but in terms of the way in which it behaves. We can describe that behaviour in terms of Quality Properties.

Architects are the custodians of the Quality Properties of the organisation’s technology function.

Quality Properties

Quality Properties are characteristics such as: Reliability; Resilience; Security; Maintainability; Deployability; Operability; Usability. Whether they do this explicitly or through application of experience and knowledge, architects strive to ensure that these qualities are addressed in sufficient measure, and we can quantify this in terms of Quality Property Metrics. We can then use these metrics to help articulate Non-Functional Requirements (NFRs) which is a familiar language to engineering teams.

Defining NFRs in terms of Quality Property Metrics

The diagram below shows how Quality Property Metrics can be used to define NFRs, and in so doing explain why Architects are so keen on policies and guideline documentation.

Quality Properties, Metrics and NFRs

This approach ensures that the work architects do as guardians of quality properties becomes relevant to engineering practices. An agreed list of quality properties forms a checklist that business analysts can use to liaise with business stakeholders to capture non-functional acceptance criteria using pre-defined metrics and target values. These well-defined NFRs influence design decisions taken by engineering teams, help shape test automation performed by quality assurance engineers, and clarify the underlying metrics for KPIs and instrumentation for IT operations to monitor.

Continuous Architecture

Continuous Architecture is an emerging discipline that brings the architecture function closer to the agile delivery process. An important first step is the shift in emphasis on quality properties, addressing the need for a ‘whole picture’ view in the way that digital transformation brings technology into the DNA of an enterprise. The intent is to ensure a balanced approach to technology that not only addresses established qualities such as reliability, resilience, performance, efficiency and so on, but also those that result in a shorter time to market for products and services.

More can be said on the topic of Continuous Architecture, but we’ll save that for another time.

Summing up

This article was about highlighting the tension and frustrations that often surrounds traditional architecture teams when business agility is called for, especially interactions with software engineering teams. But, thinking in terms of Quality Properties and expressing these as metrics in non-functional requirements is a good strategy to counter this, and one we’ve seen work well. Making the right architectural decisions is critical for all businesses (you ‘live with the results’ for a long time) yet, faced with increasing urgency to ‘act’, attention to more strategic thinking for the long-term is difficult. This is the role of an Architecture function, and an important one that companies should not forsake.

Check out the rest of AgileBeyondTech

This edition is part 4 of our AgileBeyondTech series. Check out its predecessors here:

• A TEAL Organisation Built on Agile Foundations
• Agile Transformation Part 1 - Setting the Foundations
• Agile Transformation Part 2 - Execution