EA 101

Semantech Inc. 2008 - Lecture Series Enterprise Architecture 101 (Balancing Theory with Practice) Presented by Stephen Lahanas Principal Consultant, Semantech Inc. Feb 21st, 2008 Copyright 2008, Semantech Inc. – All Rights Reserved http://www.semantech-inc.com I

Introduction

This presentation is designed to provide a high level overview to practice of Enterprise Architecture (EA).

We will focus on some possible disconnects between the theory and current practice of EA.

This presentation will also explore emerging disciplines such as Semantic Architecture, Agile & Actionable EA.

We will also review and discuss how EA relates to design and to the rest of the development lifecycle.

Enterprise Architecture, EA Defined

What it is isn’t – It’s not one approach, it’s not just one framework and its not all that different from design, really…

Enterprise Architecture was born from the need to be able to visualize and document the complexity of a complete enterprise environment as opposed to merely the design of a single system.

EA by nature is itself complex due to its mission. EA is flexible and most importantly needs to be viewed as a tool or a means to an end, rather than the end itself.

Enterprise Architecture is one of the primary enablers for Integration…

EA, Deconstructed

Most people who know about EA think of it in terms of the “Frameworks” which are used to produce EA “products” or “artifacts” (the output of EA).

Frameworks represent design and notation paradigms and are generally supported by metamodels constructed to emulate IT enterprise environments.

Frameworks include: DoDAF, ToGAF, FEAF, Zachman, UML, MODAF, BPMN & BPEL, IDEF, C4ISR, ITIL…

There is no single right or best framework.

Frameworks, Deconstructed

A framework can either be deterministic or flexible. A deterministic framework is one that attempts to describe an enterprise within a specific context. A flexible framework is one that is not bound to many conventions regarding how the enterprise should appear.

Deterministic EA is what is most commonly associated with the practice and began with the Zachman framework and IDEF.

Flexible EA was born out of the Object Oriented Design (OOD) school and is most commonly associated with UML and the Unified Process.

A View into a Deterministic EA Framework

DoDAF – The Department of Defense Architecture Framework. This framework provides “views” into the various architecture tiers:

AV – All View (The Semantic & Logical Foundation)

OV – Operational View (Business Architecture)

SV – Systems View (system design / representation)

TV – Technical View (standards)

Most of the other deterministic EA frameworks follow a similar pattern, with views or references models depicting architecture tiers or categories.

The DoDAF paradigm is built atop a complex metamodel referred to as CADM (The Core Architecture Data Model).

Copyright 2008, Semantech Inc. – All Rights Reserved http://www.semantech-inc.com This taxonomy diagram was developed to support creation of a DoDAF TV-1 for a data focused solution. The actual TV-1 was then created in a spreadsheet using these categories as its core structure.

A View into a Flexible EA Framework

Many people in the EA community are culturally divided from the development community and would not consider UML (Unified Modeling Language) to be an EA framework. However, many organizations & architects use it that way.

UML does have a metamodel and notation conventions but these are more aligned to software development & design considerations that the enterprise itself.

UML is also more likely to be integrated into the actual solution development lifecycle.

Often times though the most flexible manner for depicting an EA is by using no framework at all.

Copyright 2008, Semantech Inc. – All Rights Reserved http://www.semantech-inc.com This diagram represents a UML Use Case enterprise view of a Common Operating Picture (each circle represents other use cases and all of them are associated with other diagrams / artifacts) I

The Theory of EA…

The theory behind EA tends to imply that by having enterprise architectures in place, organizations will be able to better determine governance and manage design and implementation.

EA has become a compliance consideration or mandate by many organizations for this reason. Much of what is outlined in the Clinger Cohen Act (CCA) of 1996 for Federal IT oversight is dependent on EA.

Many EA practitioners believe that having the architecture will by itself will fulfill expectations surrounding EA.

Most EA practitioners believe that extensive analysis is required to produce an EA.

