An Overview of Total ArchitectureTotal...

An Overview ofTotal ArchitectureTotal ArchitectureBPM and SOA In Practice

Paul C. Brown, Principal Software Architect

© 2009 TIBCO Software Inc. All Rights Reserved..

In the Beginning, Architecture was Simple…

… and evolved slowly… and evolved slowly


2

Transport Technology Helped Communities to Emerge…

… and grow… and grow


3

Better Infrastructure Fostered Denser Communities…

… and more of them


4

So How Do You Organize and Manage All This?

How do you ensure you get the business results you want?want?The desired business benefitWithin cost constraints


5

Within cost constraintsWhile preserving the flexibility to address tomorrow’s needs

Enterprise ComplexityComplexity


The Idealized Enterprise View Looks Simple

A functional organization with well-defined responsibilities…


7

But There Is a Lot of Dialog Between the Organizations

How do you make sense of this?


8

You Think in Terms of Business Processes

This picture pdoes not tell you how the order-to-cash process actually works


9Order-to-Cash Process Scope

Business Process Models Provide That Understanding

Activities and their structure

ParticipantspSwimlanes represent

rolesActivities in the lanes

represent responsibilitiesrepresent responsibilities

Interactions between participantsArtifacts

• Messages• Physical objects

Relationships to activitiesp

Interactions with other business processesWhere does the product


10

Where does the product catalog come from?

You Must Think About Information as Well

Understanding utilization scope tells you little

tells you little about the information itself


11

Sales Order Information Usage

Logical Data Models Provide That Understanding

But they don’t characterize:

Shipping NoticeAddress0..1 characterize:

Who owns the data

• OrganizationShipment Order

Invoice

-invoiceAmountSales OrderCustomer1 0..*

1 10..1

1 *

-billingAddress -shippingAddress

• Organization• System

Where the dataShipment Order Line ItemSales Order Line Item

-status

Shipment

1 0..

0..1

1 0 *

**

Where the data physically lives

Shipment Order Line Item

-quantityShipped-quantity-price

1 0..*

*

Where data is replicated

• How consistency is

Saleable Product

-SKU

1


12

consistency is maintained

Each “Organization” is Actually a Stack

There may be multiple pcomponents at each layer:

I t f

InterfacesLogic componentsData componentsData components Infrastructure


13

Traditional Means of Supporting Organizational Interaction

Conversation Human level Human level

EAI

EAI Logic level

ETLData levelData level


14

People May Interact with Multiple Systems

EAI and ETL can be used within an organization as well


15

Overall, Understanding Interactions is Complicated

People

InterfaceLogicDataInfra



People People

People




People

People




People




People




People

InterfaceL iInterface Interface

People

InterfaceL iInterface Interface




People

InterfaceLogicData

InterfaceLogic

InterfaceLogic







People

InterfaceLogicData

InterfaceLogicD

InterfaceLogicD tData

InfraLogicDataInfra

LogicDataInfra

People




DataInfra

LogicDataInfra

LogicDataInfra


16

This is the problem that SOA and BPM are supposed to solve!Infra Infra

The Concept of Total ArchitectureTotal Architecture


The Enterprise is an Operation

Enterprise operations transform inputs into outputs using resources (employees, systems, facilities)

Enterprise

customers goods

customer payments

customer orders

shipping notices

services

: Enterprise Operations

customer invoicessuppliers

supplier paymentssupplier invoices

purchase orders

employees

materials

facilitiessystems


18

p y y

Enterprise Operations are Comprised of More Specialized Operations

Enterprise Operations

Operations interact with one another via artifacts

: Logistics Operations : Sales Operations fulfillment requests

warehoused goodscustomer orders

customers

materials services

Enterprise Operations

: Manufacturing Operations : Purchasing Operations

warehoused goods

h t

customer orders

shipping notices

suppliers

materials

goods

customer invoices

purchase request

supplier invoices

purchase orders

shipping notices

