Delivering Agile Architecture Practice

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 software development 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 software development 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 software 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 development process. The work of this team is typically to:

• Determine the best technology enablers to meet business needs
• Advise on build-vs-buy decisions and select appropriate third-party products and services
• Maintain technology service catalogues such as applications, databases, integrations and system configurations.
• Compile policy documents and guidelines
• 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 software engineering capability.

Quality Properties

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 with respect to 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 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 software engineering teams.

Defining NFRs

The following diagram 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. This approach ensures that the work architects do as guardians of quality properties becomes relevant to software 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.

• Read our next AgileBeyondTech article… [ADD LINK TO NEXT ARTICLE]

• Find out how we’ve made our clients more agile…

• Speak to us about adopting agile practices…

Key takeaways

• Tension and frustrations often surround 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.

About the author

Mindera’s Managing Director, Technology Leader and Advisor, Richard Hilsley specialises in strategy, business development and transformation.