Microsoft PowerPoint - When EA and SOA Worlds Collide ...

© EAdirections 2006. All Rights Reserved.

Directions Teleconference & Webinar:When EA & SOA Worlds Collide!

Featured Guest SOA Expert:David LinthicumLinthicum Group

Sponsored byShared Insights

July 19, 2007

Copyright 2007 The Linthicum Group, LLC© EAdirections 2007. All Rights Reserved. 2

Today’s Agenda

• Why is SOA such a misunderstood topic• The natural tension between Enterprise-level and project-

level architecture• An Enterprise Architect’s view of SOA• A Service Oriented Architect’s view of SOA• What should EA do for SOA projects?• What should SOA projects do for EA?• What should SOA and EA do together for the business?• How do you bring these two together?• Implications for Governance

• Q & A from the audience

Copyright 2007 The Linthicum Group, LLC© EAdirections 2007. All Rights Reserved.

Current Issues

• Technological obstacles to reuse being overcome• Cultural obstacles to reuse still an issue• Project-oriented obstacle to reuse• Many competing internal SOA projects,

approaches, & technology choices• Hype-driven confusion (e.g., “SOA 2.0”)• Lack of leadership from EA on SOA• Processes moving outside of the firewall• Departments operating independent of oversight• More enterprise applications are Web-delivered• Technology as a business advantage and cost

saving mechanism

4


Understanding the Forces at Work

SOA

SaaS

Web 2.0

Emerging Standards

Hype

Enterprise Architecture

Cost Reduction

5


EA and SOA…Let’s Face Facts

• There seems to be two worlds out there, theworld of enterprise architecture and the worldof SOA.

– “The funny thing is that those in each world thinks that they can do the otherworld's jobs.”

– “The end result...there is not a lot of synergy there yet.”

6

This is not aboutThis is not about ““Who gets to lead?Who gets to lead?””


More good news…

Some traditional enterprise architects have notdone a stellar job in understanding theopportunities within SOA, generally speaking,and the SOA guys have not figured out how SOAmeshes with existing enterprise architecturestandards, notions, and practices, again generallyspeaking.

7


Natural Tension between E-level and project-levelarchitecture

• The project is the primary “unit ofchange” in an enterprise

• Project have limited scope,budget, schedule and resources

• The “Big Picture” needs to existand be maintained

• Linkages need to be establishedand impact analysis performed

• Downstream decisionmaking/projects must beconsistent with Upstreamintentions

BuildService

BuildService

ProjectPortfolio

BuildCapabilities Build

Service

BuildService

IntegrateCapabilities

THE BIG PICTURE

Tension can become Synergy!Tension can become Synergy!


Defining Enterprise Architecture: Process

• Enterprise Architecture (EA) is a strategic managementdiscipline that creates a single, holistic view of the processes,systems, information and technology of the enterprise designedand optimized to achieve the business strategy and currentobjectives.

• Primary Output: a roadmap that evolves the ‘as-is’ businessprocesses, systems, information and technology of theenterprise from the ‘current state’ to the desired ‘future state’.

• Intent of EA process: Identify the impact of enterprisestrategies and influence lower-level tactical, operational, andproject decisions and activities to be more aligned withenterprise strategies.

The primary design goal for enterprise architecture mustThe primary design goal for enterprise architecture mustbe to enable efficient change in business capabilitiesbe to enable efficient change in business capabilities

through thethrough the servicesservices that enable them!that enable them!

9


Key Concepts in Enterprise Architecture

• Holistic View– Lots of other views– From Portfolio Management to Budget to HR

• Optimized for the Enterprise– Not the Business Unit– Not the Process– Not the Application– Not the Database– Not the Server– The problem of ‘point optimization’

• Not simply ‘IT standards’– Examples:

• This building• Designing an airplane

• EA is a ‘process’ not a ‘project’

Business Strategy

Current Objectives

Proc

esse

s

Systems & Infrastructure

