our business revolves around you

Sustaining the
Business Value of SOA
Jatinder S. Prem
Strategic IT Consultant
 Session Agenda our business revolves around you

 SOA Fundamentals
 Why SOA?
 What is you definition of SOA?
 The SOA Menu
 The SOA Paradigm Shift
 Aligning Current Development Processes
with SOA
 Factors for Sustaining SOA Value
1. Embracing the SOA Challenges
2. Understanding the Business
Requirements
3. Evolving an SOA Strategy
4. The Governance Framework
5. ….
 our business revolves around you

SOA
Fundamentals
Why SOA? 4

LiquidHub
Confidential

The Primary Business The Business Impact

Drivers for SOA Anticipated

30% IT Cost Savings 75%

23% Customer Service 65%

Improvements
21% Faster time to 56%
Market
6% Information 53%
Visibility
6% New Products / 48%
Services
5% Regulatory 36%
Compliance
5% New Channels 32%

4% Mergers & 25%

Acquisitions
1% Major Competitor 16%
Has SOA Initiative
Business Agility
Gained
Source: GCR – 2006 study of over 150 large organizations with, at least, a SOA pilot underway
What is your definition of SOA? 5

LiquidHub
Confidential

 SOA is a software design approach (or paradigm)

 A service-oriented architecture is one in which:
– Application functionality is made available through services
– Services are distributed, generally across an intranet, but sometimes across an extranet,
or even possibly across the public Internet
– Interfaces to these services are implementation-independent.  That is, even if a service is
implemented in Java, there is nothing Java-specific about its interface, and no
requirement that clients of the service use or understand Java
 Often there are two transparency requirements specified for SOAs as
well:
– Location-transparency - A client that needs a service does not want to be bound to using
that service at a specific site. 
– Transport-transparency - A client that needs a service does not want to be bound to using
that service with a specific transport protocol stack.  Different services may use different
transports (e.g. one may use HTTP, one may use SMTP, etc), which have different
characteristics. 
 SOA is a higher level of application development (coarse-grained
granularity)
– focusing on business processes and using standard interfaces helps mask the underlying
technical complexity of the IT environment
 Services provide access to data, business processes and IT
