about enterprise architecture
Post on 16-Jul-2015
108 Views
Preview:
TRANSCRIPT
© 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.
© H Tonn 2015 (Slideshare Version)
Page 4
The objects of EA
are Elements and
Dependencies.
Let’s get started with
the basics of Enterprise
Architecture (EA).
© H Tonn 2015 (Slideshare Version)
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.
© H Tonn 2015 (Slideshare Version)
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
© H Tonn 2015 (Slideshare Version)
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.
© H Tonn 2015 (Slideshare Version)
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
© H Tonn 2015 (Slideshare Version)
Page 9
...and here the
miracle occurs...
+ = Elements & Enterprise Outcomes
Dependencies Architecture & Value
© H Tonn 2015 (Slideshare Version)
Page 10
...and here the
miracle occurs...
+ = Elements & Enterprise Outcomes
Dependencies Architecture & Value
What is the magic of
Enterprise
Architecture?
How do Enterprise
Architects sprinkle
their fairy dust?
© H Tonn 2015 (Slideshare Version)
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.
© H Tonn 2015 (Slideshare Version)
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.
© H Tonn 2015 (Slideshare Version)
Page 13
^Question to be asked
Is the solution or system
correctly aligned in its
environment?
Are all external dependencies
considered?
^Intention & Purpose
To avoid delays to other
projects and surprises to
business users and services.
To identify impacts and
address those.
© H Tonn 2015 (Slideshare Version)
Page 14
^Questions to be asked
Are all activities and tasks
considered?
Are all final and
intermediate deliverables
known?
Are all tasks planned in the
correct sequence?
^Intention & Purpose
Defining complete and
realistic projects.
Inform where tasks can be done
in parallel and where in
sequence.
Setting realistic
expectations.
© H Tonn 2015 (Slideshare Version)
Page 15
^Questions to be asked
Is the architecture and
delivery described and
documented in a uniform way?
Are results comparable to
similar uses?
^Intention & Purpose
Supporting knowledge transfer
from build to operate.
Allowing re-use of lessons-
learned, information and
knowledge.
© H Tonn 2015 (Slideshare Version)
Page 16
^Questions to be asked
Are all decisions, decisions
and agreements documented?
Are all decisions, decisions
and agreements complete,
correct and plausible?
^Intention & Purpose
Making sure everyone has bought
into the project or change.
Making sure that all tasks are
known and impacts addressed.
© H Tonn 2015 (Slideshare Version)
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?
^Intention & Purpose
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
© H Tonn 2015 (Slideshare Version)
18
Conclusion
The sole essence and purpose of
Enterprise Architecture is
the enabling, assurance and
delivery of Outcomes & ̂Value.
© H Tonn 2015 (Slideshare Version)
By Heinz Tonn
Find me on LinkedIn
19
Thank you for
your attention
© H Tonn 2015 (Slideshare Version)
top related