Despite the maturation of the discipline, in many organizations Enterprise Architecture is not applied very effectively, mostly because using structured methods and frameworks is preferred over communicating business value and smart planning of IT investments. The various EA frameworks (e.g., TOGAF) that have been proposed over the past years definitely have their merit, but they also seem to seduce architects to focus on blueprints, elaborate process definitions and ivory towers. Architects simply need to work smarter to be of added value. Based on experience in numerous EA projects and EA trainings delivered in the Netherlands, in this presentation a cookbook for smart EA practices is proposed. The cookbook, which is inspired by success stories from the trenches, adopts and adapts elements from contemporary EA frameworks and other methods, (e.g., stakeholder management, architecture visualizations, business model canvas), and as such provides a step-by-step guide for building or professionalizing an EA function.

2. A Cookbook for Smart
Enterprise Architecture
Practices
12 June 2013
Rik Farenhorst
EAC2013 conference, London, UK

3. About me
Rik Farenhorst
Manager Business Line Architecture & Strategy
inspearit / cibit academy
rik.farenhorst@inspearit.com
http://www.linkedin.com/in/RikFarenhorst
inspearit
- 170 consultants in 6 countries (Europe, Asia)
- Core expertise: Enterprise/IT architecture,
Business IT strategy, Process Improvement (e.g.,
Agile, CMMI), Security & Risk Management
- cibit academy as international brand for training
services. In the Netherlands we are market leader in
enterprise/IT architecture trainings
- Extensive experience in consultancy, coaching and
training services in enterprise, IT, and solution
architecture in the Netherlands for > 20 years
(primarily in Public, Finance, and Industry domains)
www.inspearit.com
www.cibit.nl

4. Outline of this presentation
1. Enterprise Architecture – observations from the trenches
2. EA cookbook - improving the status quo
3. Using the cookbook
4. Conclusions & Outlook
4

5. Disclaimer
Several schools of thought exist for EA discipline
EA vs. EITA
My working definition for EA (Gartner):
The process of translating business vision and
strategy into effective enterprise change by creating,
communicating and improving the key requirements,
principles and models that describe the enterprise's
future state and enable its evolution
This presentation is by and large EA-definition-
independent
the cookbook focuses on core activities needed
and essential competences and behavior
required of any type of ‘enterprise architect’
5
© N. Malik, 2012

6. EA observations from the trenches:
Ad hoc Architecting
6
Typical symptoms
Enterprise architects often lack control on how they use their most
precious resource: their own time
No ‘play or pass’ guidelines
No proactive stakeholder involvement strategy
No proper project portfolio management practices established
Lack or reference architectures and enterprise/domain-level vision
Consequences
Architecture efforts are mostly
situational within projects, and are
quite time-consuming
Reactive behavior of architects:
mostly damage control and
answering questions (FIFO) instead
of proactive advice at the right time

7. EA observations from the trenches:
Lonesome architects
7
Typical symptoms
Vague or trivial high-level enterprise architecture
principles
Document/deliverable-driven behavior of architects
‘L’architecture pour l’architecture’, e.g., using TOGAF,
ArchiMate, Tool XYZ, etc.
Ivory tower & ‘gold plating’ behavior
Consequences
Architects are ignored, or only
visited for a signature, and kept
at a distance by decision makers
Lack of useful feedback loops
from either domain/solution
architecture or ‘the business’

8. EA observations from the trenches:
Architecture Islands
8
Typical symptoms
No architecture function or
governance processes to connect
architecture initiatives at project,
business domain and enterprise-
levels
Many (different types of)
architects, diffuse roles &
responsibilities, limited
communication
Consequences
Too little reuse of architecture principles, (IT) assets, architecture
descriptions, etc.
Lack of feedback to architects from peers on their output and ideas
A lot of ‘reinvented wheels’, redundant architecture deliverables with
limited traceability

