An intro to TOGAF Framework as a problem solving method to the enterprise.

1. Enterprise
Architecture
A Problematic Approach
Yasir A. Karam
March 2014

2. Wikiying TOGAF; an EA from Open
So its again
Group perspective should: Informal
Knowledge
incubated in
ofSystems
• Describe a method for defining an
information system in terms of a set
building blocks
• Show how the building blocks fit together
Semantically Linked
• Contain a set of tools
Reference Models
• Provide a common vocabulary
• include a list of recommended standards
• include a list of compliant products that can
be used to implement the building blocks

3. What 9.1 brings More Formal to the
Informal
•
representation to
knowledge
A formal business-driven approach to Capability
Again
based Working out
architecture
things
• Business capability-based planning
• Guidance on how to use TOGAF to develop a
Security Architecture or SOA
Don’t touch this cause
this may engender
everything towards
software architecture
Security becomes a
big Hassel day by
day

4. TOGAF; The addiction to Agility
•
•
•
•
•
•
•
•
A domain driven approach to reasoning of things
DDD might be a key solver
Use of Ubiquitous Languages (ie; Archimate)
Iterative design methods
Optimization methods
Rapid deployment of rules and policies
Scoped or bounded contexts
Use of dialogues (descriptive languages) to
express Intentions

5. TOGAF; The Method
So its all about RE

6. TOGAF; The Enterprise Continuum
• Since it’s a problematic approach for solving problems
via structured abstracts, then;
• It’s a set of Solutions to set of Problems
• An architectural repository is the scenic theater to
–
–
–
–
–
–
Models
Abstracts
Patterns
Descriptions
Rules, Logic
Representations
• But EC is a dynamic repository (contain knowledge)

7. TOGAF; the problematic way
• So again, it was made to solve problems
• Problems mean rationalizing of requirements or
answering the How
• Specifications (formalization) is the
operationalization of Goals or answering the
What
• Actor’s behavioral aspects (Activities) are
pragmatically set into plans or the answering of
When
• Actors are the nasty players; or the answering of
Who

8. TOGAF; The Aspectual Move
•
•
•
•
•
•
•
•
•
•
Aspectual View Points
Subject design filters
Streams
Blueprints
Point Cut’s
Advises
Join Points
Aspect Reuse
Aspect vs. Base
Aspects vs. Concepts

9. TOGAF; again the problematic way
• Its how to carefully bless requirements
• Its how to carefully separate between Aspects (Domains)
rigorously
• Its how to separate between Domains using Abstraction
Layers
• Its how to find modification methods using Meta data
• Its how to maximize levels of understanding between
different domain layers using Descriptive models or
descriptive languages
• Its about how to separate Computations (The Dynamics
or The How) from languages
• Its about where to put placeholders to enforce
rules/policies via contracts (ie; SLA,…etc)

10. TOGAF; The Lego Way
What is the difference?
<->
?

11. What is the difference?

12. TOGAF; The Toolset

13. What about ArchiMate?
• The hard wiring between artifacts
• Framework independent (can be used at any architectural
domain context)
• More comprehensive than other modeling languages to an
enterprise level (more than UML)
• Backed by meta model (can be modelled using like OOAD)
• Visual Notations
• Can be used as component configuration language
• Sound Functional (data flow programming), Lazy Eval.
• Data modelling (Everything is Data and Every data is an
Object)
• Hard coded (programmable)
• Structural dependencies between elements/objects

14. ArchiMate; What about cons?
• Fit for purpose not for use
• Still static to some extent
• Cannot describe all types of context
knowledge
• Cannot describe computational problems
(complex business patterns)
• An effort to complement System Thinking as
objects thinking

16. Yeh, But Why TOGAF??
•
•
•
•
•
•
Cozy, Simple, Quite
Open, dictates a philosophy not a strategy
Can fit large enterprises
Fits Information (Informal Knowledge) architecture
Resilient and can adapt to change (Agile)
Can be used to Solve problems of What piece of Info
about Whom, to Where, When it has been shouted
and most importantly WHY
• Can be easily integrate with ITIL, CoBIT and others.

17. When EA or TOGAF is badly needed?
•
•
•
•
•
•
•
•
•
•
•
•
When you’re dying for Governance
When things are out of control
When you wish to spend wisely (control of spending)
When its becoming too much complex (need for standards,
reference models, taxonomies)
When its about bridging gaps (interoperable)
When change is a nightmare
When the need for control become eminent, and,
When its all about Solving Problems rigorously rather than
following
Boosting people performance and org growth
When its about meeting Goals and Objectives
When you need Simplicity rather than crippled by the rules
When we need a break for Playing and having Fun..

18. BYE !!!!!!!!