An Overview of
Total Architecture
Total Architecture
BPM and SOA In Practice
In the Beginning, Architecture was Simple…
Transport Technology Helped Communities to Emerge…
… and grow
Better Infrastructure Fostered Denser Communities…
So How Do You Organize and Manage All This?
How do you ensure you get the business results you
want? want?
The desired business benefit
Within cost constraints
Within cost constraints
Enterprise
Complexity
Complexity
The Idealized Enterprise View Looks Simple
A functional organization with well-defined
But There Is a Lot of Dialog Between the Organizations
How do you
make sense of this?
You Think in Terms of Business Processes
This picture p does not tell you how the order-to-cash process
Business Process Models Provide That Understanding
Activities and their
structure
Participantsp
Swimlanes represent
roles
Activities in the lanes
represent responsibilities represent responsibilities Interactions between participants Artifacts • Messages • Physical objects Relationships to activitiesp
Interactions with other
business processes
Where does the product
Where does the product
You Must Think About Information as Well
Understanding utilization scope tells you little
tells you little about the
Logical Data Models Provide That Understanding
But they don’t
characterize:
Shipping Notice Address
0..1
characterize:
Who owns the
data • Organization Shipment Order Invoice -invoiceAmount Sales Order Customer 1 0..* 1 1 0..1 1 * -billingAddress -shippingAddress • Organization • System
Where the data
Shipment Order Line Item Sales 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 consistency is maintained
Each “Organization” is Actually a Stack There may be multiple p components at each layer: I t f Interfaces Logic components Data components Data components Infrastructure
Traditional Means of Supporting Organizational Interaction Conversation Human level Human level EAI EAI Logic level ETL Data level Data level
People May Interact with Multiple Systems
EAI and ETL can
be used within an organization as well
Overall, Understanding Interactions is Complicated People Interface Logic Data Infra Interface Logic Data Infra Interface Logic Data Infra People People People Interface Logic Data Infra Interface Logic Data Infra Interface Logic Data Infra People People Interface Logic Data Infra Interface Logic Data Infra Interface Logic Data Infra People Interface Logic Data Infra Interface Logic Data Infra Interface Logic Data Infra People Interface Logic Data Infra Interface Logic Data Infra Interface Logic Data Infra People Interface L i Interface Interface People Interface L i Interface Interface Interface Logic Data Infra Interface Logic Data Infra Interface Logic Data Infra People Interface Logic Data Interface
Logic InterfaceLogic Interface Logic Data Infra Interface Logic Data Infra Interface Logic Data Infra Interface Logic Data Infra Interface Logic Data Infra Interface Logic Data Infra People Interface Logic Data Interface Logic D Interface Logic D t Data Infra Logic Data Infra Logic Data Infra People Interface Logic Data Infra Interface Logic Data Infra Interface Logic Data Infra Data Infra Logic Data Infra Logic Data Infra
This is the problem that SOA and BPM are supposed to solve!
The Concept of
Total Architecture
Total 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 invoices suppliers supplier payments supplier invoices purchase orders employees materials facilities systems 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 goods customer 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 Operations customer payments supplier payments
Operations Execute via One or More Business Processes
customer payments customer invoices
customer order
Financial Operations
: Accounts Receivable Process
customer payments customer invoices shipping notices customer order supplier payments supplier invoices purchase orders
: Accounts Payable Process
Viewed from the operation’s perspective, the
In Reality, Processes Interact with Other Processes
accept order
close order
order paid in full notification customer 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 full on time, right amount? payment due date
Yes customer payment customer invoice notice of receipt goods receive
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
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 2 : role 1 :
role 1 : Person
role 1 :
Person role 2 : Person
role 2 : Person role 2 : System service : System role 1 : System role 2 : System role 1 : System
Reference Data Touches Many Business Processes
Changing a ProductID format can impact many
processes
Remember the 5-digit zip code?
Purchase Materials Production Plan Manage Accounts
Product 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 Products
Product Concept
+productID() +productID()
Execute Marketing Campaigns Conceptualize New Product
For Success, A Total Architecture Perspective is Required
Business Processes
Sales order management
I t t Inventory management Accounting People Participants in the business processes Information Wh t i f ti i b i
What information is being
used Systems Computers networks Computers, networks, applications, infrastructure Business Purposep
TIBCO BPM/SOA Execution Model
Execution Strategy Solutions & Operations
Step 1 Step 2 Step 3 Step 4 Step 5 Step 6
Operate the Business Develop Vision & Program Roadmap Define & Implement Organization & Governance Define & Implement Technical Infrastructure & Analyze Process & Develop Project Design, Build & Deploy Business Process
Step 1 Step 2 Step 3 Step 4 Step 5 Step 6
Repeat for each project Roadmap Governance Standards j Roadmap Process Continuous Improvement Continuous Improvement Governance
Project Life Cycle Management and Control
Measure Business IT and Organizational KPIs & SLAs / Analyze ROI Measure Business, IT and Organizational KPIs & SLAs / Analyze ROI
Vision
Focus on business processes first
They are the source of business value
They 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 Application Sil Application Silo BPM/SOA Sil Application Sil Front-Office Applications External A li ti Data Center
Silo Silo Silo Silo
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
Vision
Separate service access mediation from services
Service access control based on
Security
Quality-of-service agreements
Routing of service requests
L d di t ib ti lti l i id
Load distribution across multiple service providers
Logging of service utilization
Vision
Acknowledge different types of processes
Unmanaged 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
availability availability
Managed/Orchestrated Processes
• One component coordinates the work of other components and services
• Manager can monitor process status
• Manager can monitor process status
Managed Processes Often Span Multiple Systems
Process manager may need to access data (or
non-service functionality) directly when it is not available 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
Augmented Packaged Application Workflow
Uses EAI and ETL to coordinate with activities in
independent applicationsp pp
No overall process manager
Part of process is “hard wired”p
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
functionality
T l t i t f f
Hard-Wired Processes May Involve Any Technology
Often hybrids of SOA, BPM, and older technologies
EAI and ETL remain important
EAI and ETL remain important
EAI provides the “events” for an event-driven process
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
Master data management has a similar distributed architecture
Events are What You Can Observe Providing meaning to Purch ase O rder g them requires associating Produc t Specific ation Purch ase R eque st associating them with Processes on Produc t Shipme nt No tifica tion Data History Produc t C atalog Shipm ent O rder Prod uct In vento ry Shipme nt Sales Orde r
Complex Event Processing (CEP) Provides the Tools Concept models provide the Shipment Order Shipping Notice Invoice -invoiceAmount Sales Order Customer Address 1 0 * 0..1 1 1 0..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 conclusions
Vision
Separate processes and presentation
Sometimes you want to make the same process available via
different channels different 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
Vision
Embrace total architecture
SOA and BPM provide many opportunities to organize and
h i
manage the enterprise
The challenges are organizational as well as
technical technical
What Is a Service?
A service is a reusable unit of functionality with
Benefits of Services
Reuse
Saves money - avoid the cost of replicating functionality
Faster time to market for projects - reduced need for development
Isolation of service consumer
Service provider design can evolve without impact
Service provider can be replaced without impact
Flexibility
Platform 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
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
Service Granularity
The amount of work encapsulated by each service
operation
C i d l t l ti l l t f
Coarse grained – encapsulates a relatively large amount of
functionality
• Generate Bank Statements for all current accounts
Fine grained encapsulates a relatively small amount of
Fine 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
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 load
Underlying services may not be able to handle the load
Performance may be better if the underlying service
Service Identification
Approaches
There are three
starting points for
identifying
services:
1. Top-down from Business
processes
2. Middle-out: from
functional perspective
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 operations
Account Balance Management Service
+obtain disbursal authorization() +report funds disbursal()
Service Operations +report funds disbursal() +deposit funds() +get balance()
Example 1: Withdraw Cash Using Services
swipe card and enter PIN display transaction choices
ATM System ATM Server ATM Machine Bank System Customer cardID - bank association 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 Authorization Request
identify customer,identify account, authorize disbursal forward request
forward response : Disbursal Authorization Reply
Request
: Disbursal Authorization Reply
remove cash
call 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
remove receipt
print receipt and return atm card receipt
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 requirementsq
Non-functional requirements
Is the service appropriate for use in the different business
processes? processes?
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?
Granularity
Volume
Response time
Response time
Has the proposed service been reviewed by the
stakeholders that will use the service? stakeholders that will use the service?
Hierarchical (Federated) Service Busses <<component>> Enterprise Service Bus Domain A Domain B W Enterprise Service Provider Interface A1 Enterprise Service Provider Interface Z Enterprise Service Provider Interface X Enterprise Service Provider Interface Y Enterprise Service Provider Interface Enterprise Service Interfaces <<component>> Domain A Service Bus <<component>> Domain B Service Bus Domain A Service Interfaces <<component>> Service X Domain Service Provider Ineterface A1 Domain Service Provider Interface Y Domain Service Provider Interface Z Domain Service Provider Interface W Domain Service Provider Interface Domain B Service Interfaces Service Adapter A1 Z Native Interface Native Interface Y Native Interface W Native Interface <<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 Enterprise Service Provider Interface Z Enterprise Service Provider Interface X Enterprise Service Provider Interface Y Enterprise Service Provider Interface Enterprise Service Interfaces <<component>> Domain A Service Bus <<component>> Domain B Service Bus Domain A Service Interfaces <<component>> Service X Domain Service Provider Ineterface A1 Domain Service Provider Interface Y Domain Service Provider Interface Z Domain Service Provider Interface W Domain Service Provider Interface Domain B Service Interfaces Service Adapter A1 Z Native Interface Native Interface Y Native Interface W Native Interface <<component>> Application Z <<component>> Application W <<component>> Application X <<component>> Application Y
Service Mediation
Managing the interactions between service provider
and consumer
Typical mediation activities
Data transport and transformation
Data transport and transformation
Service distribution and routing
Service access control
These activities are typically responsibilities of an
enterprise service bus (ESB) enterprise service bus (ESB)
Abstracted Location and Access Control
Abstracting out physical location of the service
provider and the access control of the service
Service Consumer Service Consumer Service Consumer provider SOAP over HTTP -physicalDestination SOAP over JMS -logical destination
Enterprise Service Bus
+accessControl() Proxy +accessControl() SOAP over HTTP -logical destination SOAP over HTTP Service Provider Service Provider Service Provider -physical destination SOAP over JMS SOAP over HTTP -physicalDestination +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 account 1.1:
Request for Account Information 1:
north american accounts : Customer Account Service european accounts : Customer Account Service
Submission of request to service provider 1.1.1:
ActiveMatrix Service Grid – Logical Next Step
Out-of-Grid Service Consumer
*
In-Grid Service Consumer Interface In-Grid Service Consumer
* *
Concrete WSDL Interface 1
Active Matrix Service Grid Node
+accessControl()
+geographic and logical routing() Routing
* Abstract WSDL Interface 1 Abstract WSDL Interface 1 Service producers and consumers using location- g g p g g() +consumer-providerMapping()
+mapping to concrete WSDL for external interactions()
Routing * Abstract WSDL Interface 1 * Abstract WSDL Interface 1 * using location independent service definitions
In-Grid Provider Interface In-Grid Service Provider
Concrete WSDL Interface 1
*
Communications in ActiveMatrix Node 1 Node 2 Service Consumer in Service Consumer in Service Provider in Service Provider in Consumer in Container Consumer in Container Provider in Container Provider in Container
Policy Policy Policy Policy
Message Normalization and Routing Message Normalization and Routing
Agent Agent Agent Agent
Policy Type Summary*
EJB BPEL .NET Axis
Authentication Authorization Policy Agents S i B Authorization Encryption Signature Policy Store Service Bus Signature Logging Tracking Security SLA Version P1 P2 P3 P4 Tracking Auditing Routing Routing Schema Validation
Policy Independence
Policies and services are managed independently
Business Analyst Developer Deploy Deploy Admin Deploy Deploy Manage Service Lifecycle Enforce Policy Lifecycle Ops
Runtime Policy Architecture
Business Works Engine Service Consumer service request Policy Agent
service reply
service request service reply
Stand-alone Business Works and Policy Agent
Active Matrix Service Grid Node
service request service request
Business Works Engine Service Consumer Policy Agent
service reply q
service reply
Service consumer may be anywhere
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 ode credentials
Many systems are not designed to pass credentials
from input to output
Often use “trusted system credentials” to access back-end
systems systems Typically different security credentials <<component>> Front-End System <<component>> Back-End System <<component>> Service B k E d S i
U System Back-End System
Interface Service
Interface User
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 credentials
Services and adapters remain unaware of credential mapping
Services 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-End System <<component>> Front-End System Back-End Interface User Interface Service Interface Adapter Interface Policy-enabled Interfaces
The MDM Problem
Where’s the customer?
<<component>> <<component>> <<component>> <<component>> <<component>> Investment Banking System -accountInfo tH ld I f <<component>> Credit Card System -accountInfo -accountHolderInfo <<component>> Mortgage System -accountInfo -accountHolderInfo <<component>> Retail Banking System -accountInfo -accountHolderInfo -accountHolderInfo
The Data Warehouse Approach
Data
inconsistencies are <<component>>Credit Card
<<component>> Mortgage <<component>> Investment <<component>> Retail Banking never resolved
Merge 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 data E.g. relationships between customers <<component>> Data Warehouse -customer Only as current as
the last ETL extract
customer -account
The MDM Approach MDM includes data maintenance U d t t i t i <<component>> Operational Data Store -customer Updates to maintain consistency Workflow 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 data E.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 MDM maintains ODS contents -accountHolder account -accountHolder
Transactional Data Requires a Separate Path
Data typically does
not require MDM <<component>> Operational Data Store -customer account q 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 y of transactional data Implemented with
traditional event driven
component Mortgage System -account -accountHolder component Credit Card System -account -accountHolder component Investment Banking System -account -accountHolder component Retail Banking System -account -accountHolder <<flow>> <<flow>> traditional event-driven approach <<flow>> Transactional Data <<flow>> Transactional Data <<flow>> Transactional Data <<flow>> Transactional Data
T
l A
hi
Total Architecture
Synthesis
Efficiently Developing
Solution Architectures
Solution 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 Knowlege Gained from Using y Scope
Implement Components and Services
System Specify Components and Services
Component and Service Specifications
Assemble and Test System
Unit-tested Components and Services
Working System Deploy and Use System
O
i
ti
l
Organizational
Issues
Business Processes and Services Cross Organizational Boundaries
Services and Integrations Span Silos Lack of Overall Responsibility
Service Interface Shrinking Time Frames Data Center Application Silo Application Silo Services, Integration, and Process Management Silo Application Silo Front-Office Applications External Applications
Many Development Processes Have Become Degenerate
They assume a single system is being worked on
Development QA Production Requirements
Degenerate Processes Will Not Work for SOA and BPM
Multiple organizations and systems are involved
Development QA Production Requirements
A Richer Development Processes Is Required
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 Application Silo Application Silo , Integration, and Process Management Silo Application Silo Front-Office Applications External Applications Communications Infrastructure
Multi-Silo Projects Include Members from All Silos
3 key leadership roles needed on roles needed on every project
Enterprise Projects Group Should Manage These Projects
The group provides a reporting structure for projects that span organizational silos
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
Service Interface
Future
Project Call New
Service
Service Interface
Future
Project Call New
Service Service
The Enterprise Architecture Group Coordinates Projects
Establishes the vision
Ensures projects collectively
converge on a single Enterprise
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 levels
Business Application Infrastructure Architecture Infrastructure Responsible for: Architecture Application Architecture Services Architecture Standards Best practices G Architecture Governance
Total Architecture Management Total Architecture Management E t i Enterprise Enterprise Projects Enterprise Architecture 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 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 Application Silo Application Silo Services, Integration, and Process Management Silo Application Silo Front-Office Applications External Applications
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
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 projects
cross 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 essentialGovernance 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 g g over project-specific benefits j
Intrinsic interoperability over custom integration
Shared services over specific-purpose implementations
Flexibility over optimization
Evolutionary refinement over pursuit of initial perfection
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 boundaries meaningful 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 cohesivey , g
SOA Manifesto Authors Authors Ali Arsanjani Grady Booch Thomas Erl Nicolai Josuttis Joe McKendrick Steve Ross-Talbot Grady Booch Toufic Boubez Paul C. Brown David Chappell Nicolai Josuttis Dirk Krafzig Mark Little Brian Loesgen
Steve Ross Talbot Stefan Tilkov Clemens Utschig-Utschig Herbjörn Wilhelmsen David Chappell John deVadoss Brian Loesgen Anne Thomas Manes
For More Information on Total Architecture… Succeeding with SOA
• The business and organizational
perspective perspective
• 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 the Business Develop Vision & Program Define & Implement Organization & Define & Implement Technical I f t t & Analyze Process & Develop P j t Design, Build & Deploy Business
Step 1 Step 2 Step 3 Step 4 Step 5 Step 6
Program Roadmap
Organization &
Governance Infrastructure & Standards
Project Roadmap
Business Process
