1. Policy Federation and SOA Governance

2. Introducing: Miko Matsumura
VP of Technology Standards, Infravio
VP of Marketing, Infravio
Chair of OASIS SOA Adoption Blueprints
VP of SOA Product, webMethods
Chief Java Evangelist, Sun Microsystems
Software R&D at Hotwired
Limited Partner, Focus Ventures
Advisor, TogetherSoft, Asia Java Fund, Kendara, Dejima
M.S. in Neuroscience from Yale University (Neural Networks research)
MBA, San Francisco State University

3. Who is Infravio? Infravio is The SOA Governance Company.
Founded in 1999
Headquartered in Cupertino, CA
Approx 20 people in the US
Development in Chennai, India
Approx 50 people in India
X-Registry Platform 6
SOA Governance Registry Repository Platform
Top rated SOA Governance platform (Infoworld Labs Review)
One of the only vendors that looks at SOA lifecycle properly (MWDAdvisors)
“the state of the art in SOA today.” (Loosely Coupled)
“Infravio is ahead of the competition with X-Registry.” (Zapthink)
Market Momentum
Doubled customer base in Q4…
16 new customers
Competitive momentum
Pipeline expansion
Yali’s question
Definition of “Governance”
The SOA Governance Company
Expansion Stage
35 Customer including: Sprint, Providence Health System, MCI, Level3 Communications
Close to cash flow break even
$22M in funding to date
Investors: Walden International, NetIQ, Crystal Ventures
Market momentum
Average Selling Price: $150K + Services, $750k+ lifetime
Revenue momentum
Highly Leveraged Cost Structure
Company Size: 25 in North America, 50 in Chennai India
Development
Chennai India
Distribution
Open Source
Channels: NetIQ, IONA, SRA, IPT, and IBM
Commanding Market Position 3

4. Current Customers Telecommunications Government: Healthcare:
Sprint-Nextel
British Telecom
SwissCom
NTT
IONA
MCI
IPT
Level3
SRA
Government:
Texas HHS
Texas Legislative Council
State of Minnesota DPS
Government of Quebec
National Academies
Healthcare:
Providence Health System
Aventis
Integris
Finance/Insurance
Allianz Life
Defense
Lockheed Martin
JFCOM
Travel
Sabre
Manufacturing
Alcoa
WW Grainger
Telco
MCI
Sprint
SwissCom
NTT
Telco Related
Level3
IONA
SRA
IPT
Healthcare
Providence Health System
Integris
Government
Lockheed Martin
State of Minnesota DPS
Government of Quebec
National Academies
Alcoa
Data Central
TX1 4

5. SOA Governance

6. Interdependent Applications Interdependence can destroy agility
Interdependent Companies
Reuse Creates Interdependence
Interdependent Departments
Key Issue: How can mainstream companies apply new middleware standards, tools and design concepts?
How can you change anything when everything is tied together!?
Virtual Enterprise
Suppliers
Outsourcer
Distributors
Big
Customers
Data Center HR
ERP
Mfg. Plant
Sales
Branch
Enterprise
Subsidiary
Purchasing
Shipping
Dept.
Contact
Center
Consumers
Customers
Suppliers

7. When everything is tied together…
Changing IT Systems is slow and error prone!
Policies are not being enforced!
Change Processes are a mess!
Can’t See what’s happening in my SOA?
Can’t Trust Services I don’t control!
Can’t Manage SOA Policy Enforcement!
Can’t Find Services to reuse??
Can’t Understand how to use these!
Services don’t work together!

8. Federated SOA Governance

9. What is Service Oriented Architecture?
“Service Oriented Architecture is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.”
OASIS SOA Reference Model Technical Committee 9

10. Why SOA Adoption Might be Good
Central IT Benefits
Consolidation
Reuse
Compliance
Business Unit Benefits
Agility and Flexibility
Business Visibility
Process Integration
Shared Benefits
Business/IT alignment

11. SOA Benefits Statements
Strategic Benefits
KPI Improvements and/or ROI ROM Estimates

