A Cookbook for Smart Enterprise Architecture Practices

12 June 2013

Rik Farenhorst

EAC2013 conference, London, UK

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

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

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

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

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’

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

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

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

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

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]

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

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

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

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

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

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

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

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

Apply

© inspearit 21

Phase 2 Reaping

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

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!

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