Published on March 3, 2014
Enterprise Architecture A Problematic Approach Yasir A. Karam March 2014
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
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
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
TOGAF; The Method So its all about RE
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)
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
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
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)
TOGAF; The Lego Way What is the difference? <-> ?
What is the difference?
TOGAF; The Toolset
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
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
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.
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..
Enterprise Architecture and ... if we build on the strengths of both approaches, we can create enterprises that ... Wir wollen diese Problematik der ...
This ontology is a representation of the enterprise architecture ArchiMate ... The approach tackles the ... Zur Problematik der ...
Mainframes und Enterprise ... Ausgehend von der Problematik der Leistungsbewertung ... D.A. Patterson: Computer Architecture: A Quantitative Approach ...
... cc69nmmwebsite docssituation analysissituation analysis approach and method.doc Worksheet 9: Strategy for stakeholder participation along the project
ArchiMate-Modellierung mit dem Innovator for Enterprise Architects ... dem Innovator for Information Architects ... bottom-up approach with INNOVATOR
... New Challenges and Industrial Approaches, ... by systems architects and developers to ... Problematik befasst sich die Enterprise ...