12. More Groups Adopting Might be More Good
Lifecycle Stakeholders
Architects
Developers
Quality Assurance
Provisioning and Deployment
Administrators
IT Operations staff
Service Consumers
Business Users
Centralized vs. Distributed Stakeholders
Central IT
Business Units
External Stakeholders
Regulators
Customers
Suppliers
Partners

13. SOA Adoption Challenges
Hoarding
Lack of Trust
Externally Imposed Rules
Loss of Control
Assigning Blame
Compromises
Distribution of Burden
Distribution of Incentives

14. SOA Governance What is Governance?
Governance is the art and discipline of producing managed outcomes through structured relationships, procedures, and policies.
What is unique about SOA Governance?
SOA governance is half human, half machine
The relationships, procedures and policies of SOA are defined by organizational processes
These policies also in part described, enforced and automated by technology systems.
Why is SOA Governance Important?
SOA systems are highly interdependent
Multiple ownership domains, multiple policy domains
Each incident of “Reuse” creates additional dependencies

15. Rearchitecting Silos at HMRC
IT Capabilities
‘Horizontal’ business capabilities
NO MORE SILOS
Unified customer identity management, case management and tax / benefit rules administration
As-Is
NO MORE SILOS
To-Be
Automation per regime
Automation of Shared functions
Common charge management, debt management based upon a single customer account SA
PAYE CB
VAT SA
PAYE CB
VAT
contact
contact
case
case TO
liability
liability
Business process automation that allows work to be processed regardless of location
compliance
compliance
charge
charge
debt
As-Is
Government and HMRC is littered with projects and programmes delivered in Silos each
built in relative isolation with no overarching architecture blueprint as to how they
should all work together.
To-Be
replace/unpick the silos and create common services/capabilities
debt
Infrastructure and applications that can support new ways working
Ready for cross-government shared services
These will enable common shared business functions

16. Physical Architecture View (EA) for 2011 - DRAFT
Risk, Compliance, MIS, BPM
Channel Components
Integration
Telephony
Paper
Internal Portal
External Portal
B2B
Integration
ESB
Risk Assessment
Identity Components
Identity
Management
Registration
Identification
Authentication
Authorisation
Government Gateway
SAP Siebel Pega
CIS-x
Tivoli/CA/etc
Government Gateway
SAP Siebel Pega
CIS-x
Tivoli/CA/etc
Government Gateway
SAP Siebel Pega
Government Gateway
SAP Siebel Pega
External
Gateways
CIS-X
SAP MDM
MIS
Customer Relationship Management Components
Campaign
Management
Advisor
Workflow
Navigation,
Data Entry&Supply
Customer Contact
Management
Call Centre
Application
SAP Internal
Integration
Front Office
BPM
Netweaver XI
Customer Interaction & Orchestration Components
Extract Transform
Load
Shared
Workspace
Operational
Reporting
Enterprise Content
Management
Interactive Guidance
Application
Overall Transact.
Orchestration
Rules & Validation
Processing
Informatica, Oracle
Streams
Internal File
Transfer
Generic Application Components
Transfer Manager
Change of
Circumstances
Comply
In/Out
Data
Provisioning
Contact
In/Out
Collaboration
Regime Components
PayAsYouEarn / National Insurance
Self Assessment
Corporation Tax
Frontiers
VAT
Excise
Others
National Tax Credits
PAYE Core
NI Core
SA Core
CT Core
VAT
mainframe
Process Return
Stamp Duty
Application
Processing
We have started to make choices in some areas, and others will largely remain as-is (e.g. Stamp Duty on SAP) due to no focus to change from the 5YP
NIRS Bespoke
Application
NIRS Bespoke
Application
Not
addressed
yet
CT Work-
management
Calculate
Duty
PAYE/NI specific
MIS
PAYE/NI
Work Management
Work Management
Entitlements &
Awards Calculation
Middle Office
Business Objects
PEGA Rules
Calculate Penalty/Interest
PAYE/NI – SA Shared
Needs
deciding
Personal Tax Core
Maintain Tax/Allow&
Deductions
Tax calculation
Duty Deferment
NIRS Bespoke
Application
NIRS Bespoke
Application
NIRS Bespoke
Application
BackOffice Components
Integrated Trust
Accounting
Debt Management &
Banking
Single Financial
Account
Receipts and
Payments
Finance
Procurements HR
Estates & Others
decided
Back Office