: Financial Operationscustomer paymentssupplier payments

employees facilitiessystems


19

Your enterprise is a network of interacting operations

Operations Execute via One or More Business Processes

customer paymentscustomer invoicescustomer order

Financial Operations

: Accounts Receivable Process

customer paymentscustomer invoices

shipping notices

customer order

supplier paymentssupplier invoicespurchase orders

: Accounts Payable Process

Viewed from the operation’s perspective, the business process appears to be local


20

In Reality, Processes Interact with Other Processes

accept order

close order

order paid in full notificationcustomer order

ship goods

fulfillment request

payment due date

shipping notice

generate invoice

receive payment

reconcile with invoice

record open order

reconcile with order

record order paid

in fullon time, right amount?

payment due date

Yes

customer paymentcustomer invoice

notice of receipt

goods


21

pay invoicereceive goods

Changes Commonly Impact Multiple Operations

Artifact changes alter both producing and consuming operations and their systems

Participant changes (human or system) impact mechanisms for producing and consuming artifacts

Process structure changes can impact the sequencing of interactions with other operations

Speeding up a process may also require speeding


22

up related processes in other organizations

Changes Impact Both Business Process Design and Systems Architecture

Changing who plays a role

Introducing intermediaries y

(person or system)

(services) to isolate parties from changes

change role 1 change role 2 introduce an intermediary

role 1 : role 1 :role 2 :role 1 : Person

role 1 : Person role 2 :

Personrole 2 : Person

role 2 : System

service : Systemrole 1 :

Systemrole 2 : Systemrole 1 :

System


23

Reference Data Touches Many Business Processes

Changing a ProductID format can impact many processesRemember the 5-digit zip code?

Purchase Materials Manage AccountsProduction PlanProduct BOM

+productID()

Product Manufacturing Costs

+productID()Product Design Specification

+productID()Manufacture Products

+productID()p ()

+productID()Design Product

Product Manuals

+productID()Product Concept Product Catalog

Product

+productID()

C t li N P d t

Manage Product Inventory

Support ProductsProduct Concept

+productID() +productID()


24

Execute Marketing CampaignsConceptualize New Product

Sell Products

For Success, A Total Architecture Perspective is Required

Business ProcessesSales order managementI t tInventory managementAccounting

PeopleParticipants in the

business processes Information

Wh t i f ti i b iWhat information is being used

SystemsComputers networksComputers, networks,

applications, infrastructure

Business Purpose


25

p

TIBCO BPM/SOA Execution Model

Execution Strategy Solutions & Operations

Step 1 Step 2 Step 3 Step 4 Step 5 Step 6

Operate theBusiness

Develop Vision &ProgramRoadmap

Define &Implement

Organization & Governance

Define &ImplementTechnical

Infrastructure &

AnalyzeProcess &DevelopProject

Design, Build& DeployBusinessProcess


Repeat foreach project

Roadmap Governance Standardsj

Roadmap Process

Continuous ImprovementContinuous ImprovementGovernance

Project Life Cycle Management and ControlMeasure Business IT and Organizational KPIs & SLAs / Analyze ROI


26

Measure Business, IT and Organizational KPIs & SLAs / Analyze ROI

Vision

Focus on business processes firstThey are the source of business valueThey are the glue that binds people and systems together

Figure out what it is before you try to improve it!Lack of Overall Process Responsibility

Services and Integrations that Span Silos

p y

Shrinking Time

Frames

ApplicationSil

ApplicationSilo

BPM/SOASil

ApplicationSil

Front-Office Applications

External A li ti

Data Center


27

Silo Silo Silo Silo

Communications and Services Infrastructure

Applications Applications

Vision

SOA and BPM refine the traditional structure Introduce a separation between processes and services

The business process is a first-class architectural concept Their structure needs to be aligned with both organizations and systems Processes interact with one another just like systems do!j y

