By Gunnar Menzel
Agility is a central requirement for many organizations. For organizations looking for a digital future, the question is no longer whether an agile innovation should be used, but which innovation, when, and how. Questions they ask themselves include:
How to incorporate agility into the 2023 digital development plan and operating landscape?
What steps would accelerate digital transformation?
How best to architect[1] in an agile way?
At its core, the term “agile” refers to an iterative, incremental method of managing design and building activities with an aim of developing new products in a highly flexible and interactive manner. “Agility” is our ability to sense and respond to change both adequately and in due time, while “Agile” is the myriad of tools and techniques to help us achieve agility. As noted in our 2019 “Agile at Scale” report, companies are starting to adopt and scale agile ways of working, changing the way they work. And this change is also impacting the way we, as (IT) architects work. We are living in a complex and fast-moving world, ever gathering pace. What was acceptable yesterday, will not be accepted tomorrow. Our world is shifting, customer expectations are changing and so is the market. Now more than ever, end users expect their IT function to seamlessly support the business as we see the lines of business and technology blurring beyond recognition. As a result, we need to change and adopt new ways of working; we architects need to respond to change, at an ever-increasing frequency.
The past and today
A product-based approach is a major shift from how we “used” to be organised – in silos, where the business is separate to the development teams who are also separate to the operational teams. The typical (however, not always) result is slow, expensive and error prone deliveries:
This is in contrast with the product-based structure. The main idea is that you create a dedicated team that deals with strategy, design, build, test, implement and operate related to a particular IT solution / service.
IT solution in this context relates to a specific service end user facing products: Payments, Collections, Receipts, Registration.
As many product teams exist along a common business process they will have to connect / communicate and align with each other. Typically, each role will be organised in a set of practices like business analysts, architects, developer, project manager, service delivery manager etc. Within each team every team member will work and relate to their peers. Some will have a business focus whilst others will tend more towards technology.
The new conceptual model
One main effect of this change is that an architecture organisation looks different to what it used to be. The shift from waterfall to agile has changed the way architects are organised. In principle the main difference is that IT is not a backoffice capability anymore; IT is part of the business, shaping, developing, and contributing directly towards a business outcome. Today, organisation’s structure themselves around business focused products or services:
Focusing in on the change aspect (so where additional or new functionality is being provided) organisations mainly centre their structure today around a POD model. The key idea is to form independent teams that owns a particular business service (like payment, validate customer, offer booking slot etc) from strategy to operate; a POD follows the main concept of: “you built it, you ru(i)n it” (why ruin? – because it’s your service, so if you mess it up its your mess to sort out).
The architect in an agile context
And this has an impact on the way the architect’s team is organised. In an agile and product-based organisation architects will work in PODs as well as provide guidance, standards, blueprints plus advise and govern projects and programs. Working across all areas (business, data, apps, infra, security, etc) architects will be involved from inception to operation.
Overall, Architects will:
- provide the vision (intentional architecture) where the teams fit in with their (development) work,
- establish the guard rails between which the agile teams make their own design decisions (emergent architecture),
- show where teams need to connect to ensure interoperability between systems/services (solution architecture),
- guide generic services and tooling,
- identify design hotspots upfront (e.g., specific to some demanding non-functional requirements) which need to be tested early in the development for example with proofs of concept.
Typically, architects work directly in PODs, however, are organised and structured in a single practice, related to a community and assigned to a POD / PODs :
- Practice
- An organisational structure that covers all architects and is independent of the business layout
- Is led by a single Head of Practice reporting to the (Group) CIO
- Ensures that any architecture demand is being met
- Community
- Grouping of type of architects related to a particular subject
- Drives collaboration, patterns and standards, tools, and techniques
- Assignments
- Most architects will be assigned to project and/or project related work
- Focus on designing, developing, and delivering solutions
- Working with BSO (business service owner) and BRM (business relationship manager) to exploring new architectural opportunities to better service the new business needs
Summary
Agile architecture is the art of designing and delivering the “right” solution – meeting the requirements, expectations and demands of the customer – whilst being able to respond to change in an uncertain environment. Responding to change means that architects can no longer create a “Big Design Up Front” (BDUF). This also means that architects cannot live in an ivory tower, separate from the business. Architects must get closer to the developments, providing more visibility on the details without losing the broader view, vision, and strategy. Doing so allows the architects to learn from every sprint and receive feedback from development team.
[1] To avoid confusion with other professions, whenever we use the term, we are referring to Business and IT (Information Technology) architecture and Business and IT architects.
Driven by business impact, passionate about technology and focused on real outcomes, Gunnar Menzel has successfully led multiple €500m+ Global Accounts, Programs and Projects as CTO, Chief & Enterprise Architect as well as Head of Architecture. With a total of over 6000 Architects, he is one of only two globally certified Master Architect and IAF Master across Capgemini Group. Menzel works directly with customers, enabling business driven IT transformation, covering sales to delivery across multiple sectors and technologies. As a certified Master Architect and IAF Master, he is a member of Capgemini’s Global Architecture Board and as a senior leader within Capgemini’s Global Architecture Community, Menzel plays a key role in the direction of the architecture profession across the Group and developing its future talent.