17. Managed Outcomes Step One: Establish top level goals and outcomes
Measurable goals
Metrics Reporting and Auditing
Step Two: Establish policies and contracts
Accountability, adjudication, responsibilities
Interoperability Standards
Service Lifecycle Processes
Security Policies
Step Three: Build the Foundation
Assign ownerships, budgets and responsibilities
Develop Organizational Tools (CoE, chargebacks, shared services org)
Establish federated systems of record for policies, contracts and services
Automate governance processes

18. SOA Governance Foundation

19. INFRAVIO X-Registry Platform

20. What is it? Registry and Repository Cross-Lifecycle Governance
“System of Record”
Federated
UDDI and ebXML
Cross-Lifecycle Governance
Auditing
Multi-Tenancy
Access Controlled
Managed Lifecycle Processes
Federated Lifecycle Promotion
Portal-based UI for external/internal access
Design Time Governance
Automated Artifact Validation
Robust classification, attributes, service profiles
Run Time Governance
Interoperability with disparate run time intermediaries
BAM and Monitoring
Change Time Governance
Impact Analysis
Change Notification

21. X-Registry Platform

22. Metadata Lifecycle Ecosystem
Design Time
Run Time
Change Time
Lifecycle Stage
Organization
ESB/
WSM/
Broker
Portal
Business
Process/
Contracts
Source
Asset
Repository
Enterprise
System
Console
UDDI
Registry
Ecosystem
Component
Access Control Policies
Lifecycle Governance Rules and Processes
Security Policies
SOA Information Model and Metadata Repository
Metadata
Governance
Mechanisms

23. Multiple Groups, Same SOA Data
Access Control Policies
Lifecycle Governance Rules and Processes
Security Policies
SOA Information Model and Metadata Repository

24. Federated Multi-Organization View24

25. Governance Lifecycle

26. Design Time Governance Service Developer Role
Service Discovery Features
Service Description Profiles
Browse by taxonomy
Advanced attribute-based search
Supports Vertical Taxonomies (e.g. eTOM, etc.)
Service Publishing Process
Wizard-based publishing process
Content Validation (e.g. UDDI, WS-I conformance)
IDE integrated UDDI publish option
Workflow-driven approval/notification
Platform Extensibility
Governance API
JAXR Java API for XML Registries
UDDI version 3
ebXML version 2
JSR Compliant Governance Rules Engine
Custom content validation callout

27. Run Time Governance IT Operations Role
Service Provisioning and Access
Service Level Agreements
Approvals and Rejections
Limited access to services w/o approval
Service request lists
Consumer data collection
Runtime Contract/Policy Enforcement
SLA Management
Service Delivery Contracts™
Consumer Authentication
Run Time Version Management
Security Management (WS-Sec, etc)
Request/Response Routing Management
Failover/LoadBalancing Routing Management
Logging and Monitoring Management

28. Change Time Governance Business User Role
Business Activity Monitoring
Report Generation Capabilities
Performance metrics integrated with repository
Runtime metrics warehousing
SLA Performance measurement
Performance/SLA Alerts
Service Change Governance
Service Change Subscription (expression of interest)
Service Binding Subscription
Service Metadata Subscription
Change Notification
SOAP Notification
Synchronous/Asynchronous Notification
Service relationship and dependency management
Impact Analysis
Change Time version management (deprecation, migration, expiry, etc.)

29. X-Registry Policy Enforcement
Authoring
Policy
Enforcement
X-Registry
X-Broker or External