Processes are assembled from services Some performed by people, others by systems Ideally each service gets used in multiple business processes Ideally, each service gets used in multiple business processes


28

Vision

Separate service access mediation from services Service access control based on

Security Quality-of-service agreements

Routing of service requestsL d di t ib ti lti l i id Load distribution across multiple service providers Logging of service utilization Performance and SLA measurements


29

Vision

Acknowledge different types of processesUnmanaged Processes

• Components/services are “hard wired” together to form the actual process• One component’s results become the inputs to the next component• Proactive monitoring and breakdown recovery is required for high

availabilityavailability

Managed/Orchestrated Processes• One component coordinates the work of other components and services• Manager can monitor process status• Manager can monitor process status• The process of starting the manager is always an unmanaged process!


30

Managed Processes Often Span Multiple Systems

Process manager may need to access data (or non-service functionality) directly when it is not available


31

service functionality) directly when it is not available as a service

Packaged Application Workflow

Generally assumes that the activities being managed are: Generally assumes that the activities being managed are: Executed via the application interfaces Implemented within the application

Facilities for managing external activities are generally limited Facilities for managing external activities are generally limited Lack full EAI suite required for convenient management

User interface is generally not extensible Diffi lt t dd /diff t i t f


32

Difficult to add new/different interfaces

Augmented Packaged Application Workflow

Uses EAI and ETL to coordinate with activities in independent applicationsp pp

No overall process managerPart of process is “hard wired”


33

pDefeats purpose of using workflow

Generic Workflow Engine

Designed to coordinate activities no matter where they are Able to access services where they are available Able to leverage EAI technologies to access non-service

functionalityT l t i t f f


34

Truly separate interface from process

Hard-Wired Processes May Involve Any Technology

Often hybrids of SOA, BPM, and older technologiesEAI and ETL remain importantEAI and ETL remain importantEAI provides the “events” for an event-driven process

Note the absence of a manager!


35

Note the absence of a manager!

Hard-Wired Processes Often Require Monitoring

SLAs require monitoring and critical processes require breakdown detection

Complex event processing (CEP) provides the basis for this Complex event processing (CEP) provides the basis for this type of monitoring Event recognition/capture remain challenges

Master data management has a similar distributed architecture


36

Master data management has a similar distributed architecture Blend of ETL, EAI (events), and workflow to keep data consistent

Events are What You Can Observe

Providing meaning to

Purchase Order

gthem requires associating

ProductSpecification

Purchase Request

associating them withProcesses

on

ProductShipment Notific

ation

DataHistory

Product Catalog

Shipment Order

Product Inventory

Shipment

Sales Order


37

Complex Event Processing (CEP) Provides the Tools

Concept models provide the

Shipment Order

Shipping Notice

Invoice

-invoiceAmountSales OrderCustomer

Address

1 0 *

0..1

1 10..1

1 *

-shippingAddress-billingAddress

provide the data context

State models represent

Shipment Order Line Item

-quantityShipped

Sales Order Line Item

-quantity-price

Saleable Product

-SKU

Shipment Order-status

Shipment

1 0..*

0..1

1 0..*

1

*

**

represent process milestones

Event history

S U

Event history allows changes to be identified

Generated events announce conclusions


38

conclusions

Vision

Separate processes and presentationSometimes you want to make the same process available via

different channelsdifferent channels• Avoid duplicating the business rules

Some of the channels may not be conventional presentations• May provide web-service accessMay provide web service access

In such cases, you want to make the process itself into a service

• Accessible from a variety of presentation componentsy p p


39

Vision

Embrace total architectureSOA and BPM provide many opportunities to organize and

h imanage the enterprise

The challenges are organizational as well as technicaltechnical


40

Services


What Is a Service?

A service is a reusable unit of functionality with standardized interfaces


42

Benefits of Services

ReuseSaves money - avoid the cost of replicating functionality

Faster time to market for projects - reduced need for development

Isolation of service consumerService provider design can evolve without impactService provider can be replaced without impact

