Enterprise architecture: A Problamatic Approach


Published on

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

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Enterprise architecture: A Problamatic Approach

  1. 1. Enterprise Architecture A Problematic Approach Yasir A. Karam March 2014
  2. 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. 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. 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. 5. TOGAF; The Method So its all about RE
  6. 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. 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. 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. 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. 10. TOGAF; The Lego Way What is the difference? <-> ?
  11. 11. What is the difference?
  12. 12. TOGAF; The Toolset
  13. 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. 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
  15. 15. 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.
  16. 16. 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..
  17. 17. BYE !!!!!!!!