30. Infravio Service Delivery Contract™
American
Airlines
Bank of
America
Contract Terms:
Security Terms (e.g. Authentication, Authorization, Encryption )
Operational Terms (e.g. Logging, Monitoring, SLA, Alerting, Reporting, Routing)
Routing Terms (e.g. Load Balancing, Fail-over, content based routing)
Lifecycle Terms (e.g. Versioning, Deprecation Rules)
Business Terms (e.g. Billing and Metering, Business Activity Monitoring)
Data terms (e.g Transformations, Caching)
Reliable Delivery Terms (e.g. Messaging, Transport Protocol, Transactions Integrity)
Custom Terms (i.e. user defined terms)
Comcast
Contract A
Contract B
Contract C
Delivery
Security
Transformation
Transaction
Versioning
Transport
Routing
Delivery …
Delivery …
Web Service (e.g. Order entry, get stock quote, update customer record,…)
Terms of Delivery:
Delivery preferences (Security model, transport, data transformation, messaging,…)
Service Level Agreement (Expected peak load, response time, availability,…)
Notification arrangements (who to notify in case of problems, notice period for planned outages,…)
Consuming Application
Consuming Application Class Profile (e.g. Plumtree portal, SAP client,…)
Consuming Application (e.g. Employee portal, B2B partner ACME, Company Public Website,…)
Operations
SLA
Alerts
Notifications
Operations …
Operations …
Provider System Services

31. Federation
Example: Promotion of a service from a staging instance to production
Technical
Synchronization
Governance Automation
Access Control
Delegated Authority Models
Business
Distributed Policy Authoring
Policy Reconciliation

32. Award Winning INFRAVIO X-Registry Platform 5

33. SOA Maturity and Governance

34. SOA Scope vs Governance
&
Benefits
Where are you now?
Business Objectives
Architecture & Technologies
Governance & with IT Process
What do you want to be?
Vision
How will you get there?
Pragmatic Plan for Evolution
Governance
&
Maturity

35. Adopting Service-Oriented Architecture: Business and IT Drivers
Strategic Planning Assumption: Through 2008, fewer than 30 percent of strategic SOA initiatives will be justified solely in terms of IT benefits (0.9 probability).
M&A/divestitures
Multichannel sales/support
Time to market
Continuous innovation
Process flexibility
Process visibility
"Top Down" Enterprise Drivers
"Perennial" IT Challenges
"Doing more with less"
Business/IT alignment
Data consistency/quality
Time to deployment
SOA
Moving to an SOA is, in most cases, motivated by significant changes in the business environment. This need most frequently manifests itself in the context of a specific business unit, but often — and most importantly — also at the corporate level. The modular, "composable" and technology-neutral nature of service-oriented applications fits well with a large spectrum of "bottom up" business-unit-wide and "top down" enterprisewide requirements. SOA is first and foremost a key enabler to improve companies' ability to adapt more rapidly to the quickly changing business environment.
SOA adoption is also greatly beneficial from the CIO's point of view. To keep pace with relentless business change, IT departments are constantly under pressure to deliver more in a flat-budget situation. Users scream for data of better quality and greater consistency, and business units want new applications to be delivered yesterday. SOA can frequently be part of the answer, by providing a sound architectural framework to help CIOs address their challenges. However, SOA is not a product that they can buy and install. In addition to the adoption of new technologies, it requires change in people's behavior. This has a cost that can't be justified solely on the basis of technical, IT-centric considerations. Without the spur of a specific business requirement, it will prove hard for most CIOs to "sell" SOA (and justify the relevant costs) based purely on IT considerations.
Action Item: Organizations wishing to strategically adopt SOA should develop their business case on a combination of anticipated business and IT benefits.
Call center integration
Single face to clients, suppliers, employees
Process integration
Real-time B2B
"Bottom Up" Business Unit Drivers