FlexibilityPlatform independence - provide functionality anywhere and access

it from anywherey

All benefits require service interface stability!Win occurs when interface is more stable than the functionality on

ith id


43

either side

Where Do Services Make Sense?

When there is functionality that is either used in more than one place or is provided in more than

l ti l l h th “ l ”one place, particularly when those “places” are different applications


44

Service Granularity

The amount of work encapsulated by each service operationC i d l t l ti l l t fCoarse grained – encapsulates a relatively large amount of

functionality• Generate Bank Statements for all current accounts

Fine grained encapsulates a relatively small amount ofFine grained – encapsulates a relatively small amount of functionality

• e.g., Withdraw Cash

For a service to make sense the overhead involved For a service to make sense, the overhead involved in invoking an operation must be less than the amount of work performed by the operation


45

Architecting Composites

Composites can directly invoke lower level services

BUT nested service calls may not perform well (particularly retrieving the status information)Underlying services may not be able to handle the loadUnderlying services may not be able to handle the load

Performance may be better if the underlying service publishes status information to the composite


46

Service Identification

Approaches

There are three starting points for identifying services:

1. Top-down from Business processes

2. Middle-out: from functional perspective

3. Bottom-Up from Data


47

Withdraw Cash Business Process

We are going to design the two service operations required to support the Withdraw Cash business process Obtain disbursal authorization Report funds disbursal Report funds disbursal

Business Processes and the Service Operations they use

: obtain disbursal authorization

Transfer Funds


Withdraw Cash


: report funds disbursal

: deposit funds


: report funds disbursal

Make Deposit

: deposit funds

p

The underlying service and its operationsAccount Balance Management Service+obtain disbursal authorization()+report funds disbursal()Service Operations


48

+report funds disbursal()+deposit funds()+get balance()

Service Operations

Example 1: Withdraw Cash Using Services

swipe card and enter PIN display transaction choices

ATM System

ATM ServerATM Machine

Bank SystemCustomer

cardID - bankassociation

ATM Card

PIN

select withdraw cash

enter amount call obtain disbursal authorization

service operation

prompt for amount

determine bank and forward request

: Disbursal Authorization Request

: Disbursal AuthorizationRequest

identify customer,identify account,authorize disbursal

forward request

forward response : Disbursal Authorization Reply

Request

: Disbursal Authorization Reply

remove cashcall report funds disbursed

service operation

dispense cash

approved?

: Disbursal Report

cash

cash

Yes

update account balance

forward acknowledgement

forward report

: Disbursal Report ACK

: Disbursal Report

: Disbursal Report ACK


49

remove receiptprint receipt and return

atm cardreceipt

Proposed Utilization Context

Who is providing the service? Externally provided services

• Read-only, updating

From trusted partners In-house services only In house services only

• Consumed internally• Consumed externally

How does it fit into the Business Process?Functional requirementsqNon-functional requirements Is the service appropriate for use in the different business

processes?


50

processes?• In particular the granularity of the service

Qualification

Is there more than one utilization context? If not, what is the justification for making this a service?

Does the service fit all the proposed utilization contexts?GranularityVolumeResponse timeResponse time

Has the proposed service been reviewed by the stakeholders that will use the service?stakeholders that will use the service?


51

Hierarchical (Federated) Service Busses

<<component>>Enterprise Service Bus

Domain A Domain B

W Enterprise Service Provider Interface

A1 EnterpriseServiceProviderInterface

Z EnterpriseServiceProviderInterface

X EnterpriseServiceProviderInterface

Y EnterpriseServiceProviderInterface

EnterpriseService

Interfaces

<<component>>Domain A

Service Bus

<<component>>Domain B

Service Bus

Domain A Service

Interfaces

<<component>>Service

X DomainServiceProvider

Ineterface

A1 DomainServiceProviderInterface

Y DomainServiceProviderInterface

Z DomainServiceProviderInterface

