agile enterprise architecture: a step change is required

10 June 2009 1www.AgileEA.com and

Process.AgileEA.com

Agile Enterprise Architecture:A step change is required

Charles EdwardsVersion: 1.02

Date: 10 June 2009

10 June 2009 2www.AgileEA.com and Process.AgileEA.com

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!


What is “Agile EA”

(Open source EA)


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 components10 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)


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

04/21/23 www.AgileEA.com and Process.AgileEA.com 8

AgileEA - Where?

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


• Use in one of three scenarios:

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


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


What are theseStep Changes?


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


Agility & Adaptive-ness • Traditional EA approach Takes too long to deliver value

– Long (months and years), – Structured (framework, serial) – Very rigid (project plans), – Cannot adapt to change (because of above points)– Business become impatient and terminate efforts.

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


Slow. Unstable under quick direction change.

Excellent Speed. Able to direction change quickly.

Pragmatism & Urgency


http://www.pragmaticea.com/frameworks.htm

• Model of the structure

Structure & Rigour


• AgileEA is split into 2 groups of Architecture Views– Enterprise Architecture View and – Software Project Architecture View

Structure – Multi Views & Viewpoints


Enterprise Architecture Views

Project Architecture Views

Integration – ideas & tools


Actionable Enterprise Architecture – not just Diagrams and Models of Architecture, but Workflow, Risk, Change control & Governance of Architecture, with Architecture Business Intelligence.Backed by databases of related text.

UML, Archimate

Risk

Workflow & Change Control

Architecture Business Intelligence

Openness• Collaboration & Sharing of ideas openly• Scaffold - to implement new concepts & ideas within• Neutrality - without

– Intellectual Property and – Financial issues


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


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.


Practical Experiences

Strengths & Weaknesses of EA


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


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


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


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


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


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.


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


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


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


Wrap up


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.


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"


agile enterprise architecture: a step change is required

Documents

eclipse process framework

good ea

agile ea open source

agile ealook

blend of agile adaptive

enterprise architectsquick

time work

peersat work