Data & Information

10


EA Supports SOA and More…

LicenseCompliance

Skills Planning

AssetRedundancies

StandardsCompliance

ApplicationPortfolio Risk

Outsourcing Security/PrivacyCompliance

ProjectImpactAnalysis

ProcessOptimization

Business CaseAnalysis

ResourceAllocation

FINANCIALCOMPLIANCE

ASSETSPROJECTS

StrategicPlanning

PerformanceManagement

BusinessResumptionPlanning

TransitionPlanning

EA Processand

Knowledge Base

ServicesDesign

ServicesDelivery

11


An Enterprise Architect’s view of SOA

Business Strategy

Current Objectives

Proc

esse

s

Systems & Infrastructure

Data & Information

Enterprise Capabilities

Services Catalog

InfrastructureServices

BusinessServices

InformationServices

ApplicationServices

EA RoadmapCurrent

StateFutureState

ProjectPortfolio

Analysis


An Enterprise Architecture Model view of SOA

ValueNetworkAnalysis

BusinessScenarioModels

InformationValue Chain

Analysis

BusinessEvent

Analysis

Function/Process

Decomposition

IntegrationModels

Services LevelServices Level

Enterprise Solutions ArchitectureEnterprise Solutions ArchitectureEnterprise Technology ArchitectureEnterprise Technology Architecture

Enterprise Information ArchitectureEnterprise Information Architecture

Enterprise Business ArchitectureEnterprise Business Architecture

BI

TS

Capabilities LevelCapabilities Level




BI

TS

Scenario LevelScenario Level




BI

TS

““The Big PictureThe Big Picture””




BI

TS

EnterpriseBusinessStrategy

EnterpriseIntelligence

ServiceCatalog

SolutionsPortfolio

EnterprisePrinciples

(CA)

RequiredCapabilities

(CRV)

UseCases

ContextDiagrams

SwimlaneDiagrams

ServiceFunctionModels

ITStandards


Continued …

Services LevelServices Level




BI

TS

IntegrationModels Service

Catalog

SolutionsPortfolioUse

Cases

ServiceFunctionModels

ITStandards

InfrastructureServices

BusinessServices

InformationServices

ApplicationServices

Ente

rpri

se C

apab

iliti

es

= +

14


A Service Oriented Architect’s view of SOA

Data Abstraction

Data Data

Data Services/Messaging

LegacyLegacy LegacyLegacy

Services

Process/Orchestration

Monitoring/Event ManagementG

overnance

Rep

Security

Internet-Based

ServicesNew Services


So, the EA “Mega Trends”

1. SOA, SOA, SOA!2. SaaS3. “Web 2.0”4. “Enterprise 2.0”

– Mashups– Inside-out– Outside-in

5. Incorporating existing EnterpriseArchitecture concepts andpractices…how?

16


What should EA do for SOA projects?

• Standardization– Infrastructure (hw, sw, network)– Messages (format, content, delivery, use case)– Data content/names/definitions/ownership– Business Rules & Events

• Drive towards common semantics between EA and SOA• Be proactive in identifying services that should be built and

identifying the development efforts that are positioned to deliverneeded services

• Broader than the project view– Scope of analysis and design– Models for impact analysis and integration planning

• Research and recommend SOA technology choices, approachesand designs

• Collaborate on technology choices, approaches and designs thatcan satisfy a broader part of the enterprise

• Extend the application of successful SOA implementations toother parts of the enterprise

• Governance integration• CULTURE CHANGE!!!


What should SOA projects do for EA?

• Create and populate EA repository with appropriatedocumentation

• Comply with existing EA standards, when possible• Demonstrate need for new standards or extensions to EA• Provide an opportunity for SOA Proof-of-Concept (POC)• Contribute to the ongoing evolution of EA standards,

patterns and models• Seek service reuse opportunities• Bind services with appropriate partners• Create long term service development, deployment, and