W DomainServiceProviderInterface

Domain BService

Interfaces

Service Adapter A1

Z NativeInterface

NativeInterface

Y NativeInterface

W Native Interface


52

<<component>>Application Z

<<component>>Application W

<<component>>Application X

<<component>>Application Y

Policy Enforcement Points

<<component>>Enterprise Service Bus

Domain A Domain B

W Enterprise Service Provider Interface

A1 EnterpriseServiceProviderInterface

Z EnterpriseServiceProviderInterface

X EnterpriseServiceProviderInterface

Y EnterpriseServiceProviderInterface

EnterpriseService

Interfaces

<<component>>Domain A

Service Bus

<<component>>Domain B

Service Bus

Domain A Service

Interfaces


X DomainServiceProvider

Ineterface

A1 DomainServiceProviderInterface

Y DomainServiceProviderInterface

Z DomainServiceProviderInterface

W DomainServiceProviderInterface

Domain BService

Interfaces

Service Adapter A1

Z NativeInterface

NativeInterface

Y NativeInterface

W Native Interface


53

<<component>>Application Z

<<component>>Application W

<<component>>Application X

<<component>>Application Y

Service Mediation

Managing the interactions between service provider and consumer

Typical mediation activitiesData transport and transformationData transport and transformationService distribution and routingService access control

These activities are typically responsibilities of an enterprise service bus (ESB)enterprise service bus (ESB)


54

Abstracted Location and Access Control

Abstracting out physical location of the service provider and the access control of the service

ServiceConsumer

ServiceConsumer Service

Consumer

provider

SOAP over HTTP

-physicalDestination

SOAP over JMS

-logical destinationEnterprise Service Bus

+accessControl()

Proxy

+accessControl()SOAP over HTTP

-logical destinationSOAP over HTTP

ServiceProvider Service

Provider

ServiceProvider

-physical destination

SOAP over JMSSOAP over HTTP

-physicalDestination


55

+accessControl()

Provider

......

Distributed Systems Require Distributed ESB

Service consumers and providers may be at different geographic locations

Routing of requests may require introspection of the request message data

bank teller application

ESB Node in North America ESB Node in Europe

Routing of request based on location of account1.1:

Request for Account Information1:

north american accounts : Customer Account Service european accounts : Customer Account Service

Submission of request to service provider1.1.1:


56

ActiveMatrix Service Grid – Logical Next Step

Out-of-Grid Service Consumer

*

In-Grid Service Consumer InterfaceIn-Grid Service Consumer

**

Concrete WSDL Interface1

Active Matrix Service Grid Node

+accessControl()+geographic and logical routing() Routing

*

Abstract WSDL Interface1Abstract WSDL Interface1Service producers and consumers using location- g g p g g()

+consumer-providerMapping()+mapping to concrete WSDL for external interactions()

Routing*

Abstract WSDL Interface1

*

Abstract WSDL Interface1

*

using locationindependent service definitions

In-Grid Provider InterfaceIn-Grid Service Provider

Concrete WSDL Interface1

*


57

Out-of-Grid Service Provider

Communications in ActiveMatrix

Node 1 Node 2

ServiceConsumer in

ServiceConsumer in

ServiceProvider in

ServiceProvider in Consumer in

ContainerConsumer in

ContainerProvider inContainer

Provider inContainer

Policy Policy PolicyPolicy

Message Normalization and Routing Message Normalization and Routing

Agent Agent AgentAgent

EMS


58

Policy Type Summary*

EJB BPEL .NET AxisAuthenticationAuthorization

Policy Agents

S i B

AuthorizationEncryptionSignature

Policy Store

Service BusSignatureLoggingTracking

SecuritySLA

Version

P1P2P3P4

TrackingAuditingRoutingRoutingSchema Validation


59

* Availability of specific policies varies depending upon agent location(proxy,embedded), type of binding, and implementation type.

Policy Independence

Policies and services are managed independently

