introductions an introduction to the overview of ... · 5/30/2008 · fea: federal enterprise...

1

Roger Sessions

ObjectWatch

An Introduction to theMajor EA Methodologies

Presentation OverviewIntroductionsWhy EA?Overview of MethodologiesZachmanTOGAFFEAAgile EAVPEC-TSIPPutting Them TogetherSummary

Roger SessionsCEO of ObjectWatch, specializing in Enterprise Architectures

Seven Books, including Simple Architectures for ComplexEnterprises published by Microsoft Press

Keynote speaker at more than 100 conferences

Author of more than 100 articles

Board of Directors of The International Association of Software Architects

Editor-in-Chief of Perspectives of The International Associationof Software Architects

Writer and Creator of The ObjectWatch Newsletter

Microsoft MVP

Legal NoticesThis presentation is copyright © 2007, 2008 by ObjectWatch, Inc.,Houston, Texas. All rights reserved. These PowerPoint slides maynot be redistributed. Unauthorized reproduction of these slides isprohibited.

ObjectWatch® and Software Fortresses® are registeredtrademarks of ObjectWatch, Inc. SIP™ and Simple Iterative

Partitions™ are trademarks of ObjectWatch, Inc. Othertrademarks are owned by their respective companies.

The SIP Methodology is protected by pending patents.


Architectural Levels: Process

Domain of Concern: How a business process works.Example: Loans are taking too long to approve.

Process

2

Architectural Levels: Business

Domain of Concern: How processes work together.Example: Customer information is inconsistent between LoanOrigination and Collections.

Business

Process

Architectural Levels: Application

Domain of Concern: How an application works.Example: Loan Applications crashes when loan amount is lessthan zero.

Application

Business

Process

Architectural Levels: IT

Domain of Concern: How applications work together.Example: Loan applications can’t automatically move from theOrigination application to the Approval application.

IT

Application

Business

Process

Architectural Levels: EA

Domain of Concern: How IT delivers business value.Example: The last major IT initiative lacked critical capabilities thebusiness needed.

EA

IT

Application

Business

Process

Examples of EA ProblemsUp-to-date data is not available for making agile businessdecisions.

We want to acquire a new company and we need to make surethat their processes can be handled by our information systems.

We need to make sure that our IT systems can meet newregulatory requirements.

Our competition spends half as much on IT maintenance than wedo.

We need to automate our partner relationships.

We are beginning a new complex IT project and we can’t afford tohave it fail.

We are trying to decide whether we should build a new systemfrom scratch or purchase an existing off-the-shelf system.


3

DefinitionsTaxonomy: A way of categorizing things.

Process: A recipe for making things.

Framework: A description for how things fit together.

Model: A way of thinking about things.

Architecture: A description of how something is organized.

Architect: One who is responsible for an creating an architecture.

Architectural Artifact: Some item that contributes to anarchitecture.

Focused Process: A recipe for making some aspect of things.

Acronym Soup

FEA: Federal Enterprise Architecture

TOGAF: The Open Group Architecture Framework

AEA: Agile Enterprise Architecture

VPEC-T: Value, Policy, Events, Content, Trust

SIP: Simple Iterative Partitions

Zachman: John Zachman’s Framework

Comparison by Approach

Architectural Taxonomy: Zachman.

Architectural Process: TOGAF, AEA.

Architectural Framework: FEA.

Focused Architectural Process: SIP, VPEC-T

Architectural Model: SIP

Comparison by GenerationFirst Generation Methodologies

Mantra: We need to align IT and business!Methodologies: Zachman

Time Period: 1987-1995

Mantra: We need a process to follow!Methodologies: FEA, TOGAF

Time Period: 1995-2003Second Generation Methodologies

Mantra: This is taking way too long!Methodologies: VPEC-T, AEA, SIP

Time Period: 2005-Third Generation Methodologies


Zachman EssentialsIntroduced in 1987A framework for information systemsarchitecture, by J.A. Zachman in IBM SystemsJournal 1987Best Source of Information: EnterpriseArchitecture Using the Zachman Frameworkby Carol O’Rourke, Neal Fishman, andWarren Selkow.

Web Site: www.zifa.comMain Proponent: John Zachman

4