infrastructure, ideally in an asynchronous manner
 SOA typically leverages standards-based integration (XML and Web
The SOA Menu 6

LiquidHub
Confidential

SOA Project Menu

Welcome to the Café de SOA
Enterprise Appetizers:
 Governance (Policies, Standards and Procedures)
 Development Processes (SDLC etc…)
 IT & Business Strategies
 Strategic Reference Models & Design Patterns
 Program Management What can your
Service-Based Entrees: organization
 Service Domain Model consume?
 Process Alignment
 Service Taxonomy
 Consumer/Producer Contracts
Agile Dessert:
 Loosely Coupled/Modular
 Location Transparency & Discovery
 Integration Open Standards
 Federation
 Orchestration/ Choreography
The SOA Paradigm Shift 7

LiquidHub
Confidential

Distributed Architecture Service Oriented Architecture

Functionally Oriented Process Oriented

Designed to Last Designed to Change

Long Development Cycle Interactive & Iterative Development

Cost Centered Business Centered

Application Block Service Orchestrations

Tight Coupling Agile & Adapted

Homogenous Heterogeneous Technology

Technology
Object Oriented Message Oriented

Known Implementation Abstraction

 Aligning Current Development Processes towards 8

SOA LiquidHub
Confidential

Traditional Software Development Inputs Gap Analysis to Achieve SOA SOAD Foundation for SOA Development

Leveraged SOAD Elements

Enterprise SOAD = OOAD + BPM + EA
Architecture Frameworks OOAD = classes and objects Services-Oriented
(EA) BPM = Event-driven process models Analysis & Design
EA = Consistency between (SOAD)
Do not address how enterprise-wide individual
abstractions of quality facilitate reuse solutions.
and longevity.
No holistic, business-level view of the
+
Additional SOAD Elements
Levels of Abstraction

Transactions that
services landscape Operations represent single
Process and notation have logical units of
Business Process to be formally defined work (LUWs).
Modeling
(BPM) Business
Set of actions or
Service-Oriented Governance
activities
Processes
Does not reach into the architecture and performed with
implementation domain. Service Identification and Definition specific business
Does not differentiate: - , Direct and indirect business analysis goals in mind.
Between process model and more Domain decomposition
Services Represent logical
traditional programming models. Service granularity
Naming conventions groupings of
What logic is executed in
operations.
programming language extensions of
BPEL engines, as opposed to more Service Categorization and
traditional coding (J2EE). Aggregation
Job roles that perform the BPEL flow
engineering; is it a business expert
Policies and Aspects
(analyst) or a development role
(software architect)?
Object-Oriented
Analysis & Design
Meet-in-the-Middle processes
(OOAD)
The level of granularity of OO design
practices are focused at the class level.
Semantic Brokering
Strong associations such as inheritance,
create a rather tight coupling (and,
consequently, a dependency) between the Service Harvesting and
involved parties. In contrast, the SO paradigm Knowledge Brokering
attempts to promote flexibility and agility
The Industry Defined Benefits of SOA 9

LiquidHub
Confidential

Enables Information
Sharing
Heterogeneous Organizations and
Ability to utilize legacy and departments with in
new applications based on organizations deploy
the concept of interfaces various applications and
services. Visibility of these
applications and services
will aid in reducing
redundancy and enforce
reusability

Services reused, Agility Around Business

composed and Process
recomposed Organizations focus on
Reuse and loose coupling multiple business
of services/components processes. The ability for IT
lends itself to fasters organizations to rapidly
development / deploy applications based
implementation cycles on changing processes is
reduce time to delver. critical. Services centric
Leverage Business Assets model assists IT to
Organizations can increase understand dependencies
their bottom line and overall between various business
ROI by reusing components or processes.
services that have already been
built by themselves or even
across other entities.
 our business revolves around you

Factors for
Sustaining SOA
Value
1. Embracing the SOA Challenges 11

LiquidHub
Confidential

Justifying an SOA Skills

Transformation – New technology skills
Clearly define SOA within the – Versatility
context of the IT Organization – Experience
Identify and publicize corporate – Focus on architecture
benefits to be expected through SOA Change Management
Build a Tangible Business Case (use – New processes mean new roles and
projects) responsibilities
Defining the Ownership of – Career alignment
SOA  Process and roles
 Job descriptions
Often initiated by Enterprise  Measurement
Architecture Groups
Rarely tied to projects Culture mismatch
Tends to be infrastructure-focused – Management centric
Very few SMEs – Architecture centric
Low budget Breaking the silos
Getting Organizational Buy-in – Territories
Across IT – Cost cutting
Across the Enterprise (LOBs) – Knowledge gap
– P & Ls
Securing Top-Level
Sponsorship
CIO don’t buy SOA easily – They
1. Addressing the Drawbacks 12

LiquidHub
Confidential
1. Developing an SOA Methodology 13

LiquidHub
Confidential

 Service & Integration Portfolio

Analysis
•Align
service programs and projects with
business and IT principles and objectives.
 Service & Integration Planning
•Clarify
the relationship between service
build and service integration lifecycles.
 Service Build
•Delivering services to the Back Office.
 Service & Integration
Discovery, Documentation, and
Definition
•What service(s) are available to the Back
office and how they can be consumed
 Service Integrations
•The policies and best practices for how
integration(s) are delivered and how
integrations occur
 Service & Integration
Promotion & Marketing
•Thevalue SOA provides - How service(s)
and integration(s) are communicated and
presented internally and externally for the
Back Office
1. Deriving your Impact/Value Framework 14

LiquidHub
Confidential
1. IT Key Performance Indicators 15

LiquidHub
Confidential

• Reduce Development Costs

Mission
• Reduce Development Time
• Increase & promote Interoperability
between Systems
• Reduce System Maintenance
SOA Strategy

Standardize Standardize Manage Standardize Manage Measure

Data Access Processes Evolution of Integration Services Services
Current Systems (KPI)
1. The IT Challenge: Supporting Business 16

Needs LiquidHub
Confidential

Business Needs:
 Business is interested in processes and information — not applications or
infrastructure.
 Focus on using services, not acquiring assets.
 Governance will remain a top priority.
 Timely information access and measurement, process visibility
 Business process agility drives sustainable differentiation
 Clear delineation between Business Processes and Rules
 Key Performance Indicators (KPIs) – You need data to make IT and business
decisions
 Service Health Modeling (SLA)
– States
– Operational conditions
– Performance counters, events
– Monitoring rules
– Controls
 Need KPI at different levels:
– Business
– Application
– Infrastructure
 KPI at different levels are interrelated

IT Realities:
 Inability to meet demand for new application functionality, processes or information
access
 Lack of available skills and/or expertise
 Inconsistent or inadequate information and data quality
1. Identify the Savings 17

LiquidHub
Confidential

Cost Savings Revenue Savings

Development and Integration Time to Market (Agility)
– Productivity improvements – New product and/or service delivery
– Shortened test cycles – Incremental deployment of new services
– Increased reuse Extended Value Chain
– Quicker builds – New distribution channels and tighter
Maintenance and Support integration with business partners
– Simplified modifications – Customer/supplier connectivity
– Better managed code base (and fewer lines of – Increased market share
code) – Enabling mergers/divestiture
– Standards-based access Improved Service
Operations – Multichannel access and consistency
– Automation of manual processes and reduced – Improved cross-sell/up-sell capabilities
errors – Customer self-service
– Increased staff productivity – Process visibility and optimization
– Reduced transaction costs – Reduced problem resolution time
– Support for regulatory mandates and
compliance requirements
1. Put Reuse in Perspective – Its more than Code 18

LiquidHub
Confidential

Ensure you Train and Skill Your People

 Skill set portability, reduced training via standardized environment
 High Resource Efficiency
 Formalization of different roles in IT Process
 Governance principles and guidelines
 Development and delivery processes Technology
 Leverage of established IT assets (standard functionality,
infrastructure and tools)
 Architectural guidelines and principles
 Standard design patterns and frameworks
 Faster and better Reporting on results
1. Develop an SOA Roadmap 19

LiquidHub
Confidential

SOA Strategy
Buy-in from Business
Leverage Projects to Build Infrastructure
SOA Benefits Expected

Business Services
Portfolio Plan
SOA Roadmap Planning Helps Which Services, When
Avoid Duplicated Effort,
Risk Identification
and Mitigation Realize
Against them SOA Benefits Earlier and
Support Improved Ability to
Source of Risk
How to Lessen Impact Deliver Projects to SOA Risk Profile For
Projects
SOA Requires Capability
Planning
Capability Development
to Improve Ability
to Deliver on SOA Project
SOA Requires Competence
in a Range of Areas
Prioritized Projects
In Project Portfolio
Leverage Services Portfolio
Maximize Reuse
Align with Platform Availability
1. Create a Transformation Strategy 20

LiquidHub
Confidential

ProgramGovernance Business Service Methodology Solution-Based

Management Model Domain Model & Tools Orchestration &
Plan BusinessRefinement SolutionChoreography
Business ESA Blueprint Services Business Portfolio & Business
Architecture & Conceptual Design Services Delivery Services
Model Architecture Model Portfolio Roadmap Management

InformationBusiness Enterprise Metadata ApplicationFederated

Architecture Process Data Model/ Repository PlatformsData Source
& Taxonomy Models Semantic Design & ESB and
Model Data Services
Technology Application SecurityNetwork Network Technical
Services Platforms/ Services
Architecture Infrastructure
Management
Reference Model ESB Blueprint Architecture Services Services
Envision Engineer Execute
(Strategy and Plan) (Architect/Design) (Develop/Implement)

Program Management

Work Enterprise Business

Services
Streams
Information Management
1. Derive the Business & IT Development 21

Handshakes LiquidHub
Confidential
1. People and Ownership 22

LiquidHub
Confidential

You, or you in the context of a team have to provide

evidence to leadership or stakeholders that the actions and
deliverables
Authority of a SDLC phase are in conformance with the expected
requirements for that phase in order to ensure success, and
provide supporting explanations
otherwise.
The bottom-line is that the burden of success or failure for
the delivery of that phase is upon you or a team that you are a
member.

You are a decision-maker and enabler for those decisions

Accountability to be realized. Bottom-line, it does not matter whether you have the
accountability or responsibility, based upon intelligent reasoning and
experience, you can initiate actions that will cause effect and
resolution.

You are held responsible when the actionable activities

within specific phase of a SDLC can be traced back to you.
Responsibility For example, BA's and Developers would be responsible for
executing their respective phases.
Bottom-line, there is tight-coupling between given atask to
perform and executing that task.
 1. The Service Management Lifecycle 23

LiquidHub
Confidential

New Service Litmus Test New Service Workflow Upgrade an Existing Service
Preconditions : The service to be created has passed the “litmus” test .
Start Preconditions: The service to be upgraded is in the “Deployed” state..

Start

1. Service Provider (or

Service Consumer)
* New Service Request Start
submits New Service form from litmus test is
Request form forwarded to ISS
Can be Execute “Add * Business area signs-off on service upgrade
used as-is Consumer” flow * State = “Registered”
* WSRR Admin records
* Add new service entry into WSRR with the
2. Drop Not needed, 1. Register name, description, corresponding version number.
2. Re-evaluate / 1a. Search
Similar
1b. Manner of Service not compliant Service classification, etc. in * Copy applicable artifacts from previous version .
service
Change Approach WSRR
exists
resuse? WSRR * Mark new version of service as “Planned”
* State = “Dropped”
Can be used Execute
after service “Upgrade * Business area signs-off (i.e. becomes Start a “Retire Service Workflow” for the
Service does upgrade Service” flow informed) on plan and security model Should any version(s) that need to be retired. (Policy :
not exist
* Add relevant properties to WSRR.
Yes
versions be retain as few versions as possible, no
Yes * Add preliminary WSDL, XML, XSD if available . retired? more than three, unless approved by
IGC)
1d. Can idea
No
1c. Passes service * State = “Planned”
be reworked? checklist test ? Example Service Checklist On hold 3. Define * Web service security model is defined
* Will service support business area goals efficiently ? Service not needed
This should be answered by a business person.
Service * (SDLC’s SOW and Func. Spec are completed)
* Add relevant WSRR properties (e.g. protocol, etc)
* Is there a reasonably good chance for reuse?
- Is service too course -grained, retarding reuse?
Yes - Will service performance promote reuse? Xfer of service Update WSRR
Yes
- Expected to be used by multiple consumers? ownership? accordingly
No * Is the projected service life long enough to warrant 4. Defer 5. Drop * State = “Defined”
creating a service? Service Service * Must register WSDL and XSD in WSRR
6. Design
1e. Will service be * Add/update appropriate WSRR properties(e.g.
No
1f. Still a good
composable with * Is service too fine-grained to be a service? Think Service
idea?
other services? about usability and performance issues. endpoint, MQReplyQ)
* State = “Deferred” * State = “Dropped” * (SDLC’s Detailed Design is completed ) No
Failed
Yes * State = “Planned”
Define
Yes * Update WSRR with WSDL, XSD, XML,
Extensions to
7. Develop * State = “Designed” Policy artifacts , description, classification ,
Service
STOP!
Execute “New Service * Preliminary SLA, OLA etc.
Don’t create
Service” flow
service

* State = “Defined”
* State = “Developed” * Update WSDL and XSD in WSRR
8. Validate 6. Design
* Functional Testing * Add/update appropriate WSRR properties(e.g.
Service
Retiring Service
Service * QA Testing signoff endpoint, MQReplyQ)
* LoadRunner testing signoff * (SDLC’s Detailed Design is completed)

Preconditions: The service to be retired is in the “Deployed” state * State = “Validated”

* SLA, OLA sign-off and stored in WSRR
Post-conditions: Service is made unavailable for use and the WSRR is updated reflecting the retired state. 9. Deploy
* WSRR updated to reflect service endpoints, 7. Develop * State = “Designed”
Service
WSDL, XSD, XML, policy, classification ,
Service * Update SLA, OLA in WSRR
properties, and other metadata

Start

10. In-service
* State = “In-Service” Failed * State = “Developed”
Support
* WSRR is consulted and all service Testing Test Service * QA Testing with all service consumers
consumers are notified of service to be * LoadRunner testing
Announce retired. All stakeholders agree upon a date Retire
Retirement and give written permission for the service to
be retired.
Execute “Retire * State = “Tested”
Service” flow * SLA must be signed off and stored in WSRR
Deploy
* WSRR updated to reflect changes in service
* Service state is updated to “Deployed - Service
endpoints, WSDL, XSD, XML, policy ,
Retiring” and retirement date is documented classification , properties, and other metadata.
In-service/ as RetireDate property in WSRR. No new
Retiring consumers can use the service.
Deploy
* Each service consumer shall provide a
written sign-off when they no longer depend
Retire date on the service.
occurs
Service * State = “Deployed”
Support * Production support of the service

* Following IBC’s Change Control polices,

Retired ISS/Service Provider will deactivate service
and update the WSRR to indicate the
service is now retired.
1. IT Organizational Team Structures 24

LiquidHub
Confidential

Enterprise-Wide
Functional Teams
Teams
Quality Control Team

• Automated Testing
• Service Testers
• Dashboard ISGC

Services Development Team

• Core Service Development

• ESB
• Expertise in XML,WSDL,
Spring, and Hibernate

ISS Governance COE

BRE Team

• Tech Lead/ 4 Developers Governance Team

• Establish BRE Methodology
• Enrollment rules exist today • Manager / Architect / SME
• Manage Application Portfolio and prioritize opportunities
• Outward Facing
• Interface with ISS
Solution Integration Team

• Matrix Committee Enterprise Architecture

• Application Framework
• Architecture Standards
• Best Practices

API Development Team

• MHS API
• Legacy API
• Planmate API
BPM Team
• Avoid Bolt-on Issue
Business Area BPM COE
• Knowledge Acquisition (To be decided)
• Establish Methodology
Canonical Model Team • Pick BPM Tool • BPM Lead
• BPM Architect / Sys. Analyst • Business Analyst
• Establish /Publish Model
• Version Control
• Based on Industry Standards
Existing Team Future Team Matrixed Team

Cross-Functional team members from all departments are used on a project by

project basis
1. Federated Governance in Actions 25

LiquidHub
Confidential

Business Services IT
Matrix Groups
Quality Control Team
Enterprise • Automated Testing
Governance Architecture •
•
Service Testers
Dashboard

Projects
Committee Group
Services Development Team

• Core Service Development

• ESB
• Expertise in XML,WSDL,
Manage
Create/

Spring, and Hibernate

Assign BRE Team

• Tech Lead/ 4 Developers

• Establish BRE Methodology
Adapt/ • Enrollment rules exist today

SOA
Policies Leverage Solution Integration Team

Feedback •
•
Matrix Committee
Application Framework
• Architecture Standards
• Best Practices

API Development Team

• MHS API
• Legacy API
• Planmate API
• Avoid Bolt-on Issue

Adapted/
Authored Canonical Model Team

• Establish /Publish Model

• Version Control
• Based on Industry Standards

Back Office Back Office

SOA SOA
Standards Procedures
1. Where do you want to go? 26

LiquidHub
Confidential

From Transition Future

Unaligned Via a Federated Matrix IT Department Aligned Departments
Departments

Unaligned Enterprise Architecture policies, Aligned Shared

Unaligned standards, directives, etc

Common
Unaligned
Service-based policies,
Reactive

Proactive
standards, directives, etc

• IT Plan Non Existent • IT Plans Aligned with

or Not Aligned with Business Plans and
Business Plan Common and Initiatives
• IT Reactive to Shared Services • SOA Strategy that is
Business Initiatives Communicated
• No SOA Strategy Widely
• No SOA Roadmap • Well-Defined
• Silos of SOA Business Benefits
Business Focus and Sought from SOA
Alignment Strategy
• SOA Roadmap
Aligned to Deliver on
Business and SOA
Strategy
Questions and Answers 27

LiquidHub
Confidential

For more information on this

Presentation, please contact:
Jatinder Prem
jprem@[Link]
302-521-7479