Business Analyst

Developer

Deploy DeployAdmin

Deploy Deploy

ManageServiceLifecycle

Enforce PolicyLifecycle

Ops


60

Runtime Policy Architecture

Business Works EngineService Consumer Policy Agentservice request

service reply

service request

service reply

Stand-alone Business Works and Policy Agent

Active Matrix Service Grid Node

service request service requestBusiness Works EngineService Consumer Policy Agent

service reply

qservice reply

Service consumer may be anywhere

Business Works and Policy Agent in an AMX Service Grid Node


61

y g

The Security Credential Problem

Different systems require different credentials

Older systems are not capable of using modern O de syste s a e ot capab e o us g odecredentials

Many systems are not designed to pass credentials from input to outputOften use “trusted system credentials” to access back-end

systemssystemsTypically different security credentials

<<component>>Front-End System

<<component>>Back-EndSystem


B k E dS iU


62

System SystemBack-EndInterface

ServiceInterface

UserInterface

Solution Requires Mix of Old and New Technologies

Modern front-end systems can pass user credentials through to services (where appropriate)

Policy rules can check credentials at any modern interface

Policy rules can map new credentials to back-end system credentialsServices and adapters remain unaware of credential mappingServices and adapters remain unaware of credential mapping

requirements

<< t>> << t>> << t>><< t>>

Use policy to map incoming credentials to back-end interface credentials

Pass through user credentials (if appropriate)


<<component>>Adapter

<<component>>Back-EndSystem

<<component>>Front-End System Back-End

InterfaceUser

InterfaceServiceInterface

AdapterInterface


63

Policy-enabled Interfaces

The MDM Problem

Where’s the customer?

<<component>><<component>><<component>><<component>> <<component>>Investment

Banking System

-accountInfotH ld I f

<<component>>Credit Card

System

-accountInfo-accountHolderInfo

<<component>>Mortgage System

-accountInfo-accountHolderInfo

<<component>>Retail Banking

System

-accountInfo-accountHolderInfo-accountHolderInfo


64

The Data Warehouse Approach

Data inconsistencies are <<component>>

Credit Card<<component>>

Mortgage<<component>>

Investment<<component>>Retail Banking

never resolvedMerge logic becomes

increasingly complex

Credit Card System

-account-accountHolder

Mortgage System


Investment Banking System


Retail Banking System


increasingly complex

No home for additional data <<flow>>

ETL Extract

<<flow>>

ETL Extract

<<flow>>

ETL Extract

<<flow>>

ETL Extract

additional dataE.g. relationships

between customers<<component>>

Data Warehouse

-customer

Only as current as the last ETL extract

customer-account


65

The MDM Approach

MDM includes data maintenance

U d t t i t i

<<component>>Operational Data Store

-customerUpdates to maintain

consistencyWorkflow to reconcile

-account

<<flow>>

Updates

<<flow>>

Changes

inconsistencies

MDM can house additional data

+getCustomer()+updateCustomer()+reconcileDiscrepancy()

<<component>>MDM System

<<flow>>Updates

<<flow>>Updates

<<flow>>Updates

<<flow>>Updates

additional dataE.g. relationships

between customers <<flow>>Changes

<<flow>>Changes

<<flow>>Changes

<<flow>>Changes

ODS required for high-volume query

<<component>>Investment

Banking System

-account

<<component>>Mortgage System


<<component>>Credit Card

System


<<component>>Retail Banking

System

-account


66

MDM maintains ODS contents

-accountHolderaccount

-accountHolder

Transactional Data Requires a Separate Path

Data typically does not require MDM

<<component>>Operational Data Store

-customeraccountq

resolution logic

Frequency of update << t>>

-account

<<flow>>

Changes

<<flow>>

Updates

inappropriate for MDM tooling +getCustomer()

+updateCustomer()+reconcileDiscrepancy()

<<component>>MDM System

<<flow>>Updates

<<flow>>Updates