Zachman IdeasIntroduced the idea of Enterprise Architecture

An architecture needs to consider everyimportant aspect from the perspective of everyimportant stakeholder.

IT perspectives should be driven by Businessperspectives

Zachman Diagram

System Attribute

Perspective

Zachman Wrap-up

No process to follow.Not specific to enterprise architecture.

We are having difficulties communicating with oneanother about information systems architecture, becausea set of architectural representations exists, instead of asingle architecture. One is not right and another wrong.The architectures are different. - John Zachman

Drawbacks

Favorite Quotation

Nobody fills in all cells... which are necessary?


TOGAF EssentialsOriginally based on TAFIM (circa 1998, nowdefunct).Most recent version: 8.1.1

Web Site: www.opengroup.org/architecture/togaf8/downloads.htmMain Proponent: IBM

Owner: The Open GroupDefinitive Reference: Guide to Enterprise ITArchitecture by Col Perks and Tony Beveridge

TOGAF IdeasThere should be a standard process thateverybody follows.

All information on that standard should beavailable freely to anybody.

That standard should be controlled by anindustry consortium that is platform agnostic.

5

What TOGAF IncludesAn Enterprise ContinuumA Technical Reference Model

An Enterprise Architectural Process calledADM (Architecture Development Method.

A Standards Information Base

A reference model for an EnterpriseArchitecture.

Four Pieces of a TOGAF EABusiness Architecture that describes howthe business meets its goals.Application Architecture that describes howapplications are designed and interact witheach other.Data Architecture that describes how theenterprise data stores are organized andaccessed.Technical Architecture that describes thesoftware and hardware infrastructure.

The TOGAF ProcessPhase: A

ArchitectureVision

Phase: Prelim.Framework

andPrinciples

Phase: BBusiness

Architecture

Phase: CInformation

SystemsArchitectures

Phase: DTechnologyArchitecture

Phase: EOpportunities

andSolutions

Phase: FMigrationPlanning

Phase: GImplementation

Governance

Phase: HArchitecture

ChangeManagement

ADM: Architecture Development Method


ArchitectureVision


andPrinciples

Phase: BBusiness

Architecture

Phase: CInformation




andSolutions



Governance


ChangeManagement

Introduce TOGAF process

Modify process as necessary

Set up governance

Putting Them Together


ArchitectureVision


andPrinciples

Phase: BBusiness

Architecture

Phase: CInformation




andSolutions



Governance


ChangeManagement

Receive Request For Architectural Work.

Define high level start and end goals.

Create Statement of Architectural Work.

Approve statement by all stakeholders.


ArchitectureVision


andPrinciples

Phase: BBusiness

Architecture

Phase: CInformation




andSolutions



Governance


ChangeManagement

Create detailed baseline and target business architecture.

Create business models.

Develop technical requirements.

Describe migration plan.

6


ArchitectureVision


andPrinciples

Phase: BBusiness

Architecture

Phase: CInformation




andSolutions



Governance


ChangeManagement

Create baseline and target IS architecture

Review and validate reference models, viewpoints, etc.

Map business architecture to CRUD data operations.

Deliver Target Data and Applications Architecture.


ArchitectureVision


andPrinciples

Phase: BBusiness

Architecture

Phase: CInformation




andSolutions



Governance


ChangeManagement

Determine infrastructure requirements.

Determine baseline and target architectures.

Remaining phases continue like this.

TOGAF Wrap-up

Process is long and tortuous.Idea of data architecture is outmoded.

TOGAF is not wholly specific with respect togenerated documents; in fact, it provides very little inthe way of prescriptive document templates – merelyguidelines for inputs and outputs. (Col Perks andTony Beveridge, Guide to Enterprise IT Architecture).

Drawbacks

Favorite Quotation

Artifacts are poorly defined.“Standard” is so flexible as to be meaningless.


FEA Essentials

Replaces FEAF (Federal EnterpriseArchitecture Framework)

Owned by Office of Management and Budget(OMB - a branch of The White House)

Use of this framework is required by thebudgetary process.

Specific to the U.S. Federal Government

FEA IdeasThe Federal Government needs a standardframework that all government bodies canfollow.

This sharing will result in a highly efficientgovernment.

This standard framework will allow governmentbodies to share data, code, and processes.

7

What FEA IncludesA “Segment” ModelA set of references models, includingbusiness, service, components, technical, anddata.

A transitional process for migrating from apre-EA to post-EA paradigm.

An ADM-like process.

A taxonomy for describing EA assets.A maturity model to measure success inapplying EA.

The FEA Segment Model

Services that can be deployed centrally andshared across the government.

Services that canbe implementedonce and deployedin each organ-ization

Services thatare specific toindividualagencies.

FEA Wrap-up

Process is even more long and tortuous than ADM.There is little evidence that this is helping.

[FEA is] a common language and framework todescribe and analyze IT investments, enhancecollaboration and ultimately transform the Federalgovernment into a citizen-centered, results-oriented,and market-based organization as set forth in thePresident's Management Agenda. (OMB)

Drawbacks

Favorite Quotation

The process is largely tied to the FederalGovernment.


AEA Essentials

Definitive Reference: www.AgileEA.com mostlyby Charles Edwards (looking for help!)

Main Proponent: Charles Edwards

Focal Point: Agile TOGAF

Introduced: 2007

AEA Ideas

Take the EA one month at a time (called“Sprints”.Keep list of hot work items within a biggerpicture.

Daily status meetings (“Scrum Meetings”) toevaluate progress.

EA needs agile concepts such as adaptability,agility, continuous improvement, similar to whatAgile Development provides.

Focus on time-boxing the AE process.

8

AEA Wrap-up

The goal of making TOGAF agile is good, butnot yet clear how AEA will achieve this.Think of AEA as an evolving set of BestPractices and open source tools for makingTOGAF usable.

AEA is still in Beta, ETA end of year.

Favorite Quotation: A lot of thought has gone intosoftware development and software architecturedisciplines over the last few decades, with the Agilecommunity at the forefront and making excellent progressmore recently. The same cannot be said for the disciplineof Enterprise Architecture (EA)...– Charles Edwards


VPEC-T Essentials

Definitive Reference: Lost in Translation byNigel Green and Carl Bate

Main Proponent: Capgemini

Focal Point: Business/IT Communications

Introduced: 2006

Web Site: www.LITHandbook.com

VPEC-T Ideas

Business doesn’t understand IT speak.We need a common language that bothunderstand.This language should facilitate a clearunderstanding of what the business needsfrom IT.

IT doesn’t understand business speak.

IT Failures are primarily due to poorcommunications.

The issues that are least comfortable todiscuss may be the most important tounderstand.

VPEC-T In Practice

Every major discussion, from businessrequirements to technical design needs toinclude a VPEC-T dialogue.

The PECs of VPEC-TP stands for PoliciesDefinition: The policies of an organization define therules that govern activities within that organization.

Example: Any loan over $100,000 must be approvedby a VP.

Note: Policies often describe workflow patterns.

9

The PECs of VPEC-TE stands for EventsDefinition: Events are widely visible changes in thestate of one or more business activities.

Example: Any loan that is overdue by more than 60days triggers a loan-default event.

Note: The concept of events naturally lead to EDA(Event Driven Architectures)

The PECs of VPEC-T

C stands for ContentDefinition: Content is the information that is needed totie an event to a particular business entity and tointerpret that meaning of that event.

Example: The contents of loan defaults includes thename of the loan holder, the amount of the loan, thedate of the last payment, the amount outstanding, thenumber of days past due.

Note: In an services-oriented architecture, contentwould be the definition of the message.

The Tough Parts of VPEC-T

V stands for ValuesDefinition: Values are the agenda items (oftenunwritten) that drive patterns of behavior.

Example: Loan-Origination only cares about how manyloans it originates each day (this is how it is measured)it doesn’t care how many of those loans are eventuallyapproved.

Note: This information is rarely captured in businessrequirements, yet can be critical determining thesuccess of a project.

The Toughest Part of VPEC-T

T stands for Trust

Definition: Trust is a measure of confidence that oneparty has in another.

Example: Loan-Approvals has very little trust in thedata that Loan-Origination collects and neither groupbelieves that IT can deliver a working system.

Note: This information is not only rarely captured, butis rarely verbalized outside of some trusted circle. Yetif trust issues are not captured, they fester and cannotbe addressed.

VPEC-T Wrap-up

Gives little guidance as to how to get people todiscuss the hard issues.

A Trust issue might be the single largest barrier toadoption of an IT solution. – Lost in Translation byNigel Green and Carl Bate.

Drawbacks

Favorite Quotation

Success will be determined by the skills of thefacilitator.

Focus on meaningful communications that canmake or break projects.

Strengths

Can be applied at many different levels.

Presentation OverviewIntroductionsWhy EA?Overview of MethodologiesZachmanTOGAFFEAAgile EAVPEC-T

Putting Them TogetherSummary

SIP

10

SIP Essentials

Definitive Reference: Simple Architectures forComplex Enterprises by Roger Sessions

Web Site: www.objectwatch.com

Main Proponent: ObjectWatch

Focal Point: EA Complexity

Introduced: 2007Precedent: Software Fortress Methodology

SIP Ideas

The main inhibitor to delivering business valuefrom IT is complexity.

The most important goal of EA is to removecomplexity.A model for EA complexity based onmathematics allows us to validatearchitectures before they are built.

EA needs to be based on rational, reproducibleprocesses.

What SIP IncludesA model for EA complexity based on probabilitytheory, set theory, and equivalence relations.A process for partitioning an enterprise intoautonomous units called AutonomousBusiness Capabilities (ABCs)A process for prioritizing the delivery of thoseABCs based on risk, cost, and value.An iterative delivery model of those ABCs thatis amenable to agile development.

The SIP Process

PreparationPhase Partitioning Simplification Prioritization Delivery

GoalsSet stage forsuccessfulengagement

Pain/GainABCidentification

ABCSimplification

DeliveryPrioritization

IterativelyDeliverIdentifiedSolutions

Preliminary Analytical IterativeStage

The SIP Enterprise Model

DistributionCenter

Store

Main Office

Main Office

RetailEnterprise

DistributionCenter

Store

Store 01Store 02 Store 03 Store 04 Store 05

Region 1Distribution

Center

Supplier1

Region 1Distribution

Center

Supplier

Supplier2

Supplier

Supplier3

Supplier4

Supplier5

Supplier6

How SIP Reduces Complexity

Partitioning of the enterprise into ABCs.

Functional reduction within ABCs.

Consolidation of similar ABCs.

Elimination of unnecessary ABCs.

11

SIP Wrap-up

SIP focuses only on the issue of complexity. Itcan be augmented with other processes asneeded.

Complexity is the Enemy.– Simple Architectures for Complex Enterprises byRoger Sessions.

Drawbacks

Favorite QuotationIt is based on math which can feel intimidating.

Focus on controlling complexity.Strengths


None are CompleteTOGAF is all process, no deliverables.Zachman is all deliverables, no process.

SIP is too small.

VPEC-T is all talk, no action.

AEA is all action, no talk.

FEA is too big.

The bottom line: you need a little of everything.

One PossibilityStart with SIP to address the burning issue ofcomplexity.Introduce VPEC-T to guide the discussions.Aim for a segmented architecture a la FEA.Once you have created SIP style subsets, useTOGAF to align the business and technicalpieces within them.Keep TOGAF under control with AEA.Manage your artifacts with a Zachmanapproach.

But Whatever You DoMeasure the business value your EA approachdelivers.

Track the time it takes to deliver that value.

If you can’t deliver measurable value quickly,change your process.

EA is about value, not process.


12

The High PointsZachman was the first. It helps organizeartifacts and relate them to each other.TOGAF introduces formal processes and AEAmay make those processes usable someday.

SIP breaks a complicated enterprise intomanageable morsels and focuses businessand IT on their common enemy: complexity.VPEC-T helps business and IT communicatein a positive, non-confrontational style.

FEA is a government monster but includes auseful model for enterprise segmentation.

The Take Home MessageThe methodologies are not mutually exclusive.

Each has strengths and weaknesses.Your goal should be to use the best of each tomeet your enterprise needs.Keep focused on why you care about EA : NOTspinning through processes, but delivering thehighest possible business value from your ITinvestments.

For more on SIP

[email protected]

introductions an introduction to the overview of ... · 5/30/2008 · fea: federal enterprise...

Documents