9. EA observations from the trenches:
IT architecture for ‘the business’
9
Typical symptoms
A lot of business process
modeling, analysis, and
business goals/drivers
discussions within IT
departments
Too much architecture output
that does not resonate with
business executives nor with
other non-IT stakeholders.
Consequences
Architects are perceived as scientists and/or theorists, unable to
get to the point, being detached from the enterprise
Big risk that architecture models and vision are too much rooted
in IT and not based on customer needs, markets, business
strategy, or business value

10. EA observations from the trenches:
Summary
In many organizations Enterprise Architecture is still not applied
very effectively (understatement)
It is almost a reversed Agile Manifesto. Many enterprise architects
still value
Process models and tooling over individuals and interactions
Architecture frameworks, models and thick documents over a
flexible, profitable and customer-driven enterprise
Rigid governance structures and formal roles & responsibilities
over stakeholder collaboration and teamwork
Blueprints, target architectures and roadmaps over the
capability to quickly deliver results and respond to change
10© Agile Manifesto

11. EA cookbook - improving the status quo
To help organizations in arriving at a more effective and value-
driven enterprise architecture function a cookbook is
presented
Based primarily on hands-on experiences at various smaller
and larger organizations
Combined with state-of-the-art EA insights
11
Prerequisites
Eager, flexible architects
CxO-level support
Mature organization
Willingness to change

12. EA cookbook - improving the status quo
Anticipate by identifying where architects can contribute
Communicate with stakeholders and learn more about what
architects could add (and how)
Try things, help only where help is needed, and earn credits
Negotiate about the role and mandate of the architecture
function and strive for agreement on performance indicators
Operationalize the agreed upon roles and responsibilities by
choosing your tools of the trade
Reuse existing (architecture) assets as much as possible
Manage expectations of your colleagues and key
stakeholders
Apply architecture skills and use available toolkits
to deliver value
Learn from your experiences, continuously
12
Phase 1
Sowing
Phase 2
Reaping
[optional]

13. Anticipate
Build up an overview of all change
initiatives and projects
By talking to stakeholders in all layers of
the organization
Ensure that intimate and up-to-date
knowledge on the relevant stakeholders is
gained
Stakeholder maps, stakeholder
involvement strategy, social network
analysis
Who is doing what in the organization,
who knows what, ownership and
responsibilities
13
Identifying where architects can contribute most
Phase 1
Sowing

14. Communicate
Allocate sufficient ‘quality time’ to talk to
relevant stakeholders:
In projects & programs
Decision makers in business units
Board room executives
Operations
Talk, but listen more: know what happens, and
make educated guesses on what kind of
enterprise architecture guidance can be useful
where
Storytelling as effective mechanism to share
the essential parts of the enterprise
architecture
Show architecture work products and learn from
reactions of stakeholders
how is ‘architecture’ perceived and how are
‘architects’ judged, based on earlier
encounters?
14
Learn from stakeholders what architects could add (and how)
Phase 1
Sowing

15. Try
Plan and prioritize architecture work
‘Play or pass’ principle
Focus on lightweight interventions and
activities
Some ‘rules of engagement’:
Just enough, just in time
80-20 rule (Pareto principle)
Visualizations and Powerpoint over (thick)
documents
Pragmatic but effective, tailored to
stakeholders’ needs
Fast delivery, highly iterative
Marketecture to earn credits from important
stakeholders 15
Try things, help only where help is needed, and earn credits
Phase 1
Sowing

16. Negotiate
Define what the EA playing field will be
Agreed upon definition and scope of ‘enterprise
architecture’
Link with e.g. bodies for portfolio management,
strategy, finance and investment planning
Define KPIs for enterprise architecture function
together with sponsors and management
KPI categories: ‘Proof of life’, ‘proof of health’,
‘proof of value’
Craft an EA charter to commit and to focus
cf. preliminary phase TOGAF 9.1
Agree on required resources, budget and scope
People
Processes
Technology
16
Negotiate about the role and mandate of the architecture
function and strive for agreement on performance indicators
Phase 2
Reaping

