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.
Presentation OverviewIntroductionsWhy EA?Overview of MethodologiesZachmanTOGAFFEAAgile EAVPEC-TSIPPutting Them TogetherSummary
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.
Presentation OverviewIntroductionsWhy EA?Overview of MethodologiesZachmanTOGAFFEAAgile EAVPEC-TSIPPutting Them TogetherSummary
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
Presentation OverviewIntroductionsWhy EA?Overview of MethodologiesZachmanTOGAFFEAAgile EAVPEC-TSIPPutting Them TogetherSummary
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?
Presentation OverviewIntroductionsWhy EA?Overview of MethodologiesZachmanTOGAFFEAAgile EAVPEC-TSIPPutting Them TogetherSummary
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
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
Introduce TOGAF process
Modify process as necessary
Set up governance
Putting Them Together
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
Receive Request For Architectural Work.
Define high level start and end goals.
Create Statement of Architectural Work.
Approve statement by all stakeholders.
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
Create detailed baseline and target business architecture.
Create business models.
Develop technical requirements.
Describe migration plan.
6
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
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.
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
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.
Presentation OverviewIntroductionsWhy EA?Overview of MethodologiesZachmanTOGAFFEAAgile EAVPEC-TSIPPutting Them TogetherSummary
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.
Presentation OverviewIntroductionsWhy EA?Overview of MethodologiesZachmanTOGAFFEAAgile EAVPEC-TSIPPutting Them TogetherSummary
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
Presentation OverviewIntroductionsWhy EA?Overview of MethodologiesZachmanTOGAFFEAAgile EAVPEC-TSIPPutting Them TogetherSummary
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
Presentation OverviewIntroductionsWhy EA?Overview of MethodologiesZachmanTOGAFFEAAgile EAVPEC-TSIPPutting Them TogetherSummary
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.
Presentation OverviewIntroductionsWhy EA?Overview of MethodologiesZachmanTOGAFFEAAgile EAVPEC-TSIPPutting Them TogetherSummary
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