10 June 2009
www.AgileEA.com and
Process.AgileEA.com
1
Agile Enterprise Architecture:
A step change is required
Charles Edwards
Version: 1.02
Date: 10 June 2009
10 June 2009
www.AgileEA.com and Process.AgileEA.com
2
Background
• So who’s this
Charles guy?
10 June 2009
www.AgileEA.com and Process.AgileEA.com
3
Today’s Objectives
• Something for all audience types:
– For Enterprise Architects
• Quick understanding of “Agile EA”
• Look at what these Step Changes are?
– For C*Os
• Discuss Enterprise Technical Debt
• The implications of Architectural decisions
– For Industry and Enterprise
• Practical experiences - Strengths & Weakness of EA
• Let’s get some Urgency and Openness into it all!
10 June 2009
www.AgileEA.com and Process.AgileEA.com
4
What is “Agile EA”
(Open source EA)
10 June 2009
www.AgileEA.com and Process.AgileEA.com
5
AgileEA - Why?
• Where did the idea come from?
– Did a TOGAF 8.1 course in 2006 and loved the content
– Left feeling TOGAF needed more (v9 is much better now)
– In general however issues in EA are:
• Structure – missing “easy” Operational Process
• Modernisation – missing Agile, Adaptive, Services
• Integrated tools – not only about visual modelling
• Pragmatism & Urgency – embed EA, add value quick
• Examples – What does “good” EA look like?
• Openness – freely available to all at no cost
• Extendibility – allow for an easier selection of
techniques and plug-in components
10 June 2009
www.AgileEA.com and Process.AgileEA.com
6
AgileEA - How?
• Delivered as a
– Human readable static Website. Not an executable business
process tool.
– Developed using a free open source tool called Eclipse Process
Framework (EPF).
– It follows a rigorous
process meta-model
(SPEM)
10 June 2009
www.AgileEA.com and Process.AgileEA.com
7
AgileEA - What?
• AgileEA is a blend of
–
–
–
–
Agile & Adaptive ideas - taken from software development
Enterprise Architecture ideas from multiple sources
Operational Process for EA's to follow - help introduce and build EA
Build Maturity– to run EA while also maturing EA in an organization
• Crawl
• Walk
• Run
7/28/2017
www.AgileEA.com and Process.AgileEA.com
8
AgileEA - Where?
• Use in one of three scenarios:
1. In a SaaS form – usable
directly off the internet
2. As-is / out the box –
Download, deploy and use
locally
3. Tailor it to suit your Co’s
processes & terminology
Download, tailor and
deploy locally
10 June 2009
www.AgileEA.com and Process.AgileEA.com
9
AgileEA – When?
•
•
•
•
Started in Dec 2006, now 2½ years old.
Part time work-in-progress
New iterative release every 3 or < months
Still in Beta – 2009.0.039 aiming for late 2009.1.000
7/28/2017
www.AgileEA.com and Process.AgileEA.com
10
AgileEA – Whom?
• Loose collaboration with many peers
– At work taking actual day-2-day experiences
– Previous work peers and experience
– Industry collaboration, in particular
•
•
•
•
•
Guy Tozer – Doriq.com
Kevin Lee Smith – PragmaticEA.com
Tom Graves – Tetradian.com
Roger Sessions – Simple Iterative Partitions (SIP)
Nigel Green – VPEC-T
– ±200
registered international users on the site
– Newly formed Linkedin.com forum has ±85 users
7/28/2017
www.AgileEA.com and Process.AgileEA.com
11
What are these
Step Changes?
10 June 2009
www.AgileEA.com and Process.AgileEA.com
12
Step Changes?
To get to the next level Enterprise Architecture needs:
• Agility and Adaptive-ness – speed and time
• Pragmatism & Urgency – Ease of starting & quick results
• Structure & Rigour – What does a “good” EA look like?
• Integrated – concepts & support Tools
• Openness – Bringing all the puzzle pieces together
• Cultural – People & awareness make the change happen
• Architectural implications – Enterprise Technical Debt
10 June 2009
www.AgileEA.com and Process.AgileEA.com
13
Agility & Adaptive-ness
• Traditional EA approach  Takes too long to deliver value
–
–
–
–
–
Long (months and years),
Structured (framework, serial)
Very rigid (project plans),
Excellent
Speed. Able
to points)
Cannot adapt to change
(because
of above
direction change
quickly. efforts.
Business become impatient
and terminate
Slow. Unstable under
quick direction change.
• New EA approach  To benefit from “duality”
– Fix Causes - using a Rigid Structure – Yin
– React to Symptoms - The ability to change direction quickly – Yang
• Build a Structure to accommodate change while in full flow
– Allow Engine to rev faster and go quicker
– Yet stable enough to regularly change direction and win.
7/28/2017
www.AgileEA.com and Process.AgileEA.com
14
Pragmatism & Urgency
http://www.pragmaticea.com/frameworks.htm
7/28/2017
www.AgileEA.com and Process.AgileEA.com
15
Structure & Rigour
• Model of the structure
7/28/2017
www.AgileEA.com and Process.AgileEA.com
16
Structure – Multi Views & Viewpoints
• AgileEA is split into 2 groups of Architecture Views
– Enterprise Architecture View and
– Software Project Architecture View
Project
Architecture
Views
Enterprise
Architecture
Views
7/28/2017
www.AgileEA.com and Process.AgileEA.com
17
Integration – ideas & tools
UML, Archimate
Workflow &
Change Control
Risk
Actionable Enterprise
Architecture – not just Diagrams
Architecture Business Intelligence
7/28/2017
and Models of Architecture, but
Workflow, Risk, Change control &
Governance of Architecture, with
Architecture Business Intelligence.
Backed by databases of related text.
www.AgileEA.com and Process.AgileEA.com
18
Openness
• Collaboration & Sharing of ideas openly
• Scaffold - to implement new concepts & ideas within
• Neutrality - without
– Intellectual Property and
– Financial issues
7/28/2017
www.AgileEA.com and Process.AgileEA.com
19
Cultural & Human
•
•
•
•
•
People love the status quo = comfort zone
People’s reluctance to change is legendary
Simply defining new processes won’t make people change
So why define an Operational Process then?
However –
– Examples always help
– Tangible - what “good looks like” helps people relate
– Re-use – we must stop re-inventing the wheel
– Good cross-ref to EA Frameworks
– Good cross-ref to EA Tools
– Gets the discussion going
7/28/2017
www.AgileEA.com and Process.AgileEA.com
20
Architectural implications
• Do Business people understand the implications
of Architectural decisions?
• The concept of Enterprise Technical Debt
• Enterprise “Karma”
Karma = “causality through a system where
beneficial effects are derived from past
beneficial actions and harmful effects from past
harmful actions, creating a system of actions and
reactions”
• Notion of gathering Interest on unpaid off Debt
& ever mounting loan amounts.
7/28/2017
www.AgileEA.com and Process.AgileEA.com
21
Practical Experiences
Strengths & Weaknesses of EA
7/28/2017
www.AgileEA.com and Process.AgileEA.com
22
Manage - Iterative planning
• Poor – no acceptance except in software
development circles of “iterative” (SCRUM)
•
•
•
•
•
•
Iterative - Very weak where I’ve worked…
Difficult to get interest and enthusiasm
Software “techies” get it – rest do not
Minimal architecture interest in Feedback loops
Too busy fighting fires daily than preventing them up front
Manage Risk by defining mitigating actions
7/28/2017
www.AgileEA.com and Process.AgileEA.com
23
Manage - Governance
• Good – lots of industry marketing
• Using MS Sharepoint Lists / Wiki’s to keep lists of:
– Architectural Decision lists
– Architectural Waivers & Dispensation lists
– Architecture Work Triage lists
– Architecture Principles & Policy lists
– Architecture Standards lists
– Etc …
• Not a lot of EA Tool support for the above items
7/28/2017
www.AgileEA.com and Process.AgileEA.com
24
Manage - People
• Reasonable – general industry understanding
• Tools & processes?
– Architect Work Demand lists
– Architect Resource planning lists
– Ensure roles well defined and hired to fit
– Training lists
• Too much pressure to fire fight – symptoms
• Not enough invested in proactive causes
7/28/2017
www.AgileEA.com and Process.AgileEA.com
25
Manage - Risk
• Reasonable – medium industry marketing
• Some get it, some do not.
• Business users seem far more aware of this than IT
• Using MS Sharepoint Lists / Wiki’s to keep lists of:
– Architectural Risk lists (prioritised)
– Risk taxonomies and categorisation lists
– Architectural Action and Mitigation lists  feeds planning
7/28/2017
www.AgileEA.com and Process.AgileEA.com
26
Manage - Communications
• Reasonable – medium industry marketing
• In Business some get EA, many do not.
• Still way too much emphasis on EA in IT only - e.g.
– Do an IT Strategy
– Then fail to sell it to the Business
– Problems when projects have to adhere to the IT strategy
• Strategic Ownership and Decision making should be at CxO
level not buried within IT.
– Senior business execs should share the Risks and
implications of their decisions
7/28/2017
www.AgileEA.com and Process.AgileEA.com
27
Foundation - Process & Tools
• Poor – EA industry marketing is primarily
concerned with Modelling & frameworks
• Process: is improving (Togaf 9 now in EPF)
• Tools: an awareness of integrated enactment tools is now
emerging
• When will we have a suite of modules to run EA like we have
a suite of ERP modules to run the business?
• An integration of
–
–
–
–
Visual Modelling
Actionable enactment and control of Architecture
Shared information portals, etc
Hooks into BPM tools, CMDB tools, Project management, etc.
7/28/2017
www.AgileEA.com and Process.AgileEA.com
28
Foundation - Configuration Mngt
• Poor – industry marketing appears unaware
• Leave it up to other tools
• Not well understood in general
–
–
–
–
–
Most think CM applies to code only
Most think CM only covers version control
Confusion about Change Control & Configuration management
Automated Release management
CM in ITIL is different to CM for software development
• We need CM for Architecture
– To be able to baseline the Enterprise Architecture
– in monthly or quarterly increments
– Use this to generate Architecture KPI’s
7/28/2017
www.AgileEA.com and Process.AgileEA.com
29
Foundation - Change Control
• Reasonable – medium industry marketing
• Disarray in Architecture from my experience
• Multiple tools – lack consistency
– From Help desks, excel, to ticketing systems, to Visual
models, to BPM to MS Sharepoint lists and Wiki’s
• Multiple processes
– Various lifecycles require various State transitions
– Software delivery change control
– EA Visual Models change control
– Project change control
– Strategy change control (governance, plans, etc.)
7/28/2017
www.AgileEA.com and Process.AgileEA.com
30
Architecture
• Business Architecture Discipline
– Poor but Improving (VPECT-T, SIP, many more...)
– Business are taking their own initiative
• Info Systems Architecture Discipline
– Reasonable in general
– Applications & Data better but only Operationally focused
not Support focussed
– Weak around Services
• Infrastructure Tech Architecture Discipline
– Better
– Often not well modelled however
7/28/2017
www.AgileEA.com and Process.AgileEA.com
31
Wrap up
7/28/2017
www.AgileEA.com and Process.AgileEA.com
32
Conclusion
• For the Enterprise - step changes are:
–
–
–
–
Get Agile - Iterative & Adaptive continuously improving
Get Pragmatic & Urgent – To get results quick & easy
Cultural – People really make the change happen
Communicate – Share the Architectural challenges & risks
• For the EA Industry:
–
–
–
–
Openness – Common framework for all puzzle pieces
Tool Integration – support Process concepts with Tools
Structure & Rigour – Show what a “good” EA looks like?
Educate Business in Architectural understanding –
Enterprise Technical Debt  Implications of decisions.
7/28/2017
www.AgileEA.com and Process.AgileEA.com
33
Thought for the day
• Lean value of Kaizen (literally means "change good").
• For Toyota the immediacy of Kaizen is summed up as:
"We must be noticeably better
than last year...and it's a crisis"
7/28/2017
www.AgileEA.com and Process.AgileEA.com
34