36. SOA Adoption: Benefits and Implications
Strategic Planning Assumption: Through 2008, the upfront investment for large-scale service-oriented applications will be justifiable only for projects with a planned lifetime of three years or more (0.8 probability).
Benefits
Implication
Architectural Partitioning
Diverse life-cycle "speeds"
Synergy of different technologies
Optimal tech skills allocation
Processes visibility
Greater maintainability
Easier outsourcing/"offshoring"
Higher Upfront Costs
Cultural change
Infrastructure (SOA backplane)
More formal methodology
Longer design time for services
Testing (unit/end-to-end)
More Distributed Infrastructure
Extensive use of middleware
Transaction management
Debugging/troubleshooting
End-to-end management
More granular security
Metering/logging
Incremental Deployment
Gradual migration
Cost "spreading" across projects
Reduced maintenance cost
SOA's principles are logical/physical partitioning of business logic from user-facing application logic, separation of business logic into independent modules (that is, services) and encapsulation of the functionality of each service in a well-defined, loosely coupled interface. In SOA, services are activated by service consumer programs that invoke specific services by calling them over the network through their interfaces. The platforms service consumers and implementations run on can be completely different, as long as there's a proper middleware-based infrastructure (the SOA backplane) in place to provide secure, reliable and manageable interoperability. The benefits of a well-implemented SOA are greater adaptability, faster time to deployment and lower costs for application development and integration. But SOA doesn’t come for free. Compared with traditional architectures, SOA needs a more careful application design. It requires use of integration middleware. Testing, debugging, managing and securing a distributed SOA are more complex and expensive. Services ownership and accountability issues, as well as cost allocation are much harder to deal with. Therefore, effective processes and governance rules must be enforced. Addressing these issues is paramount for successful SOA initiatives, but despite the falling cost of technology, more widespread know-how and skills availability from systems integrators, the incremental upfront cost of SOA vs. a traditional architecture in most cases can't be justified for fast-ROI, opportunistically oriented projects.
Action Item: Users should consider SOA only to support the most strategic, systematically oriented projects.
Sharing (Reuse) of Services:
Faster time to deployment
Lower development cost
Greater adaptability
Tighter Management/Governance
Ownership/accountability
Cost allocation
Prioritization/conflict resolution

37. Stages of SOA Adoption Enabling Technology Stage 1 Introduction
Strategic Planning Assumption: Through 2010, fewer than 25 percent of large companies will have developed the technical and organizational skills needed to deliver enterprise-wide SOA (0.8 probability)
Stage 1 Introduction
Stage 2 Spreading
Stage 3 Exploitation
Stage 4 Plateau
Address
Specific Pain
(e.g., Customer Portal)
Process Integration
(e.g., B2B)
Process Flexibility
(e.g., Time to Market)
Continuous Adaptation & Evolution
Business Goals
Establish
Technology
Platform
Leverage Services Sharing
Proof of
Concept
Enterprise SOA Infrastructure
IT Goals
Multiple
Applications
(Single BU)
Multiple
Applications
(Cross BUs)
Single Application
Virtual Enterprise
Scope
# of Published Services*
# of Service Consumers*
Total Service Calls/Day*
# of Service Developers*
<25 <100 <500 >500
<5 <25 <50 >50
<10,000 <100,000 <1,000,000 >1,000,000
<10 <20 <100 >100
SOA adoption evolves through stages that pose escalating organizational and technical challenges. In many cases, it begins with an individual project, usually within the scope of a single application domain, addressing a specific business goal such as call center integration or customer self-service portal. The main IT goal is to prove the SOA concept and establish a prototype infrastructure. These projects usually proceed informally without the support of a hard-core methodology and governance processes. Often, these SOA initiatives grow to a wider scope (multidomain or business-unit-wide) and support more ambitious business requirements, such as integration of strategic business processes and business agility improvement. From an IT perspective, the goals are establishing a strategic technology platform for the SOA backplane and experiencing the benefits of service reuse.These settings are where most mainstream companies should expect to settle in their first two or three years of SOA, but getting there requires more discipline, governance and control than for the initial projects. The final stage is enterprisewide SOA adoption to enable continuous evolution and adaptation of business processes. Infrastructure and processes must be dramatically formalized and scaled up. Only a few companies have the technical and organizational maturity required for enterprisewide SOA, but many will move in this direction during the next five years. Designing a scalable SOA-enabling infrastructure and proper governance processes from the outset is critical for success.
Action Item: Users entering SOA should initially avoid enterprise-wide initiatives and focus their efforts on smaller-scope (for example, inter-domain or business-unit-wide) projects.
Enabling Technology
(cumulative)
Application Server, Portal, Adapters
ESB, WSM Integr. Suite, B2B
SOA Reg/Rep
BPM
Policy Mgmt
Enterprise SOA Backplane
* =These figures represent typical scenarios, but they may vary considerably depending on the specific organization’s requirements.

