soa building for the future

SOA Building for the Future

XML In Practice XML In Practice Washington, DC 20008Washington, DC 20008

Presented by Saeed Abu ElnajPresented by Saeed Abu Elnaj

212/9/2008 SOA: Building for the Future

Agenda

Few Introductory words on SOAThe Trouble with SOA

The varying views of SOATwo fundamentally different definitions and views of SOAThe developers’ view of SOAThe vendors’ view of SOA

The Literature on SOALack of sufficiently trained and experienced resources

Developer with expertiseEnterprise Architects

SOA Standards and XML being the core of such standardsThe “A” in SOA and the architects view of SOAA Roadmap to SOA: Building for the future


Few Introductory Words on SOA and Services

Service-Oriented Architecture is an architectural approach to designing, building, and deploying information systems such thatthe system is created from simpler manageable building blocks, called “services”

Each service implements a discrete piece of business functionality. These services can then be mixed and matched to create entirely new applications or to deliver new business capabilities.

* Using Definition provided by The SOA Monitor


Services Design Principles

Well-defined service contracts

Service encapsulation

Loose-coupling

“Composeable”

Discoverable

Abstraction

Reusable

Autonomous

Granularity Interoperable

Business aligned Durable


Business and IT benefits of SOA

Increased IT asset reuseReusable services eliminate the need to code from scratchReuse of legacy systems extend legacy investmentFaster and higher quality application development

Increased business flexibility or agilityServices can be mixed and matched to create new capabilitiesNew capabilities can be delivered faster and cheaper

Improved IT flexibility and reduced IT complexityImproved interoperability and internal and external integrationReduced redundancy and maintenance costs


Multi-Layered SOA Architecture and Views

Gov

erna

nce

&

Man

agem

ent


Gartner Key Findings on SOA

SOA was used in more than 50% of large, new applications and business processes designed in 2007By 2010 Gartner expects that more than 80% of large new systems will use SOA for at least some aspect of their designHowever, in 2008 the number of organizations that are planning to adopt SOA for the first time was cut by more than one-half, down to 25 percent from 53 percent in 2007The number of organizations with no plans to adopt SOA more thandoubled from 6 percent in 2007 to 16 percent in 2008Some companies have been disappointed by the low level of service-sharing ("reuse") that they have achieved, and some SOA projects have failed for a variety of reasonsSOA face challenges in governance, testing, configuration, version control, metadata management, service-level monitoring, security and interoperabilityOne of the greatest challenges is managing application logic and data in SOA service components that are spread out over multiple business units


The Trouble with SOA

The varying views and understanding of SOAThere are two fundamentally different definitions /views of SOAManagement view of SOAThe developers’ view of SOAThe vendors’ view of SOAThe architect’s view of SOA

The lack of business case/justification for SOA

The lack of sufficiently skilled resources on SOA

The complex web of SOA Standards: Over 115

The Literature on SOA


The SOA Puzzle and The Two Fundamentally Different Definitions and Views

SOA is a business initiative and is about achieving business modularity and agility through customizable, composable and reusable IT-enabled business processes

Is it a Top-bottom approach where the business leads in the SOA services analysis

SOA is an IT initiative where SOA is viewed as an architectural style whose goal is to achieve loose coupling among interacting software modules

Is it a bottom-up approach where IT leads in analysis and identification of services

Presenter

Presentation Notes

How to solve the SOA puzzle


Management View of SOA

Understanding and/or appreciation of SOA at CxO level

The ever elusive ROI: Only 37% of enterprises have achieved a positive ROI from SOA deployments (Nucleus Research)

Everything that can be counted does not necessarily count; everything that counts cannot necessarily be counted (Albert Einstein)

Presenter

Presentation Notes

; AKA The Spreadsheet View


Developers View of SOA

SOA = Web ServicesWSDL

UDDI

SOAP

REST

Presenter

Presentation Notes

And if you are lucky UDDI


Vendors’ View of SOA

Presenter

Presentation Notes

Making money through Stack of technology Support of Standards that are more and more allowing for mixing and matching of technologies


The Architects’ View of SOA


Lack of Resources

According to a survey of 106 enterprises conducted by Nucleus Research and KnowledgeStorm, fewer than four in 10 developers use SOA

Companies using SOA experienced an improvement in developer productivity by of 28%, however, the productivity savings do notwarrant broad SOA deployment

Evans Data Corp: About 25% of enterprise developers already have an SOA in place and approximately 28 % more plan on following suit over the course of the next two years.

Gartner: Overall, the two major reasons that organizations choose for not pursuing SOA are a lack of skills and expertise, and no viable business case


SOA Standards and Specifications the Full View (innoQ Standards Poster)

Presenter

Presentation Notes

Over 115 standards and specifications related to SOA (Forrester Research)


Simplified View of SOA Standards

Presenter

Presentation Notes