<<flow>>Updates

<<flow>>Updates

Stored data is often an aggregate/summary <<component>> <<component>> <<component>><<component>>

<<flow>>Changes

<<flow>>Changes

<<flow>>Changes

<<flow>>Changes

gg g yof transactional data Implemented with

traditional event driven

componentMortgage System


componentCredit Card

System


componentInvestment

Banking System


componentRetail Banking

System


<<flow>> <<flow>>


67

traditional event-driven approach

<<flow>>Transactional Data

<<flow>>

Transactional Data



T l A hiTotal Architecture SynthesisEfficiently Developing Solution ArchitecturesSolution Architectures


Positioning Architecture in the Project Life Cycle

Define Requirements

Charter Project

Business Benefit, Cost and Schedule Expecations

Define Requirements

B i P D fi i i

Define Business Process Architecture

Business Process Requirements Total Architecture

Synthesis

Define Systems Architecture

Business Process Definitions

Component Structure and Responsibilities

KnowlegeGained

fromUsing

yScope

Implement Components and Services

System Specify Components and Services

Component and Service Specifications

Assemble and Test System

Unit-tested Components and Services

Working System


69

Deploy and Use System

Architecture Method: An Iterative Approach


70

O i ti lOrganizational Issues


Business Processes and Services Cross Organizational Boundaries

Services and Integrations Span Silos

Lack of Overall Responsibility

ServiceInterface

Shrinking Time

Frames

Data Center

ApplicationSilo

ApplicationSilo

Services, Integration,

andProcess

ManagementSilo

ApplicationSilo


External Applications


72


Many Development Processes Have Become Degenerate

They assume a single system is being worked on

Development QA ProductionRequirements


73

Degenerate Processes Will Not Work for SOA and BPM

Multiple organizations and systems are involved

Development QA ProductionRequirements


74

A Richer Development Processes Is Required

Governance at work!


75

Who Owns Projects That Span Silos?

Business Executive Sponsor

IT Executive Sponsor

Who owns projects that span silos?

Business Manager

Business Manager

Business Manager

Business Manager

Business Manager

Services,

Data Center

IT System Owner

IT System Owner

IT System Owner

IT System Owner

IT System Owner

IT System Owner

ApplicationSilo

ApplicationSilo

,Integration,

andProcess

ManagementSilo

ApplicationSilo




76

Communications Infrastructure

Multi-Silo Projects Include Members from All Silos

3 key leadership roles needed onroles needed on every project


77

The Executive Sponsor Can’t Oversee All These Projects


78

Enterprise Projects Group Should Manage These Projects

The group provides a reporting structure for projects that span organizational silos


79

Who Provides the Cross-Project Service Perspective?Wh l k h d f f t ?

New Service

Who looks ahead for future usages?

Today’s Project

ServiceInterface

Future Project Call New

Service

ServiceInterface

Future Project Call New

Service


80

Service

The Enterprise Architecture Group Coordinates Projects

Establishes the visionEnsures projects collectively

converge on a singleEnterprise

Architecture converge on a single coherent architecture

Maintains cross-silo perspective at all levels

Architecture

Business Process Architecture

Systems Architecture Data Architecture

perspective at all levelsBusinessApplication

Infrastructure Architecture

Infrastructure

Responsible for:Architecture

Application Architecture

Services ArchitectureStandardsBest practicesG

Architecture


81

Governance

Total Architecture ManagementTotal Architecture

Management

E t i EnterpriseEnterpriseProjects

EnterpriseArchitecture

Business Process Architecture

Project Manager

Systems Architecture

Application Architecture

Business Process Architect Systems Architect

Architecture

Infrastructure Architecture

Project Manager

Business Process Architect

Services

Data Architecture

Project Manager

Systems Architect

Services Architecture


82Business Process Architect

Systems Architect

The Completed Organizational Picture

Business Executive Sponsor

IT Executive Sponsor

Business Manager