38. SOA Adoption: Required Management Buy-In per Stage
Tactical Guideline: Although management buy-in is key for successful SOA adoption, it is critical to avoid setting too high expectations. Sell SOA to top management only when your can prove its merits with already achieved, concrete and measurable business benefits.
Stage 1 Introduction
Stage 2 Spreading
Stage 3 Exploitation
Stage 4 Plateau
Head of Development or Head of Integration P P P P
CTO/Head of Architecture O P P P
Head of IT Operations O P P
CIO/Business Units O P P
CEO O P
Small-scale, experimental SOA projects don't require huge investments or sophisticated skills. As long as individual project leaders or architects are willing to take the risk of adopting an unknown approach, introducing SOA is relatively easy. The success of these initial projects stimulates SOA adoption by adjacent application areas and larger developer communities. At this stage, the CTO and the architecture team must buy into it because more-sophisticated skills and technologies (for example, ESBs or integration suites) are needed. At the CIO level, however, SOA still remains a specific approach adopted by a circumscribed set of projects that doesn't require careful monitoring from his or her part: As long as projects are on time and on budget, it's fine.
Only when SOA proves effective in many business-critical initiatives does it becomes apparent to the CIO as a strategic option and provides enough benefits evidence as to justify the additional investments needed to expand the SOA scope at a business unit level or wider.
Strategic enterprise adoption is probably beyond the level of empowerment of most CIOs and requires the CEO's — or even board-level — support as sensitive organizational and political issues (for example, cross-business-unit cost allocation and governance) must be worked out. However, seeking top management commitment too early can be dangerous by exposing an immature approach to the direct scrutiny of impatient business leaders. Even modest failures in such conditions would undermine the credibility of SOA and its IT sponsors.
= Imperative
O = Recommended

39. SOA Adoption: Required Technology Skills per Stage
Tactical Guideline: As you move from stage to stage plan for acquiring the necessary technology skills however bearing in mind that skills for Stage 3 and Stage 4 are rare, expensive and hard to build.
Stage 1 Introduction
Stage 2 Spreading
Stage 3 Exploitation
Stage 4 Plateau
Basic Middleware P P P P
Web Services P P P P
Integration Middleware O P P P
Service Oriented Development of Applications (SODA) O P P
Business Process Management O P P
One of the main benefits of SOA in contrast with other architectural styles is it graduality, which is also reflected in the opportunity that organizations have to build their SOA-related skill set in an incremental fashion. In the Introduction stage only widely available and not particularly complex skills are required: a good understanding of development tools, application servers, portals, message oriented middleware and web services technology is sufficient, although integration middleware (adapters, programmatic integration servers, integration suites) is often required. But as organizations move through adoption stages, more sophisticated, harder to find and more expensive skills – such as business process management or composition skills - are needed.
In defining their SOA adoption plan, organizations should carefully assess what the available skill set is (both withing the internal IT organization and from service providers or vendors) and subesquently perform a gap analysis to determine what kind of skills they have to build internally and/or collect from external service providers to be able to planned stage of adoption. Or viceversa by matching the assesed skills portfolio with the Gartner adoption model they can figure out how far they can go in their SOA initiatives without making any investments in new skills.
SOA Operations Management O P P
= Imperative
O = Recommended

