About Enterprise Architecture

© H Tonn 2015 (Slideshare Version) 1

Does this look

familiar?

2

Is this what

Enterprise Architects

are good for?

© H Tonn 2015 (Slideshare Version)

3

If not that, what then?

• What to expect when working with

Enterprise Architects (EAs)?

• Why would you need an EA for your

project?

• What do they do and how do they do

it?

Answers provided

• A simple explanation to the non-

expert.

• De-mystification.

• Setting expectations.

• Explaining the value.


Page 4

The objects of EA

are Elements and

Dependencies.

Let’s get started with

the basics of Enterprise

Architecture (EA).


Page 5

Elements are the things

of the Enterprise.

They can be classified,

structured and

described.

They can be everything

from technical,

organisational to

conceptual.


Page 6

Dependencies are the relationships

between the Elements.

If Elements are

classified,

structured and

described, the

Dependencies become

apparent.

Dependencies need to

be identified to

understand impacts

when one element is

changed.

Elements Depend On Elements

Departments Processes

Processes Documents

Processes Applications

Applications Servers

execute

create, produce

require

are hosted on


Page 7

These are the objects

of Enterprise

Architecture, BUT...

Elements and

Dependencies describe

the enterprise BUT...

... what do Enterprise

Architects<<<<<<< << << << << < << << do with

those?

...just describing the

Enterprise isn’t good

enough.


Page 8

Let’s try an

abstraction.

What if EA was like

a craft or trade?

Material + Craft = Product

+ = Elements & Enterprise Outcomes

Dependencies Architecture & Value

Clay + Pottery = Ceramics

Wood + Carpentry = Furniture


Page 9

...and here the

miracle occurs...




Page 10

...and here the

miracle occurs...



What is the magic of

Enterprise

Architecture?

How do Enterprise

Architects sprinkle

their fairy dust?


Page 11

The Miracle of EA

“The Miracle” is best

explained with

5 C’s-themes

The correct

combination of elements

& dependencies within

scope

The consideration

of dependencies to

relevant elements outside

the scope.

Planning the

sequence of production

and assembly tasks & #

activities.

Common and

similar description,

documentation and

visualisation.

Validating

completeness, correctness

and plausibility.


Page 12

^Questions to be asked

Do we have the right scope?

Are all elements and

dependencies correctly

defined and arranged?

^Intention & Purpose

To avoid unpleasant surprises

(e.g. cost overruns).

To focus projects and keep

them focussed.


Page 13

^Question to be asked

Is the solution or system

correctly aligned in its

environment?

Are all external dependencies

considered?


To avoid delays to other

projects and surprises to

business users and services.

To identify impacts and

address those.


Page 14


Are all activities and tasks

considered?

Are all final and

intermediate deliverables

known?

Are all tasks planned in the

correct sequence?


Defining complete and

realistic projects.

Inform where tasks can be done

in parallel and where in

sequence.

Setting realistic

expectations.


Page 15


Is the architecture and

delivery described and

documented in a uniform way?

Are results comparable to

similar uses?


Supporting knowledge transfer

from build to operate.

Allowing re-use of lessons-

learned, information and

knowledge.


Page 16


Are all decisions, decisions

and agreements documented?

Are all decisions, decisions

and agreements complete,

correct and plausible?


Making sure everyone has bought

into the project or change.

Making sure that all tasks are

known and impacts addressed.


Page 17

...and

why all

of that?

^Burning Questions

Is the business value

understood (not just the

needed system)?

Are the enablers (service,

solution, business change) to

make this a success known?


Making sure you understand

what is needed (not just

understand what IT you need).

Making sure that your money is

well spend and there are no

surprises.

To deliver

Outcomes &

Value


18

Conclusion

The sole essence and purpose of

Enterprise Architecture is

the enabling, assurance and

delivery of Outcomes & ̂Value.


By Heinz Tonn

Find me on LinkedIn

19

Thank you for

your attention


http://www.linkedin.com/in/heinztonn/

Technology

About Enterprise Architecture