an overview of total architecturetotal...
TRANSCRIPT
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
© 2009 TIBCO Software Inc. All Rights Reserved..
2
Transport Technology Helped Communities to Emerge…
… and grow… and grow
© 2009 TIBCO Software Inc. All Rights Reserved..
3
Better Infrastructure Fostered Denser Communities…
… and more of them
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
5
Within cost constraintsWhile preserving the flexibility to address tomorrow’s needs
Enterprise ComplexityComplexity
© 2009 TIBCO Software Inc. All Rights Reserved..
The Idealized Enterprise View Looks Simple
A functional organization with well-defined responsibilities…
© 2009 TIBCO Software Inc. All Rights Reserved..
7
But There Is a Lot of Dialog Between the Organizations
How do you make sense of this?
© 2009 TIBCO Software Inc. All Rights Reserved..
8
You Think in Terms of Business Processes
This picture pdoes not tell you how the order-to-cash process actually works
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
13
Traditional Means of Supporting Organizational Interaction
Conversation Human level Human level
EAI
EAI Logic level
ETLData levelData level
© 2009 TIBCO Software Inc. All Rights Reserved..
14
People May Interact with Multiple Systems
EAI and ETL can be used within an organization as well
© 2009 TIBCO Software Inc. All Rights Reserved..
15
Overall, Understanding Interactions is Complicated
People
InterfaceLogicDataInfra
InterfaceLogicDataInfra
InterfaceLogicDataInfra
People People
People
InterfaceLogicDataInfra
InterfaceLogicDataInfra
InterfaceLogicDataInfra
People
People
InterfaceLogicDataInfra
InterfaceLogicDataInfra
InterfaceLogicDataInfra
People
InterfaceLogicDataInfra
InterfaceLogicDataInfra
InterfaceLogicDataInfra
People
InterfaceLogicDataInfra
InterfaceLogicDataInfra
InterfaceLogicDataInfra
People
InterfaceL iInterface Interface
People
InterfaceL iInterface Interface
InterfaceLogicDataInfra
InterfaceLogicDataInfra
InterfaceLogicDataInfra
People
InterfaceLogicData
InterfaceLogic
InterfaceLogic
InterfaceLogicDataInfra
InterfaceLogicDataInfra
InterfaceLogicDataInfra
InterfaceLogicDataInfra
InterfaceLogicDataInfra
InterfaceLogicDataInfra
People
InterfaceLogicData
InterfaceLogicD
InterfaceLogicD tData
InfraLogicDataInfra
LogicDataInfra
People
InterfaceLogicDataInfra
InterfaceLogicDataInfra
InterfaceLogicDataInfra
DataInfra
LogicDataInfra
LogicDataInfra
© 2009 TIBCO Software Inc. All Rights Reserved..
16
This is the problem that SOA and BPM are supposed to solve!Infra Infra
The Concept of Total ArchitectureTotal Architecture
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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()
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
Step 1 Step 2 Step 3 Step 4 Step 5 Step 6
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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!
© 2009 TIBCO Software Inc. All Rights Reserved..
30
Managed Processes Often Span Multiple Systems
Process manager may need to access data (or non-service functionality) directly when it is not available
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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”
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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!
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
40
Services
© 2009 TIBCO Software Inc. All Rights Reserved..
What Is a Service?
A service is a reusable unit of functionality with standardized interfaces
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
: obtain disbursal authorization
Withdraw Cash
: obtain disbursal authorization
: report funds disbursal
: deposit funds
: obtain disbursal authorization
: 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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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?
© 2009 TIBCO Software Inc. All Rights Reserved..
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?
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
<<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
© 2009 TIBCO Software Inc. All Rights Reserved..
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)
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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:
© 2009 TIBCO Software Inc. All Rights Reserved..
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
*
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
58
Policy Type Summary*
EJB BPEL .NET AxisAuthenticationAuthorization
Policy Agents
S i B
AuthorizationEncryptionSignature
Policy Store
Service BusSignatureLoggingTracking
SecuritySLA
Version
P1P2P3P4
TrackingAuditingRoutingRoutingSchema Validation
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
<<component>>Service
B k E dS iU
© 2009 TIBCO Software Inc. All Rights Reserved..
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>>Service
<<component>>Adapter
<<component>>Back-EndSystem
<<component>>Front-End System Back-End
InterfaceUser
InterfaceServiceInterface
AdapterInterface
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
-account-accountHolder
Investment Banking System
-account-accountHolder
Retail Banking System
-account-accountHolder
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
-account-accountHolder
<<component>>Credit Card
System
-account-accountHolder
<<component>>Retail Banking
System
-account
© 2009 TIBCO Software Inc. All Rights Reserved..
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
-account-accountHolder
componentCredit Card
System
-account-accountHolder
componentInvestment
Banking System
-account-accountHolder
componentRetail Banking
System
-account-accountHolder
<<flow>> <<flow>>
© 2009 TIBCO Software Inc. All Rights Reserved..
67
traditional event-driven approach
<<flow>>Transactional Data
<<flow>>
Transactional Data
<<flow>>Transactional Data
<<flow>>Transactional Data
T l A hiTotal Architecture SynthesisEfficiently Developing Solution ArchitecturesSolution Architectures
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
69
Deploy and Use System
Architecture Method: An Iterative Approach
© 2009 TIBCO Software Inc. All Rights Reserved..
70
O i ti lOrganizational Issues
© 2009 TIBCO Software Inc. All Rights Reserved..
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
Front-Office Applications
External Applications
© 2009 TIBCO Software Inc. All Rights Reserved..
72
Communications and Services Infrastructure
Many Development Processes Have Become Degenerate
They assume a single system is being worked on
Development QA ProductionRequirements
© 2009 TIBCO Software Inc. All Rights Reserved..
73
Degenerate Processes Will Not Work for SOA and BPM
Multiple organizations and systems are involved
Development QA ProductionRequirements
© 2009 TIBCO Software Inc. All Rights Reserved..
74
A Richer Development Processes Is Required
Governance at work!
© 2009 TIBCO Software Inc. All Rights Reserved..
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
Front-Office Applications
External Applications
© 2009 TIBCO Software Inc. All Rights Reserved..
76
Communications Infrastructure
Multi-Silo Projects Include Members from All Silos
3 key leadership roles needed onroles needed on every project
© 2009 TIBCO Software Inc. All Rights Reserved..
77
The Executive Sponsor Can’t Oversee All These Projects
© 2009 TIBCO Software Inc. All Rights Reserved..
78
Enterprise Projects Group Should Manage These Projects
The group provides a reporting structure for projects that span organizational silos
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
Front-Office Applications
External Applications
© 2009 TIBCO Software Inc. All Rights Reserved..
83
Communications and Services Infrastructure
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
© 2009 TIBCO Software Inc. All Rights Reserved..
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
Step 1 Step 2 Step 3 Step 4 Step 5 Step 6
© 2009 TIBCO Software Inc. All Rights Reserved..
89
ProgramRoadmap
Organization & Governance Infrastructure &
StandardsProject
Roadmap
BusinessProcess