40. SOA Adoption: Required Capabilities per Stage
Tactical Guideline: As you move from stage to stage plan for building the required capabilities by taking into consideration that tools required in Stage 3 and Stage 4 are immature and often provided by vendors of questionable viability.
Stage 1 Introduction
Stage 2 Spreading
Stage 3 Exploitation
Stage 4 Plateau
SOA Center of Execellence O P P P
Services Life Cycle Mangement O P P
Service Design Methodology O P P
Planning Control and Quality Management O P P
Service Reuse Methodology O P P
Operation Management O P P
Domains O P
Not only is SOA adoption gradual in terms of skills portfolio but also in terms of organizational, process and governance capabilities. A dedicated team of SOA specialists is mandatory only starting from Stage 2 onward, although it is highly recommendable even in Stage 1. A registry/repository-based services life cycle management process, a formal services design methodology, quality management and a formal approach to encourage service reuse are imperative only when the number of actual services is greater than 100 or so and the number of consumer applications is greater than 20-25, which typically happens on Stage 3. But these capabilities are desirable to support the most ambitious Stage 2 endeavors as well. When organizations move to Stage 3 and 4 they typically discover that in different business units or subsidiaries other SOA initiatives where also going on in parallel. Then a significant governance issue is arisen in terms of reconcilying different technology platforms for the individual SOA backplane, methodologies and different governance processes. The notion of “SOA Domains” (i.e., clusters of application domains sharing a common SOA Backplane, common SOA methodologies and under the span of control of homogeneous governance processes) must be supported. Some sort of Enterprise-wide SOA backplane (at times also called Super-Backplane or Uber Backplane) must be put in place to enable interoperability between the SOA Domains. Finally an homogeneous, consistent and enterprise-wide set of these SOA governance processeses must be put in place to enable enterprise-wide enjoyment of SOA benefits.
Cost Allocation Schema O P
Consistent Enterprise-wide Governance Processes O P
Enterprise-wide SOA Backplane O P
= Imperative
O = Recommended

41. Trusted Operations Fabric

42. INFRAVIO X-Registry Platform
Burton Group SOA Reference Architecture
INFRAVIO X-Registry
Policy
Repositories
Metadata
Service
registry
Service mediation systems
X-Broker and SOA Link Partners
Acceleration
Routing
Transform
Security
Other
Service
platform
Middleware
Web Services Framework Standards
Service
platform
SOA Link
Service
management

43. Intermediary Can Load Balance…
Consumer A
Consumer B
Consumer C
Consumer D
Consumer E
Intermediary
Consumers and Services are now “loosely coupled”
Service A
Service B
Service C

44. Customize Service Delivery…! ? +
Consumer A
Consumer B
Consumer C
Consumer D $
Consumer E *
Based on Capabilities, Limitations and Preferences of Consumers
Intermediary
Service A
Service B
Service C
Contract

45. Feed Operational Consoles…
Consumer A
Consumer B
Consumer C
Consumer D
Consumer E
Intermediary
Service A
Service B
Service C

46. Assure Service Level Agreements…
Consumer A
Consumer B
Consumer C
Consumer D
Consumer E
Intermediary
Higher priority Consumers get preferred access
Service A
Service B
Service C

47. Enforce Security Terms…
Consumer A
Consumer B
Consumer C
Consumer D
Consumer E
Intermediary
Intermediary can enforce security and compliance
Service A
Service B
Service C

48. Policies Enforced by Intermediary
American
Airlines
Bank of
America
Comcast
Contract A
Delivery
Security
Transformation
Transaction
Versioning
Transport
Routing
Operations
SLA
Alerts
Notifications
Authenticate
Engage Contract
Access Service
Intermediary
Sprint Trouble Ticket Service

49. Who Controls Metadata Controls SOA.
The Registry Repository allows the fastest changing elements of IT infrastructure to be externalized as metadata
Contract A
Contract
Delivery
Security
Transformation
Transaction
Versioning
Transport
Routing
Operations
SLA
Alerts
Notifications
Contracts
(Operational
Configurations)
Process
Flows
Security &
Access Control
Governance
Rules

50. Case Study: Sprint Nextel

51. Sprint’s Problems Managing Services
No organized Web Services offering point for internal / external consumers
No Library / Catalog of deployed web services
Not easily discoverable
No Description Information available
No Governance or Compliancy measures
No “Utilization” or “Activity” measurements
No Deployment Control
No End-to-End view of integrated services
How do we respond to employee / customer demands for self-service access?
“On-ramping” new consumers takes WAY too long; they need information NOW
No way to Version services
How can we have the business be connected to our end consumer and services?
Thought they had web services but they actually had over 80 in production
For each business customer, they would build an individual, custom portal for each customer which became very expensive

52. 52