Standards and specifications should be addressed based on requirements and in the context of the technology stack that you use!


SOA Literature

There is little empirical and/or good methodology based literatureWhat we lack a book like “Enterprise Architecture as Strategy” by Jeanne Ross, Peter Weill and David Robertson

Mostly anecdotal and project based experiences

Some Literature examples:Service Oriented Architecture by Thomas Erl (760 pages!)Service Oriented Modeling by Michael Bell (Don’t buy!)Web Services and Service Oriented Architecture by Douglas Barry (Save your money)Understanding SOA with Web Services by Eric Newcomer and Greg Lomow (Useful if using Web services)Enterprise SOA by Dirk Krafig At Al (Save your money)Enterprise Service Bus by David Chappell (Useful if using an ESB)

Presenter

Presentation Notes

There is a lot of material on the Web that is excellent and for free!


The “A” in SOA; The Architect’s View

Enterprise Modeling

SOA Technical Infrastructure

SOA Application Infrastructure

Service Modeling and Development

Service Analysis

Service Design Build Deploy Run Manage

Business Context Analysis and Service Identification


Building for the Future Through an architecture Roadmap to SOA

Define your Itinerary: Create a priority list of projects and services to evolve the

architecture

Define your destination: Future Architecture that meets business needs

(architecture blueprint)

Define Current Location: The “As-is” Architecture


The architecture roadmap has well- defined objectives

Identify the technical and capabilities required to address problems and opportunities in the current and planned business and technical environment

Develop an SOA blueprint architecture as a framework to support the SOA enabled business vision

Develop an SOA architecture evolution plan to incrementally achieve the SOA blueprint architecture

Understand the technical components and competencies needed to build a strong service foundation


Developing an SOA Roadmap

ITERATIVE


SOA Architecture Roadmap Methodology Steps and Deliverables

Identify and prioritize required business and IT capabilities

Determine scope of architecture roadmap

Analyze and agree on SOA & other architectural principles

Analyze architectural requirements & components

Model and evaluate various architectural scenarios

Gather strategy and architecture documentation

Discover & document system functions & data model

Discover & document system infrastructure & interfaces

Analyze and agree on challenges & opportunities

Understand key technology & architectural constraints

Analyze gap between blueprint & current state

Prioritize architectural initiatives to address gaps

Define architectural milestones for prioritized initiatives

Finalize architectural evolution

Identify skills sets and resource requirements

Secure consensus and buy-in of architecture roadmap

Determine scope and objectives for Phase 1 projects

Determine approach and staffing requirements

Define success criteria & performance measures

Secure funding for Phase 1 projects and initiate execution

Required business and IT capabilities

Analysis of requirements & architectural components

Architecture blueprint

Analysis of challenges, opportunities and constraints

Rationale for SOA

As-is architecture

Gap analysis

Architectural evolution plan

Skills and resource requirements

Artifacts to build consensus and secure buy-in

Detailed Phase 1 project plan

Phase 1 project descriptions

Key

Activ

ities

Del

iver

able

s

41 32Assess current state

Develop architecture

blueprint

Define architectural

evolution

Secure buy- in and define tactical next

steps


Phase 1 – Assess current state

Gather strategy and architecture documentation

Discover & document system functions & data model

Discover & document system infrastructure & interfaces

Analyze and agree on challenges & opportunities

Understand key technology & architectural constraints

Analysis of challenges, opportunities and constraints

Rationale for SOA

As-is architecture

Key

Activ

ities

Del

iver

able

s



blueprint


evolution


steps


Phase 2 – Develop architecture blueprint

Identify and prioritize required business and IT capabilities

Determine scope of architecture roadmap

Analyze and agree on SOA & other architectural principles

Analyze architectural requirements & components

Model and evaluate various architectural scenarios

Required business and IT capabilities

Analysis of requirements & architectural components

Architecture blueprint

Key

Activ

ities

Del

iver

able

s



blueprint


evolution


steps


Phase 3 – Define architectural evolution

Analyze gap between blueprint & current state

Prioritize architectural initiatives to address gaps

Define architectural milestones for prioritized initiatives

Finalize architectural evolution

Identify skills sets and resource requirements

Gap analysis

Architectural evolution plan

Skills and resource requirements

Key

Activ

ities

Del

iver

able

s



blueprint


evolution


steps


Phase 4 – Secure buy-in and define tactical next steps

Secure consensus and buy-in of architecture roadmap

Determine scope and objectives for Phase 1 projects

Determine approach and staffing requirements

Define success criteria & performance measures

Secure funding for Phase 1 projects and initiate execution

Artifacts to build consensus and secure buy-in

Detailed Phase 1 project plan

Phase 1 project descriptions

Key

Activ

ities

Del

iver

able

s



blueprint


evolution


steps


The APA Blueprint

Questions & Answers

soa building for the future

Documents