Architecture occurs or should occur within the context the projects or initiatives which manage enterprise IT capability… Copyright 2008, Semantech Inc. – All Rights Reserved http://www.semantech-inc.com

The Practice of EA…

Current EA approaches take too long, cost too much and often fail to achieve their objectives. Why?

EA has become too complex in many cases to be useful.

EA efforts are often disassociated from the initiatives or environments which spawned them.

EA is about integration, not extended analysis – integration is all about rapid problem solving.

EA has seemingly divorced itself from Design; solution architectures and enterprise architecture ought to be extensions of each other, not separate disciplines. EA must also be integrated with all other enterprise processes.

EA practice is evolving to provide more pragmatic approaches to architecture. Actionable EA is one such approach…

Agile EA is a recognition of the need for speed in EA development as well as the necessary connection to the rest of the lifecycle… SOA is one area where Agile EA can be applied.

Meta-Integration – Complexity in Design

By definition, any combination of integration techniques or paradigms represents “meta-integration.”

EA Frameworks are themselves meta-integration engines in that they utilize enterprise metamodels to derive “instance views” of the enterprise or the EA.

Some enterprises must also deal with multiple frameworks, design techniques and their associated metamodels. For integration to occur in these scenarios, meta-integration must be reconciled first.

There is only one way to achieve this type of integration – semantic de-confliction (otherwise known as semantic integration).

Semantic Integration recognizes the growing need for reconciliation across multiple frameworks and enterprises…

EA & Integrating The Enterprise

Enterprise Architecture can be effective when:

It is not used merely as a compliance checkbox.

It is aligned to solution objectives and design.

It is practiced as a continuous evolutionary cycle rather than a one-off project.

It is proactive and facing forward rather than overly focused on current structures and analysis of capability that needs to be replaced.

It is aligned with an integrated into all other architectures, designs and processes.

It is easily accessible to everyone in the enterprise.

It becomes the basis for all requirements…

What is a Solution Architecture?

A Solution Architecture can be informally defined as a comprehensive design, one that may extend beyond a single system or include a system along with its business and datacenter foundations.

Solution Architectures are often not built using any EA framework (even UML). Any design tool can be employed, including PowerPoint and Visio.

The objective with the Solution Architecture is to provide a visual reference for all stakeholders involved with the project.

Solution Architectures are AGILE – they can be produced quickly and maintained easily…

Copyright 2008, Semantech Inc. – All Rights Reserved http://www.semantech-inc.com This diagram represents a Solutions Architecture view of a Common Architecture Picture (a complex form of data fusion architecture). The Solution Architecture is flexible but often limited in its scope…

What is SOA?

Services Oriented Architecture (SOA) has been variously described as a set of best practices, a design philosophy and a set of related vendor “stacks” that function as a facilitating medium - all of this centered around the notion of systems shifting to services using web services standards as the foundation. From a business and technical perspective it perhaps far less important to understand the details of how a WSDL or a SAML token are supposed to work in ideal circumstances. What really counts is how SOA is or isn’t being used to leverage actual enterprise solutions. When we take a look at the implications that this technology trend may have upon the nature of the enterprise itself, SOA becomes at once more problematic and interesting. The most fascinating prospect is the idea that we may be on the verge of finding a unifying framework which may finally help us coordinate all aspects of enterprise IT capability.

SOA is both an Architecture and a Governance exercise. There are many ways to visually depict what SOA means and what decisions might be associated with it… Copyright 2008, Semantech Inc. – All Rights Reserved http://www.semantech-inc.com

Conclusion

Enterprise Architecture is a complex practice with no single methodology and holds tremendous potential. Like many aspects of IT though, much of that potential remains unrealized.

EA practitioners must be pragmatic rather than dogmatic when it comes to employing EA to solve enterprise issues. The right way to perform it is ultimately the way that works best for the client – EA ought to be solving their problems, not creating new ones.