17. Operationalize
Create an EA toolkit with your preferred tools of the
trade
Frameworks: TOGAF, Zachman, DYA, etc.
Languages: ArchiMate, etc.
Tools: Powerpoint, MS Visio, pencil, whiteboards,
etc.
Standards, reference architecture
Company-specific methods, templates, models,
etc.
Define types of governance needed
Architecture board
Etc.
Define roles & responsibilities
Types of architect roles needed (e.g., enterprise,
domain, project, solution architects)
Architects vs. project and program managers,
domain specialists, business analists, etc.
17
Operationalize the agreed upon roles and responsibilities by
choosing your tools of the trade
Phase 2
Reaping

18. Reuse
Identify existing best practices
What kind of stakeholder involvement works best in this
organization?
What models or visualizations worked well last time?
What are the preferred tools and templates?
Align to and build from existing (architecture) assets
Business capability models, portfolio descriptions, solution
architectures, reference architectures, roadmaps
EA seldom starts as ‘greenfield’, but sometimes things are not
labeled as ‘enterprise architecture’ (e.g. information
management)
18
Reuse existing (architecture) assets as much as possible
Phase 2
Reaping

19. Manage expectations
Create stakeholder maps and a suitable
involvement strategy that is updated
regularly
Make sure that all architects and the
key stakeholders agree upon what
enterprise architecture will deliver, and
what it will not do:
Role during strategic planning and
investment decisions
Role during project portfolio
management
Influence and impact in (IT)
projects
Divide work clearly over members of
the enterprise architecture function,
and assign responsibilities
Think of QA processes needed during
architecture work and feedback
mechanisms required
19
Manage expectations of your colleagues and key stakeholders
Phase 2
Reaping

20. Apply
Put things in practice, start ‘doing’ enterprise
architecture work
Follow established rules of engagement,
execute on defined architecture processes
and smartly divide available time
Use key skills for architects to deliver value [M. Rosen]
Situational use of instruments from your toolkit
Business Modeling
Capability modeling
IT landscape visualizations
Business cases
Baseline and target architectures
Roadmaps
Reference architectures
Etc.
20
Apply architecture skills and use available toolkits to deliver value
Phase 2
Reaping

21. Apply
© inspearit 21
Phase 2
Reaping

22. Learn
Regularly reflect on the performance of the enterprise
architecture function, e.g. using a SWOT analysis
Effectiveness and popularity of work products
Popularity of architects among stakeholders and
coworkers
# of escalations / violations of architecture principles
and decisions
Establish competence development practices at personal
and unit-level
Personal development plans
Importance of certification, standardization,
specialization
Soft skills, architectural knowledge and domain
knowledge
Create an environment where learning is stimulated
Experiment with architecture processes and products
Change approach or tools of the trade when needed
Dare to show draft work products to stakeholders: agile
approach to architecting
Organize architecture roadshows, seminars, knowledge
sharing sessions 22
Learn from your experiences, continuously
Phase 2
Reaping

23. Using the cookbook
Anticipate
Communicate
Try
Negotiate
Operationalize
Reuse
Manage expectations
Apply
Learn
23
Recommendations
1. Use the cookbook pragmatically
As checklist and themes to improve
existing practices, rather than as linear
step by step guide
2. Strive for continuous improvement in EA
function and promote (double loop)
learning among EA professionals
3. Let’s not make too much fuzz about
enterprise architecture (esp. in terms of
why, what, and how)
Just do it!

24. Conclusions and Outlook
The cookbook guides organizations and its enterprise architects
by defining a series of EA activities, and associated best practices
To improve the state of the practice; EA more value-driven
To counter the various EA anti-patterns observed from the
trenches
“The value of EA depends on the influence it has, directly and
indirectly, over executive decisions, actions, investments and
outcomes.” [C. Potts]
The cookbook’s effectiveness in practice depends on
Experience and skillset of the architect
Maturity of organization and EA function in particular
The definition, scope and sphere of influence of EA practices
The cookbook is not a strict step-by-step guide, or a ‘silver
bullet’, nor is it finished
Continuous fine-tuning takes place during architecture
projects, classroom discussions, literature review, discussions
at conferences, etc.
24