Do you really need Architecture Deliverables in Agile Transformation?:

We discussed in a previous article, the impacts of Agile introduction on the Architecture team. In this article, we’ll drill down in more detail on the Architecture and Design deliverables required to effectively govern a large Agile Transformation. 

Introducing an Agile methodology across the whole organisation brings a number of key benefits including:

Business Value comes first
Introduces a Customer-focused Approach
Fast time to market 
Cost Control
Improves Products Quality
Aligns all levels of the enterprise that are involved in solution development
Delivery is predictable and simplified
Simplifies change
Reduces the amount of design required upfront

Often, organisations that use Agile to deliver large transformation programmes come unprepared and have to spend valuable time and effort in redefining processes and artefacts to govern the programme delivery. This is also true for Architecture teams that are used to steer far from delivery activities and spend most of their time in defining roadmaps to their strategic architecture vision. 

When talking about large agile transformations, all levels of the Architecture team should be involved and with different roles throughout the transformation journey.  The  Enterprise Transformation Value Chain has four major domains. Each domain is subject to change and is influenced and influences others. 

Strategy

This is where the organisation objectives are set by Business Executives and the IT directors. Chief Architects and Enterprise Architect work together with business stakeholders to define the Architecture Vision and Strategy. 

Portfolio

Based on the initially defined strategy, different change initiatives are planned. Chief Architect and Enterprise Architects are directly involved in shaping the Enterprise Change Portfolio defining portfolio roadmaps. Enterprise Architecture roadmaps should align with the sequence of Programmes and Programme Releases in the portfolio.

Delivery

When a Release is in the delivery phase, Epics (high-level scope elements), are analysed and refined in user stories. The architecture and design to delivery the solution is identified and documented. The code is developed, tested and deployed.

Service

Agile organisations aim to build a “Continuous Delivery Pipeline” that keeps deployed systems continuously evolving. When a solution is Live, product features might not meet the expected business outcomes (because of lack of performance or delivery defects). In this case, they are identified for improvement and fed back to previous phases of the transformation value chain for further analysis and replanning. 

We are now going to discuss in more detail each of the deliverables the Architecture team should own for each phase in the transformation value chain.

Strategy Architecture Deliverables

Architecture Vision

The Architecture Vision aligns business goals and strategic objectives to new and existing capabilities address the stakeholder concerns when implemented.

Architecture strategy 

The Architecture Strategy matches business strategy with objectives that require a change to business and system capabilities together with an implementation roadmap. 

Portfolio Management Architecture Deliverables

Roadmap

A Roadmap lists a set of Milestones that communicate planned Solution deliverables. It can often include more than this and link Business, Data, Application and Technology aspects of the solution together with Investments and planned activities. There are different types of roadmaps and can be seen at Enterprise, Domain (group of applications) or Application level. 

Release Architecture

A Release Architecture defines the set of Applications and logical interfaces required to support a Release. It is usually based on a set of assumptions and high-level scope items (Themes and Epics) and it requires refinement throughout the Delivery phase. 

Enterprise Architecture repository

Large scale enterprises create a huge volume of architectural output that has to be governed, organised and should be leveraged-on. To make this a worthwhile effort, an organisation should adopt a common taxonomy and an effective metamodel to represent and store architecture and design artefacts. 

The adoption of a reputable Enterprise Architecture tool is a mandatory step to establish a successful Architecture practice. 

Our partner Bruhati developed a simple and effective framework called Architecture, Design and Delivery Framework (ADDFtm) that offers a common metamodel that can be used to effectively manage enterprise architecture and design artefacts. This framework is tool-agnostic and can be deployed within the tools your organisation is already using. 

Delivery Phase Architecture Deliverables

Process Assurance 

The Architecture and Design team should ensure that business processes are consistent and if supported by Systems, confirm reference system names.  

Data Entities impacts 

As the delivery work progresses, Epics and User Stories are refined. This refinement process should also happen for Data Entities and their new/modified Data Attributes required to deliver the Epics and User Stories. 

Application & Interfaces impacts

As for Data Entities, Impacts to Applications and Interfaces that are required to deliver new Epics and user stories should be identified. 

Dual Run impacts

In large digital transformations, there usually is a need to keep track of Legacy and New IT stacks. Defining a dual running strategy, a set of patterns and identify applications changes to operate a dual-stack is paramount for the success of the transformation. 

Migration Impacts

Migration Approach and Designs are usually overseen by the Architecture team. 

NFRs impacts

The identification of non-functional requirements is often underestimated and left for a later stage of the delivery (if ever fully considered). Particularly within an agile delivery, non-functional aspects of the solution should be considered while analysing user stories within the scrum teams (also called squads). 

Acceptance Criteria

Business Analysts capture Epics and User Stories but Architects and Designers must ensure that their Acceptance Criteria are measurable and technically sound.

A&D framework

This is a fundamental step in a successful transformation, the definition of tools, processes, templates, metamodel, and taxonomy that will be used to model and document the Architecture and Design of the solution. Our partner Bruhati developed a simple and effective framework called Architecture, Design and Delivery Framework (ADDFtm) that offers a common metamodel that can be used to effectively manage enterprise architecture and design artefacts. This framework is tool-agnostic and can be deployed within the tools your organisation is already using.  

E2E traceability

Scope traceability (ability to link Themes to Features (capabilities), to Epics, to user stories, to Design Artefacts and ultimately to the code delivered in production is of great importance as it provides an insight into the requirements coverage and ensures that all stakeholders expectations are met. 

E2E Architecture and Design

This is a document (or a view in an EA tool) that provides a snapshot view of Business, Data, Application and Technology architectures for the release. It provides a joint view and is an open document that lives through the whole release and gets completed after the last user story is completely refined. It’s the reference point for the whole set of stakeholders involved in the release.

Domain Designs

Applications are grouped and organised by Domain. Each domain should have his design, that will deliver a detailed view of the impacts to all applications in the domain concerning the epics in scope. It must be aligned to the E2E design. 

Live Service Phase

Continuous delivery offers the opportunity to quickly measure impacts of newly introduced features on business performance and pivot, whenever required, to optimise products and services. The enablement of this feedback loop can be enabled by the introduction of continuous monitoring of business performance. 

Ready for Scale

It is not uncommon that delivery constraints and tactical solutions impact the ability to deliver software that can scale to the required volumes. After Go-Live, Architects should continue supporting the transformation programme assessing the readiness to scale up the live service and advising the correct remediation actions when non-functional and compliance requirements are not met.

Service Performance

It is best practice to include performance testing at least as part of each release. It is important to find the optimum velocity, this can be achieved sharing testing responsibility across the end to end delivery life-cycle. Performance problems, if identified late in the delivery process, can cause serious delays and rework.

As you can see, implementing Agile Architecture requires a lot of effort that translates to a delay in the ability to effectively support the delivery of a digital transformation. Adopting since the beginning of the transformation journey a set of tools, processes, templates, a metamodel, and a taxonomy that are proven and based on industry best practice is the only way to avoid delays and increase the large risk that transformations inherently already carry.

Introducing Agile in an organisation should be seen as a journey. When Agile is wrongly implemented it can take a toll on the organisation’s ability to deliver efficiently. Our partner Bruhati are experts in implementing Agile in organisations, leading the Architecture team of organisations undertaking large digital transformation.

For more information and a FREE consultation please visit www.bruhati.com or contact sales@bruhati.com.