Driving Toward SOA: An Architectural Roadmap

1
Driving Toward SOA An Architectural Roadmap

• Dr. Khalid Mansour

2
Agenda

• Business and IT Drivers
• Current IT Challenges
• Software architecture evolution - styles
• SOA Overview
• What is SOA?
• How does it work?
• Why is it important? Benefits
• Software architectural styles services and
  events
• Lessons learned
• Roadmap activities
• Supplementary Material

3
SOA is

• a method of conceptualizing, designing, and
  implementing business software applications and
  infrastructure. It incorporates centralized
  assembly and management of reusable autonomous
  business functions (services) in a loosely
  coupled manner, with heavy emphasis on accepted
  industry standards. Service-oriented architecture
  helps align your business goals and IT.

4
Business and IT Drivers

• Support for business agility and innovation
• Faster time to market
• Improve capacity and responsiveness of IT
• Improve operational effectiveness
• Reduce costs high maintenance costs
• Allow for business partner integration
• Mergers and acquisitions
• Regulatory drivers

5
SOA
SOA is all about Business Computing

• Digital copy of real-life business services
• Enables flexibility to adopt and transform
  business processes

6
Current State of IT
Barely reactive to changing business needs

• Lack of business agility and flexibility
• slow in addressing changing business requirements
• Increasing complexity and little re-use
• Monolithic applications, tightly coupled rigid
  systems - very fragile
• multiple development platforms, tools, and
  support teams
• custom point to point interfaces expensive and
  complex to maintain
• Lack of interoperability
• Difficultly in quickly deploying industry
  standards
• Data quality and data management issues -
• Multiple, inconsistent sources exist for each
  data entity (master data)
• Infrastructure delays due to replication and
  nightly batch processing
• Difficulty integrating data in real-time data
  based on business events

7
Shift in Strategy

• The IT landscape is changing
• Integration can become the centerpiece!
• Standards and interoperability are key enablers
• IT as a strategic asset that drives the business

• Traditionally application-centric, ERP is the
  centerpiece
• New integration-centric,
• plug-in business functionality

8
Shift to Service-Oriented Architecture

• Process oriented
• Build to change
• Incrementally built and deployed

• Function oriented
• Build to last
• long development cycles

• Orchestrated solutions
• Loosely coupled
• Message oriented
• Abstraction

• Application silos
• Tightly coupled
• Object oriented
• Known implementation

9
What is Service-oriented architecture (SOA)?

• A distributed applications architecture
  (approach) that defines the reuse of common
  services logical units of work to support
  business process requirements
• Leverages standards-based integration (XML and
  Web services) to connect heterogeneous systems
• Higher level of abstraction (coarse-grained
  granularity) focusing on business processes
• Requires underlying enterprise data architecture
  that provides consistent, timely accurate data

10
What is a Service?

• Loosely coupled, autonomous, reusable, and have
  well-defined, platform-independent interfaces
• Provides access to data, business processes and
  infrastructure, ideally in an asynchronous manner
  
• Receives requests from any source making no
  assumptions as to the functional correctness of
  an incoming request
• Each request encompasses a complete and
  independent unit of work
• Each request leaves the system in a long-term
  steady state
• Can be written today without knowing how it will
  be used in the future
• May stand on its own or be part of a larger set
  of functions that constitute a larger service
• Provides for a network discoverable and
  accessible interface
• Keeps units of work together that change together
  (high coupling)
• Builds separation between independent units (low
  coupling)

11
A Service