53. Service Assurance (Repair)
Telecom Web Services
Summary List of Repair Tickets
Summary List of Bills
Summary List of Invoices
View Contract Information
List of Available Local Services
List of Local Services on an Account
Long Distance Telephone Info on a Line
List of Directory Listings for an Account
Unified Customer View Matching Service
Switched Toll Free Order / Maintenance
Install Customer & Maintenance
List of Associated Telephone Numbers on an Account
Validated Account Code
Toll Free Reservation Data
User and Account Security
Etc. etc. etc. …
Cellular Services
Long Distance
Ordering
Local Services
Report
Order
View
Billing
Pay
Account Maintenance
Update
Service Assurance (Repair)
Enter ticket
Dispatch

54. Transition from EDI to Portal to SOA
SOA project initiated by portal group 54

55. eBonding Customer Demand (24 Retail Customers polled in January 2005 regarding significance of web service integrations / ebonding) 55

56. eBonding Problem: 3000+ Hour Customer Integrations
I would like our new sales employees to automatically get a calling card. I need an SLA of 600msec and X.509 certification.
Sprint
Manager
Please hold on, I have to write a business plan to justify this integration project to submit to Finance.
Sprint
Finance
I need to build an ROI model so I can rationalize spending development resources on this integration.
Sprint
Customer
Sprint
Developer
Thanks for the requirements document. I need to write a specification for this implementation.
Sprint
Architecture
Please wait while we validate your specification according to the Sprint architecture
Sprint
Quality Assurance
Before you write a line of code, we will need to build a test plan to verify your code.
Sprint
IT Operations
Since we don’t know who’s using the service, we need to provision a separate bank of servers for each customer. 56

57. Service Delivery Contract™ Enforced by X-Broker
American
Airlines
Bank of
America
Comcast
Contract A
Delivery
Security
Transformation
Transaction
Versioning
Transport
Routing
Operations
SLA
Alerts
Notifications
One service, many customers, many contracts. Each set of consumption preferences gets a separate contract.
Contract B
Operations …
Delivery
Contract B
Operations …
Delivery
X-Broker
Sprint Trouble Ticket Service 57

58. Contract Manager Configuration of Consumption Policies and Patterns
American
Airlines
Bank of
America
Sprint
Manager
Comcast
Contract Terms:
Security Terms (e.g. Authentication, Authorization, Encryption )
Operational Terms (e.g. Logging, Monitoring, SLA, Alerting, Reporting, Routing)
Routing Terms (e.g. Load Balancing, Fail-over, content based routing)
Lifecycle Terms (e.g. Versioning, Deprecation Rules)
Business Terms (e.g. Billing and Metering, Costs, Business Activity Monitoring)
Data terms (e.g Transformations, Caching)
Reliable Delivery Terms (e.g. Messaging, Transport Protocol, Transactions Integrity)
Custom Terms (i.e. user defined terms)
Contract A
Contract B
Contract C
Delivery
Security A
Transform A
Transaction A
Version A
Transport A
Routing A
Delivery
Security B
Transform B
Transaction B
Version B
Transport B
Routing B
Delivery
Security C
Transform C
Transaction C
Version C
Transport C
Routing C
Web Service (e.g. Order entry, get stock quote, update customer record,…)
Terms of Delivery:
Delivery preferences (Security model, transport, data transformation, messaging,…)
Service Level Agreement (Expected peak load, response time, availability,…)
Notification arrangements (who to notify in case of problems, notice period for planned outages,…)
Consuming Application
Consuming Application Class Profile (e.g. Plumtree portal, SAP client,…)
Consuming Application (e.g. Employee portal, B2B partner ACME, Company Public Website,…)
Operations
SLA A
Alerts A
Notification A
Operations
SLA B
Alerts B
Notification B
Operations
SLA C
Alerts C
Notification C
Sprint Trouble Ticket Service 58

59. After Infravio: 160 Hour Integrations
95% Cost Reduction to Onramping
Up to 20x faster
Customized service delivery
Integration can take as little as 45 min
Sprint
Customer
Explanation
Sprint
Manager
Configuration 59

60. Over Portal Based Integration
Benefits
95% Reduction in Cost
Over Portal Based Integration
~20x improvement in speed
of Customer On-ramping
Payback within 6 months
After 2 successful customer integrations 60

61. Conclusion, Q&A