Weekly Note 450 – Architecture function in an agile context Part 3 of 3

In #447 and #449 I started to outline how an agile based architecture team could be organised. This week I will
complete my 3-part series with a closer look at how in practice this might look.
Focusing on the interaction between the business relationship manager and the business service owner and
the enterprise and solution architect, the following key activities summarises the focus for each key
stakeholder:

Line of Business / Line of Business IT Architect Practice

Business Business Service Enterprise Solution

Relationship Manager Owner (BSO) Architect (EA) Architect (SA)
(BRM)

\\\\\\\\\\\\\\\\\\\\\\

• Owns the relationship with senior
business stakeholders – engages on LoB-
tech. strategy and demand, service
performance & value-for-money
• Part of the business-technology strategy
process - converts LoB strategy, plans and
objectives into high-level requirements
for the LoB IT organisation
• Leads one of the Solution Delivery Hubs,
aligned to a specific part of the LoB (for
instance R&D, Engineering or
Manufacturing)
• Develops the storymap for certain
features
• Initiates the setup of a POD(s)
• Senior Service Manager with extensive
service delivery experience and the ability
to engage senior business stakeholders
• Plays a dual role in the Service Delivery
team:
− Accountable for all IT service delivery to a
specific part of the LoB
− Owns a specific sub-set of the LoB IT service
portfolio
• On a day-day basis, works closely with:
− a/the enterprise architects to assess and
understand effort, impact and risk profile
of suggested change
− the other BSOs, TSOs and technology
partners (Service Integration) to guide and
govern service delivery
• EA facilitate the alignment of business • The SA will build the architectural runway
and strategy, enabling visibility and with the EA as well as BSO and BRM
validation of strategic opportunities via a
• Together with the EA, the solution
common framework that can be used to
architect will assist BSO and BRM with
achieve consistent investment decision-
exploring new architectural opportunities
making
to better service the new business needs
• EA will work with the BRM and BSO to
support the formulation of change
• SA work in cycles (matched with the cycles
of the Product Owners per POD) with a
initiative proposals, the business case as
board, stand-up meetings and
well as providing expert knowledge of the
retrospectives
opportunities and benefits available, and
the dependencies and priorities between • SA will work as part of a / the POD(s) to
proposed change initiatives design, develop, and deploy the
solution(s)
• EA will support the planning &
prioritisation of business and technology
projects, providing guidance on the
impact and implications of proposed
change

The above scenario only focused on a subset of responsibilities and involvement of architects, namely
engaging with the business relationship manager and the business service owner.
Overall layout of an agile based architect’s organisation
Next to the POD layout and the operating model across the business areas, the overall layout of an agile
based architect’s organisation is based on three main components:
• Practice
o An organisational structure that covers all architects and is independent of the business
layout
o Is led by a single Head of Practice reporting to the (Group) CIO
o Ensures that any architecture demand is being met
• Community
o Grouping of type of architects related to a particular subject
o Drives collaboration, patterns and standards, tools, and techniques
• Assignments
o Most architects will be assigned to project and/or project related work
o Focus on designing, developing, and delivering solutions
o Working with BSO and BRM to exploring new architectural opportunities to better service
the new business needs
 Practice Head Line Manager, Payplan Manager

Chief of Staff Manages overall Team, recruitment

Community Career Process Patterns Tools
and and and and and
Collaboration Talent Methods Standards Techniques Ops Manager Manages day 2 day incl assignments

Resource Manager Manages supply and demand

Knowledge Manager Manages Community and LoB related knowledge

Architect Group Community* focus on subjects

related to:
• standards and blueprints
• capabilities and competencies
• governance and assurance
• culture and strategic thinking
• content to be used by the PODs
Lead Business Lead Solution Lead Data Lead Integration Lead Security Lead Cloud Lead Governance Lead Platform Lead Enterprise
Architect Architect Architect Architect Architect Platform Archi. Architect Architect Architect

Architects permanently assigned to a Shared

Service and / or LoB*:
• designing, developing, and delivering
solutions
• working with BSO and BRM to exploring new
architectural opportunities to better service
Business Solution Data Integration Security Cloud Platform Governance Platform Enterprise the new business needs
Architects Architects Architects Architects Architects Architects Architects Architects Architects • creating and retaining As-Is knowledge to
support future changes

* Dependant on size of the organisation

This model is like the way we are organised; like in our BTS organisation (business technology solutions) which
has various capabilities including architects where we assign each to a client project generating ARVE
(Assignment rate vacation excluded). And for clients that follow a full agile and product-based model this is not
dissimilar when it comes to their architects. Architects are organised in one practice, structed in communities,
and assigned to projects and programs that are implemented as PODs.
Summary
Agile architecture is the art of designing and delivering the “right” solution - meeting the requirements,
expectations and demands of the client - while being able to respond to change in any 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.