Business Manager

Business Manager

Business Manager

Business Manager

Total Architecture Management

Data Center

IT System Owner

IT System Owner

IT System Owner

IT System Owner

IT System Owner

IT System Owner

ApplicationSilo

ApplicationSilo

Services, Integration,

andProcess

ManagementSilo

ApplicationSilo




83


Key Questions

Is there an architect on every silo-spanning project? Responsible for end-to-end business process and systems

design

How Are cross silo projects managed? How Are cross-silo projects managed? Who negotiates with silos? Who resolves conflicts?

Who validates the future applicability of services? Functionality Granularity SLAs


84

The Challenges of Silo-Spanning Projects Are Diverse

Knowledge is scattered throughout the enterprise

For success, business and IT must align Total architecture focus on producing business value

New skill sets are required Total (business process and systems) architecture( p y ) Project management focused on business results

Clear ownership and control is needed for cross-silo projectscross silo projects

Executive sponsorship is needed to align priorities Resolve political conflicts

A Proactive Enterprise Architecture group is required Guide multiple projects towards a cohesive whole

Governance is essential


85

Governance is essential

The SOA Manifesto: http://soa-manifesto.org

Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying

service orientation.

We have been applying service orientation to help organizations consistently deliver sustainable business value, with increased agility and cost effectiveness, in line with

changing business needs.

Through our work we have come to prioritize: oug ou o e a e co e to p o t e

Business value over technical strategy

Strategic goals over project-specific benefits g g j

Intrinsic interoperability over custom integration

Shared services over specific-purpose implementations

Flexibility over optimization

Evolutionary refinement over pursuit of initial perfection


86

That is, while we value the items on the right, we value the items on the left more.

Guiding Principles: we follow these principles

Respect the social and power structure of the organization. Recognize that SOA ultimately demands change on many levels. The scope of SOA adoption can vary. Keep efforts manageable and within

meaningful boundariesmeaningful boundaries. Products and standards alone will neither give you SOA nor apply the service

orientation paradigm for you. SOA can be realized through a variety of technologies and standards. Establish a uniform set of enterprise standards and policies based on industry, de

facto, and community standards. Pursue uniformity on the outside while allowing diversity on the inside. Identify services through collaboration with business and technology stakeholders. y g gy Maximize service usage by considering the current and future scope of utilization. Verify that services satisfy business requirements and goals. Evolve services and their organization in response to real use. Separate the different aspects of a system that change at different rates. Reduce implicit dependencies and publish all external dependencies to increase

robustness and reduce the impact of change. At every level of abstraction, organize each service around a cohesive


87

y , gand manageable unit of functionality.

SOA Manifesto AuthorsAuthors

Ali ArsanjaniGrady Booch

Thomas ErlNicolai Josuttis

Joe McKendrickSteve Ross-TalbotGrady Booch

Toufic BoubezPaul C. BrownDavid Chappell

Nicolai JosuttisDirk KrafzigMark Little

Brian Loesgen

Steve Ross TalbotStefan Tilkov

Clemens Utschig-UtschigHerbjörn WilhelmsenDavid Chappell

John deVadoss Brian Loesgen

Anne Thomas Manes Herbjörn Wilhelmsen


88

For More Information on Total Architecture…

Succeeding with SOA• The business and organizational

perspectiveperspective• For CxOs, managers, architects

I l ti SOA Implementing SOA• Creating the total architecture

• For enterprise and project architects, CTOs

TIBCO Accelerated Value Framework (AVF)

Operate theBusiness

Develop Vision &Program

Define &Implement

Organization &

Define &ImplementTechnical

I f t t &

AnalyzeProcess &DevelopP j t

Design, Build& DeployBusiness



89

ProgramRoadmap

Organization & Governance Infrastructure &

StandardsProject

Roadmap

BusinessProcess

An Overview of Total ArchitectureTotal...

Documents

Transcript of An Overview of Total ArchitectureTotal...