A Practical Approach to Service Oriented Architecture

1
A Practical Approach to Service Oriented
Architecture

• presented by
• Barbara Brown
• Director, Technical Services
• Alliance Systems Programming
• bbrown_at_alliancesys.com

2
Agenda

• What it is
• Why you care
• How to get there
• Realistic expectations

3
What it is Definition

• Service something which performs work for
  another
• Oriented focused, directed
• Architecture a plan or structure of a system
  that describes the properties of its components
  and their relationships
• Service Oriented Architecture a plan or
  structure for a system in which the components
  perform discrete well-defined units of work for
  requestors through well-defined interfaces

4
What it is Key Characteristics

• Modular break down complex processes into
  components
• Encapsulated hide complexity of implementation
  within modules with well defined interfaces
• Separation of concern requester is not
  concerned about details of how a service is
  implemented
• Loosely coupled modules connected by simple
  interface no technology dependence
• Composable modules may be assembled to create
  other services

5
What it is Key Characteristics

• Coarse grained service provides complete
  business function coarseness determined by
  reusability.
• Interface-based design service is independent of
  platform, language or other technology
  considerations.
• Single implementation only one service for each
  function
• Stateless each request is treated independent
  from what came before or what will come next
  (does not prohibit passing of state-related
  information in parameters)

6
Why do you carePotential Benefits to the
Business

• Increase business responsiveness and agility
• Provide a competitive advantage
• Transcend organizational boundaries
• Save money, time, and people
• Eliminate frustrations with IT
• Reduce product development cycle times
• Identify value in business processes

7
Why do you careBenefits to IT

• Reusable services mean less coding
• Services are built by contract with user
  department involvement
• Promotes process consistency
• Localization of function reduces maintenance
  effort
• Standardized interfaces and separation of concern
  reduce solution complexity
• Promotes understanding across the business of the
  value of IT
• Justifies IT expenses and capital outlays

8
How to get thereAnalyze the Business Process

• If services are not defined as a collaborative
  effort, you are setting yourself up for failure.

This is a JOINT effort that must involve the
parts of the business who perform these
functions.
9
How to get thereAnalyze the Business Process

• Identify the services
• what functions are performed?
• what level of granularity is warranted?
• Example order entry

10
How to get thereAnalyze the Business Process

• Design the service
• How is the function performed?
• Are there (or should there be) services that can
  be used by this service?

11
How to get thereAnalyze the Business Process

• Define the interface
• what parameters should be passed to the service?
• what parameters should be delivered by the
  service?
• consider possible future uses
• optional parameters allow for greater flexibility

12
How to get thereAnalyze the Business Process

• Define the interface
• what form should the service take?
• Web Service
• Stored Procedure
• Service Program

http//www
EXEC
CALL PGM(..)
13
How to get thereCreate Service from Existing
Application

• Determine what business functions are required to
  be implemented as services
• Design interfaces for the required functions.
• Determine where those functions are currently
  implemented.
• Decide how much of the current implementation
  should be used as a base for the new functions.
• Develop the new functions.
• Determine whether the new functions should be
  used in the existing (green screen) application
  (s).

14
How to get thereAnalyze the Application

• Not necessary to rewrite entire RPG application
  to make a service from RPG business logic.
• Stateless means new considerations for developer
• lists vs result sets
• record locking

15
How to get therea new mindset

• Each modification is an opportunity
• Should I create a service from the function to be
  modified?
• Which existing programs should be reworked to use
  the service?
• If you have the rare option of starting from
  scratch, consider
• Buy a package built on SOA
• Well documented services and interfaces
• Build from existing services
• Build new services

16
How to get therea new mindset

• Governance
• Enforce standards of SOA
• Loosely coupled
• Stateless
• Well defined interface
• Need for infrastructure services
• Security
• Audit
• Recovery
• Service Directory

17
Realistic Expectations Do you need SOA?

• NO if.
• Little or no integration.
• Most processes are manual or document-centric
  little or no automation.
• Most application development uses same
  programming model.
• Most business processes covered by one or two
  customer relationship management (CRM) and
  enterprise resource planning (ERP) applications
  with little need for integration
• Existing skill base is too far removed from being
  able to implement SOA.
• No business need identified that would benefit
  from SOA.
• Existing revenue stream could be adversely
  affected by new business services.
• Business partners have no interest in automating
  intercompany processes.
• Business requires extremely high-volume,
  synchronous, real-time transactions.

18
Realistic Expectations Do you need SOA?

• Yes if
• Existing business logic needs to be used by other
  internal applications, business partners, or on
  the Internet improve value of IT assets
• Costs of integrating business units
  (acquisitions, mergers, restructuring) are too
  high not offset by comparable value
• Health of the business demands that you respond
  more quickly to the demands of the marketplace or
  competitive pressures.
• Need to do more with less
• Business partners provide services in conjunction
  with in-house services.
• Need to improve the efficiency of employees by
  increasing percent of time focused on delivering
  core services to customers.

19
Realistic Expectations

• Establishing and enforcing standards is key
• Expect it to cost more before it costs less
• More payback where more possibility for reuse
• Getting to SOA is an on-going process