• It has an interface and contract
• It can have one or more operations (methods to do
  something
• Each business capability is invoked by messaging
• The messages into the service request business
  operations
• The semantics of the operations are around
  business functions
• Take an on-line survey / Complete a promotion /
  Request a sample

12
Service Orientation

• Basic Consumer/Provider view

13
SOA Benefits - The Overall Picture
14
SOA Challenges
SOA Cultural Shift

• Migration to SOA where to start?
• Decomposition of existing applications to
  services
• Focus on process knowledge and architecture
• Change of attitude and learning new skills
  (business process analysis, modelling, etc)
• SOA specific project management
• It takes timeyears

15
SOA Adoption

• Why won't It be adopted?
• Lack of awareness at all levels (CEO and CIO
  levels) of how SOA may help companies become and
  stay competitive
• An IT culture that is resistant to change (CEOs
  are driving SOA to ensure adoption)
• Certain business patterns that are not amenable
  to SOA
• What will be adopted instead? A continuation of
  what we have now
• More tightly-coupled and inflexible applications
• Point-to-point interfaces (a big problem now)
• Lots of replicated and un-managed data
  repositories

16
Progression of Design Styles

• Through 2008, enterprises will combine elements
  of SOA, Event Driven Architecture (EDA)
• SOA is a best practice for software design
• Lack of SOA will become a competitive
  disadvantage
• Invest today in understanding and building SOA
  design and development skills

Gartner 2004, please note the direction of the
black arrows in the pictorial
17
Key Message Evolutionary Approach towards
Implementing SOA

• Tools and technologies will not automatically
  give you SOA
• SOA without good data is doomed to failure
• SOA without governance will NOT realize full value

• SOA abstraction of business events, modeled as
  enterprise services, from the actual underlying
  of applications and data
• SOA is strategic blueprint (need roadmap)
• Long term cultural shift

18
Lessons Learned andSOA Possible Roadmap Steps
19
Few Reminders

• Business case
• Balance between ltinnovation agilitygt and
  ltTCOgt
• Priorities are weighted
• Ensure organizational readiness CEOs can sell
  SOA!
• Senior management buy-in
• Internal communication of benefits to end users
• Execute iteratively
• start small, deliver, in phases, and deliver
  value
• Do not rush to deploy technology solutions
• Do not ignore master data, data quality, and
  security issues
• Do not underestimate the cultural issues
  surrounding change

20
Prerequisites For Building a SOA

• Assess - understand what is needed to support the
  business first
• Build your own Architecture competency
  organization
• Develop your architecture strategy
• Consider your architectural expertise and
  applications development skills
• Consider your development methodology, guidelines
  and standards
• Consider your architectural components
  (infrastructure and tools used)
• Consider your project management expertise,
  training and communications
• Document your business process
• Information architecture (and common data model)
• Build your SOA roadmap - plan to leverage
  existing assets (re-use)!
• Plan for iterative implementation and development
  - crucial

21
High-Level Approach
Discovery
Recommendations
GAP Analysis
Roadmap

• Discovery/Assessment Interview key IT and
  business stakeholders. Review documentation.
  Understand the IT vision, business requirements,
  and current IT architecture
• GAP Analysis - Current state assessment versus
  future state model, or, if not defined, industry
  best practices
• Recommendations Path to a future state model,
  including system building blocks and
  relationships between them, principles governing
  their design, and enabling technologies and
  standards
• Roadmap Scope and prioritize discrete projects,
  and estimate timeframes and deliverables by phase

22
How to Implement SOA.

• Identify pilot objectives and critical success
  criteria
• Identify business domains that represent targeted
  business processes
• Identify the major initiatives planned for the
  next three years
• Begin documenting the domain future state
• Define the following
• Architectural layers and approach for each
  (guidelines, standards)
• Required new services and SLAs information
  bound to those services
• Identify and catalog all needed service
  interfaces
• Inventory all interfaces supported today
• identify Systems of Record for the key data
  entities needed for the above services
• Determine the interactions within and between
  domains
• Begin to develop the models within the model
  driven framework by using the information
  collected in steps 1-6 above
• Define governance and management processes
• Select your technology set, deploy, evaluate,
  manage, and govern (An Enterprise Architecture
  team should provide assistance)

23
Governance Processes Are They Important?
Yes

• Consider defining and implementing processes for
  the following
• proposing and deploying a new service (including
  funding)
• modifying existing services
• versioning, retiring a service
• exposing services to partner
• SOA decision-making and issue-resolution process
• Monitoring the business, technical performance,
  and reuse
• Consider acquiring tools for project management,
  business modeling, service modeling, data
  modeling, data cleansing transformation ETL,
  application development, system management,
  exchange of models/information between tools
  (metadata layer)

24
Possible Risk Areas
Services are only as good as the foundation that
they sit on!

• METADATA is a key to establishing a single
  source of the truth
• one dictionary breeds understanding, two or more
  breed confusion!
• Data must be cleansed and standardized and in
  some cases centralized

25
Thanks for Your Time.Next Section Example
SOA Roadmap Activities