Agile Architecture

Agility is a central requirement for many organizations and agility is also impacting the way we, as (IT) Architect's work. We work in an agile way to drive change that creates business opportunity through technology innovation. We will shape and translate business and IT strategy needs into realizable, sustainable technology solutions, whilst taking end-to-end solution delivery ownership from idea to benefits delivery.

Being able to respond to change means, that we do not longer create a Big Design Up Front (BDUF) where we define an architecture to be realized over a long period.

Instead, the architecture design in an agile context :

• provides the vision (intentional architecture) where the teams fit in with their (development) work,
• gives the guard rails between which the agile teams make their own design decisions (emergent architecture),
• shows where teams need to connect to ensure interoperability between systems/services (solution architecture),
• provides guidance on generic services and tooling

So, agile architecture should break up the solution in pieces of work that can be taken further by different teams. Ideally, agile architecture also enables designing for testability, deployability and releaseability. 

One common challenge when designing an architecture is that it is easy for it to become an end in its own, rather than something that is there to help the business. As a result, it can be difficult to assess when to stop “designing the architecture”.

In fact, the reality for most businesses is that, due to inevitable cost and time constraints, changes to business objectives or strategy mean that the architecture will rarely be 100% complete, perfect, or even fully achieved. Most of the time an architecture represents the aspiration (or target to reach) and provides the support framework to make decisions along a journey. The deciding factor revolves around when the Architecture is “good enough” for its scope and objectives to ensure that results deliver expected business benefits.

To assist our 10,000+ architects across the Capgemini Group, we defined the notion of JIT-JEA (just in time – just enough architecture). The idea is that the architect will work with the agile team(s) to deliver:

• just good enough architecture
• just good enough documentation
• just good enough governance
• just in time and
• in iteration-size chunks

 

To define “what is good enough”; to outline and articulate the level of detail and therefor the amount of architecture related material is needed, the following JIT-JEA related 10 principles can be defined: 

1. Understand the As-Is; if there is an As-Is make sure you have a view across business, data, application and infrastructure what is currently installed and what will most likely change (not needed for complete green field)
2. Understand context; Understanding of the Business (and IT) Context, including external facts (regulation, etc.) that may affect the results.
3. Define principles; Formalized and traceable Business Objectives and Principles, driven by the Business Mission and Vision.
4. Know the requirements; Understanding and / or delivering the functional and in particular the key non-functional requirements.
5. Record Decisions; Documenting the rationale for all Architectural and Design Decisions, ideally reflecting the Principles/Business Needs.
6. Ensure traceability; Providing clear traceability back to the Business Objectives within the Architecture
7. Develop solution; Document the Solution(s) incl Investigate Solution Alternatives to ensure that decisions are made in a holistic manner and not in isolation.
8. Assumptions and constrains; Capturing, validating, and managing any assumptions and constraints that affect the Architecture.
9. Risks and issues; Proactively document and manage risks and issues, both of the process as well as the results.
10. Plan; Have a clear and sensible plan / roadmap to achieve the desired business outcome(s).

The reason why we have (or better) need an architecture is to manage risk and cost. And as per the 10 principles suggested above, this is mainly about ensuring that the solution will meet the expected outcomes. 

Using architecture frameworks like the Open Group’s Architecture Framework (TOGAF 9), Capgemini’s Integrated Architecture Framework (IAF) as well as getting help and support from the various Communities, ensures that our architects are able to deliver JIT-JEA, by providing the necessary structure and architectural artefacts together with documented best practice, in an agile fashion.

Thanks for Reading

---