5. Form, in architecture, starts in the eye of the beholder… or
in deep processes that transcend human existence
Agile Software Architecture, Alan W. Brown, Muhammad Ali Babar, Ivan Mistrik
Architecture Form
6. An Association for All IT Architects
Architect Driven Digital Advantage
Architects must be at
the heart of the digital
transformation
ADDT
Innovation
Lifecycle
Program
Investment
Capability
Transition
Value
Management
Operational
Excellence
Engagement
Model
11. CONTEXT:
Describe the forces at play, including technological, political, social, and project local.
Describe the tensions & dependencies
Describe the facts as you know them
DECISION:
ADRs are those that affect the structure, quality attribute characteristics, dependencies, interfaces, or construction techniques of an architecture
How do we respond to the forces
We will….
CHARACTERISTICS:
AUTHORITY:
DECISION-OWNER:
Who owns the decision-making process?
DECISION-MAKING PROCESS:
How do we make this decision?
DECISION-MAKING AUTHORITY:
tell, sell, consult, agree, inquire, delegate
ARCHITECTURE DECISION RECORD CARD DOMAIN: DATE: STATUS:
Last updated on 21 April 2018 Download a copy of this canvas at http://www.iasaglobal.org/tools/adrcard
ADR Card Version: 0.1 Designed By: Gar Mac Críosta Agent ∆ for IASA Global
Inspired By: Michael Nygard http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. http://creativecommons.org/licenses/by-sa/4.0
REVERSABILITY
DECISION DURATION
INFORMATION QUALITY
EFFORT (€, people, time)
fully reversible irreversible
days forever
0% 100%
weeks months years
CRITICALITY:
low extreme
OPTIONS:
What options did we consider?
1 2 3
DECISION RATIONALE & CONSEQUENCES:
Why did we choose this option?
Are there any side-effects or impacts resulting form this decision?
13. An Association for All IT Architects
As business ecosystems become further involved they form
ecosystem platforms with multiple interchangeable parts
Co-opetition become increasingly important and the rate of ‘new
entry’ increases
Platform business models require empowerment of others in the
ecosystem
Business Model Challenges
14. An Association for All IT Architects
The customer’s world changes daily even hourly
New tools
New ecosystems
New costs
Customers are involved in pseudo-information expertise
They are bombarded with similar information sources
This results in expectations that often far exceed transactional value
Customer Challenges
21. An Association for All IT Architects
Value Capture In Decisions
Decision
traceability is the
key to
architectural
success
From business to
solution architects
there is a constant
rotation of
ownership and
outcomes
23. An Association for All IT Architects
Program Teams
• Engineering and
Architecture have a joint
opportunity
• There are overlapping
skills and comprehensive
coverage
• Self-Organizing and Self-
Describing
• Architects are responsible
for Form and Structure
• Engineers are concerned
with Structure and
Function
24. 9. It’s not people skills, it is stakeholder management
25. How do we need to communicate with them?
KEY METRICS:
DECISION-MAKING STYLE:
PAINS:
ORIGIN STORY:
STAKEHOLDER
EMPATHY MAP
DATE: VERSION:
Last updated on 21 April 2018 Stakeholder Engagement Map Version: 0.1 Designed By: Gar Mac Críosta Agent ∆ for IASA Global.
Inspired by: Dave Gray - Empathy Map - http://gamestorming.com/empathy-map/
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. http://creativecommons.org/licenses/by-sa/4.0
INITIATIVE:
ROLE:
PERCEPTION:
LOCATION:
POWER:
REPORTS TO:
GAINS:
THINK & FEEL:
What do they think & feel?
SEE:
What do they see?
What information is displayed in
their office/workspace?
What do they read or subscribe to?
How do they read physical
(print)/digital (device)?
Who do they see vendors, analysts,
externals?
hopes, dreams,
desires, aspirations
fears/frustrations
/anxieties
/grievances
SAY:
What do they say?
What catch phrases or common themes are they known
for?
What do you imagine they talk about to friends & family?
What do you imagine they say to peers and bosses
DO:
What do they do?
What does their job involve?
What do they need to be able to do?
What questions do they need answers to?
What decisions do they make?
analytical, conceptual, decisive
GOAL:
What do they need to do?
What are they measured on?
What are they rewarded for?
What decisions do they need to make?
What jobs unsatisfied important jobs to be done do they have?
What will success look like for them? outcomes
KEY
INFLUENCERS:
Who do they listen to?
Who are their key influencers?
formal/informal
positive/negative/
neutral/mixed
INTEREST:
gatekeeper, decision-maker, influencer,
participant, stakeholder
NAME:
TYPE:
HEAR:
What are they hearing from bosses?
What are they hearing from colleagues?
What are they hearing from
consultants/partners?
What are they hearing from vendors?
What are they hearing from the ‘industry’?
ENGAGE:
INITIATIVE ENGAGEMENT STRATEGY:
How should we engage this stakeholder in this initiative
ignore, consult, negotiate, involve, collaborate, empower
informal formal
frequent
regul
ar
chat structure
urgent
INFORMATION EXCHANGE
CADENCE
FORMAT
29. An Association for All IT Architects
1. Solution architects are technical product owners
2. Design emerges but architecture is proven.
3. MVP stands for minimum Valuable product.
4. Healthy tension is good for a team.
1. Decisions are first order objects.
5. You’re designing and ecosystem not a system.
6. Be able to hold competing mindsets comfortably.
7. Decide and maximize quality attributes from the beginning.
8. People skills are not enough in stakeholder management.
9. You don’t get more certainty you get better dealing with uncertainty.
10. Get an engagement model… now.
10 THINGS
Function driven – the great fear keeping us from agile adoption – but also a hint of reality
Resilient software design in a nutshell, Uwe Friedrichsen (codecentric AG) – Software Architecture Conference – London, 18. October 2017
Walk through architect ownership and handoff analysis. The architect is responsible from goal to measure where the traditional IT team is responsible from requirements to delivery test. However the value is generated after usage. That means while IT is throwing parties after deployment the project is at its most expensive and least used for the company. Agile and DevOps attempt to address this specifically with team product owners but the product owners are not technical enough. The team if it stays with its solution still needs the architect involved deeply.