If everything is under control – you’re going too slow – Mario Andretti
Enterprise Architecture has come into its fair share of criticism in the last decade or so – and some would say that its relevance has waned with the rise of agile methods to mainstream business practice.
The long-awaited but ultimately underwhelming release of The Open Group Architecture Framework (TOGAF) 9.2 has done nothing to diminish the unhelpful often real stereotype of the ‘ivory tower’ Enterprise Architect seated in a back corner of IT producing box and line schematics that few others comprehend or find a use for - which sits in stark contrast to the hive of activity and enthusiasm typically surrounding DevOps agile initiatives with regular product increments, stand ups, and regularly released minimum viable products that are transforming the organisation’s technology environment and capacity to do business.
The time of the ‘dungeon’ - ‘boxes and lines’ Enterprise Architect was up long ago; and so too the delivery process that sees architectural deliverables developed over months of deep analysis which are ‘launched’ on an ambivalent business as the roadmap for the organisation to realise its goals; only to be largely ignored or at best perhaps seen as a means of acquiring future capital funding.
In this article we offer of few observations on trends that are emergent across our clients that maintain an active Enterprise Architecture capability within an agile environment. We feel that the tide is changing and it is possible to deliver agile architecture provided you are prepared to make some profound changes.
The term ‘Agile Architecture’ has become popularised within the Scaled Agile Framework (SAFe 4.5) and essentially is defined as a means to achieve the balance between agile team emergent design and longer-term architectural intent. It deals with the issue of how to both promote iterative customer centred solution design while also ensuring that what is delivered aligns with other dependencies (e.g., chosen technology platforms, overall product strategy etc.) and longer-range business goals.
To be fair, the TOGAF Architecture Development Method (ADM) with its ‘re-entrant’ phases can claim to be an iterative process, and not a strictly sequential ‘waterfall’ pattern for the architecture delivery. However, the actual process for delivery – defined as a sequence of steps within each phase, together with the emphasis on architecture documents and artefacts rather than outcomes, and even the certification exam itself has only reinforced the focus on the ‘tools’ and prescribed sequential processes rather than meaningful business outcomes and business decisions enabled by highly targeted ‘just enough just in time’ minimal viable architecture. In the Open Group’s defence, they have released a preliminary white paper titled ‘Agile Architecture in the Digital Age’ which is an invitation to the Open Group community to develop a new architecture framework.
In nearly a decade since the release of TOGAF 9.1, agile and scrum methods of delivery have risen to mainstream. Furthermore, Design Thinking, and Service Design now provide a compelling alternative to the space that was once solely the prerogative of Business Architecture and business process improvement or business process re-design. The world has moved on and the somewhat euphemistically named workplace trend ‘ways of working’ is now here to stay – arguably meaning TOGAF’s role as ‘the industry standard’ for enterprise architecture delivery is increasingly untenable.
One successful pattern we’ve observed in environments where there are distinct design and agile development teams and where there is inevitably a need for some degree of ‘hand over’ - is the use of a central design authority. In this scenario a ‘Centre of Excellence’ (CoE) or ‘Design Authority’ is established that guides the design process. The CoE plays the role of guiding design stories to a point of maturity and then working with the dev team to implement it. It also plays a role to gauge and provide feedback about the alignment between the original concept and the implemented product outcome of the agile process.
In this pattern the enterprise architecture capability plays a role documenting and playing back the original design concept and its components, and the impact of CoE decisions on the realisation of the original concept.
Where we have seen the successful use of enterprise architecture with design and agile – the overarching ADM pattern is typically retained, however the stepwise sequential processes within each ADM phase have been replaced with something more closely related to design processes popularised by IDEO and the UK Design Council. In addition, the key ‘injection points’ between an enterprise architecture capability and agile dev teams occur just preceding, and near the conclusion of each sprint, usually enabled via a solution architect often as a permanent member of the agile team collaboration.
The activity preceding the agile team sprints is concerned with defining the ‘platform’ that the sprint will ‘run on’ – typically defining sets of standard tools and technology platforms, what SAFe defines as the ‘Architecture Runway’. However, we feel that in practice the scope of the ‘Runway’ needs to include sufficient architectural guidance in terms of overall intent, known constraints and established ‘standard practices’ in addition to the runway elements outlined in SAFe.
The architectural system intent is an implementation agnostic description of system components, together with known constraints and typical behaviour.
The rationale for having such a runway preceding sprints is to both to reduce waste (i.e., reduce agile team time spent reinventing or rediscovering things) and to provide a minimum viable description of architectural system intent ahead of development.
The ‘end of sprint’ role of the embedded solution architect is in part to ensure that an accurate representation of the physical ‘as-built’ solution is captured and mapped to pre-sprint representation. This may mean updating the pre-sprint system intent where the dev team has implemented a better approach and made enhancements or feeding back in the end of sprint showcases where there are departures that might constitute risks within the wider context, or missing features or behaviour to be addressed within the subsequent sprints.
Another evolving framework whose purpose is to balance autonomy of dev squads (i.e., emergent design) against alignment to longer term, broader product strategy (i.e., architectural intent) is the Spotify Model. As a framework it uses a ‘decoupled’ solution architecture to allow individual squads to build, test and release individual features rapidly while minimising risk (i.e., minimum blast radius) and the need for inter-squad coordination. Indeed, taking the time to define a ‘decoupled’ product feature architecture preceding dev team sprints is a key enabler for teams to progress more independently and reduced coordination overhead.
The Spotify Framework also relies on achieving high levels of targeted inter-squad collaboration as well as squad autonomy by using the cultural constructs of squads, guilds and tribes. The Framework uses the concept of ‘minimum viable bureaucracy’ to describe the minimum controls and conventions to ensure adequate coordination while promoting maximum autonomy for emergent design.
Both Spotify and SAFe speak to the need to conceive of a given product in an implementation agnostic way (i.e., logical architecture view) to allow individual squads maximum autonomy to ‘solve’ for each product component for the relevant Product Owner. Such a view helps identify or predict ahead of implementation, those likely critical points of dependency or inter-connectivity between yet-to-be implemented components, instances of siloed or poor business level integration driving suboptimal technology outcomes, and potentially reduces the time spent by squads re-inventing or re-discovering the same solutions.
The architecture needs to span the business, information, application and technology domains to be able to provide the full enterprise context of any given product. This information needs to be available at the right time, in right level of detail to enable agile team decision making.
Lastly, and importantly, it would be a mistake to expect that you can simply take traditional Enterprise Architecture delivery and ‘bolt’ it onto a framework such as SAFe or Spotify – and then deliver architecture at key points in the agile process. The highly collaborative nature of agile delivery, the need for squad autonomy and self-serve, no hand off points, and the concept of minimal viable architecture all require a corresponding change in the way Enterprise Architecture is developed and delivered so that it too honours the principles that are reflected in the Agile Manifesto.
This is an evolving space in which the role, contribution and value of enterprise architecture is emerging and yet to be correctly quantified. We remain committed to the value proposition of Enterprise Architecture as a discipline. Our own approach to delivery is constantly evolving. We would be very interested to hear your perspective on the issue of achieving agile architecture delivery, whether it’s possible and its place in the modern workplace.