Weekly Note 447 – Architecture function in an agile context Part 1 of 2

This week (and next) I will focus in on the way we organise and structure architects when developing agile
solutions across a product based operating model.
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 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, client expectations are
changing and so is the market. Now more than ever, our clients 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 need to respond to change, at an ever-increasing frequency.
The past
A product-based approach is a major shift from how we “used” to be organised – separate and 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:

Change = Yes please No, no change please

Design Development SIT UAT OAT Live

Compute

Storage

Network
 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.

Our understanding of the evolution of speed and agility within the IT

organization towards agile product orientation
Project oriented culture The DevOps oriented Organization The Business driven IT Organization
1 The aligned structure 2 - The asynchronous structure 3 In sync towards the client

CIO

Client Client

VS
CIO
Classic DevOps

PRODUCT DOMAIN

PRODUCT DOMAIN
Department Department
Plan

Build
Function Function

Platforms
Run

Project Project Project

Operating Services

▪ Project based solution approach ▪ End user facing systems seek for flexibility ▪ End-user facing systems seek responsiveness
▪ Plan/Build/Run aligned organization ▪ Integration of Business fosters alignment ▪ End-2-End Alignment and Processes
▪ Agile Methods to speed up Run Organization ▪ Different speeds by application ▪ Aligned speed by value stream

IT solution in this context relates to a specific service like HMRCs Public facing products: Ways to Save
(mobile), Capital Gains Tax (web), Payments, Collections, Receipts, Registration, and many PODs that focus on
specific services will form / support a business process.
As many PODs / 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 POD every team
member will work and relate to his/her peers. Some will have a business focus whilst others will tend more
towards technology (see a short definition of a POD later in this blog).
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 across our client landscape. 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:
 Digital & IT Strategy Governance Enterprise Architecture
Balance of power
is a central idea of the operating model that enforces
Practices collaboration
Group 1 Group 2 Group 3 …
Consulting Architecture Cloud
Budgets
are driven by customer demand and allocated to solutions
and benchmarked IT products
Projects
Business Solution IT Product 1 (Change)
Resources
B2B Sales Order Portal Services
(Operations) mostly reside within Practices – solutions and products are
staffed lean
Business

Partners
Projects
Business Solution IT Product 2 (Change)

B2C eCommerce CRM Services

Resource management
(Operations) supports transparent and dynamic staffing based on
capabilities and demands
Projects
IT Product 3 (Change)
…
User Account Services
(Operations)
Scalability
is ensured through global provisioning of required in-
external capabilities
Resource Management Supplier Steering Financial Management
End-to-end delivery accountability
Architect Roles
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. This applies to any type of architect:
• Enterprise Architect: details the structure and relationships of the Enterprise, its business models, the way
an organisation will work and how and in what way information and IT will support the organisation’s
business objectives and goals
• Business Architect: defines the integrated structure of the overall business itself (in terms of organisation,
people, process, and resources)
• Solution Architect: defines an architecture for a specific solution, whether this be business or IT. Note that
“solution architecture” is often used as shorthand for “solution IT architecture” and is sometimes referred
to as “project architecture” or” IT architecture”.
• Data Architect: defines and describes the structure, standards, guidance and relationships of the
information objects and their relationship with other objects within a specific solution or the enterprise.
• Infrastructure Architect: focuses mainly on the non-functional characteristics of a solution. It outlays all
infrastructure related components needed to fulfil the non-functional requirements such as (but not
restricted to) availability, stability, security, scalability, operability, and extensibility.
• Governance Architect: defines not only the traditional IT Systems management capabilities, organisation,
and systems, but also addresses business governance (how to manage the overall business processes, formal
and informal) as well – critical in these days of increasing business regulation and compliance.
• Security Architect: defines not only traditional (ie firewall, proxies, etc) IT security but also addresses
business and information security, as well as the resulting organisational and business-related services to
deliver the required security.
An example organisational structure (conceptual model)
Organisations do implement the product based and agile organisational structure in various ways. However,
there is typically a separation between group global (for a large and global organisation), the region, the line of
business and shared services. The below is an example taken from a large and global manufacturing company :
In this example:
• Line of Business: Leads, designs, and delivers IT Change, Owns all IT capabilities for the LoB
• Line of Business IT: Provides LoB IT specific capabilities, runs & manages shared IT demand
• Shared IT: Provides all shared IT services capabilities to all LoBs
• Group IT: Owns Group wide IT, sets overall standards and policies

This is the End of part 1: I will continue next week on this subject to dive more into the architecture function
and the way architects work in an agile and product-based organisation.