management plan• Link back to proper EA methods


What should SOA and EA do together for thebusiness?

• Deliver the needed Enterprise Capabilities• Identify the potential investments required to build an SOA• Develop a Service Catalog• Foster a collaborative reuse-oriented culture as a model for

the rest of IT• Identify opportunities to externalize business services, as

well as identify external services for consumption• Continue to measure agility and reuse, and adjust as

needed• Monitor the integration with partners• Continue to monitor the value to business


Object

ObjectObject

Object

Standard Service Request

Standard Service Response

Perfo

rm

PerformPerform

CLIENT(Service

Requestor)

ServiceProviderWORK

Perfo

rm

NEED

FOR

SERVICE

Object

ObjectObject

Object



Perfo

rm

PerformPerform

CLIENT(Service

Requestor)

ServiceProviderWORK

Perfo

rm

NEED

FOR

SERVICE

ExecutiveManagement

ExistingOperations

EnterpriseArchitecture

BusinessStrategy

ProjectPortfolio

New/ChangedCapabilities

Required Models of theFuture StateEnterprise

Models of theCurrent State

Enterprise

Project B

Object

ObjectObject

Object



Perfo

rm

PerformPerform

CLIENT(Service

Requestor)

ServiceProviderWORK

Perfo

rm

NEED

FOR

SERVICE

Project A

Object

ObjectObject

Object



Perfo

rm

PerformPerform

CLIENT(Service

Requestor)

ServiceProviderWORK

Perfo

rm

NEED

FOR

SERVICE

Project C

Build &Integrate

Build &Integrate

Build &Integrate

PopulateNew/Changed

Capabilities Delivered

TacticalProject

Requests

InputAnnual, Tactical

Goals, Objectives& Targets

Influences

EA Roadmap• Project Requests• Adds/Changes to Applications,

Infrastructure, Information, &Business Processes Services

• Timeline/Interdependencies

GOVERNANCE

How do you bring these two together?

20


Implications on Governance

EA Governance• Ensuring that duplicate services are not

created• Compliance with standards / exemptions /

extensions• Ensuring service levels are defined and

approved– Need appropriate metrics

• Change management more complex –unknown service consumers

• Manage the portfolio of services

SOA Governance• SOA Governance becomes a sub-discipline to

EA Governance• Design Time SOA Governance

– A registry and/or repository for the tracking ofservice design, management, policy, security,and testing artifacts.

– Design tools, including service modeling,dependency tracking, policy creation andmanagement, and other tools that assist inthe design of services.

– Deployment tools, including servicedeployment, typically through binding withexternal development environments.

– Links to testing tools and services, providingthe developer/designer the ability to create atest plan and testing scenarios, and thenleverage service testing technology.

• Run-Time SOA Governance– Service discovery– Service delivery– Security– Setting and maintaining appropriate service

levels– Managing errors and exceptions– Enabling online upgrades and versioning– Service validation– Auditing and logging

DesignTime

RunTime


Final Thoughts

• EA is an evolving discipline. New notions and business eventswill drive EA activities going forward.

• SOA is part of EA. We have a tendency to forget that. The “A” inSOA is architecture.

• Learn how to see beyond the SOA hype, and make sure tounderstand your own business issues.

• Accept the emerging Web as a resource that is to be leveraged forthe good of the company. There will be much change here.

• The enterprise architect should drive change for the good of thecompany. However, never “manage by magazine.”

• The lines are blurring between enterprise applications and theemerging Web. There is a fundamental shift in how we deployand manage enterprise applications and services going forward.

• Project architects may lead, or EA may lead, but they must workcollaboratively to advance SOA beyond marginal point successes

22


Q & A

To submit your questions, please click on the “Q&A” tab onthe bottom right-hand corner of your screen.

Microsoft PowerPoint - When EA and SOA Worlds Collide ...

Documents

Transcript of Microsoft PowerPoint - When EA and SOA Worlds Collide ...