Starting your First SOA Project.Steps to Success

Starting your First SOA Project…Steps to Success

David S. [email protected]

Copyright 2007 The Linthicum Group, LLC

What to Consider…

• Consider the people.

• Consider the Buy-in.

• Consider your own needs.

• Consider the approach.

• Consider the business case.

3

Current State of Things…Real World

• Hype is huge, and management by magazine is the way of the world these days.– “I got to git me one of them SOAs”– “A SOA will fix that.”– “SOA 2.0”

• Bad practices:– Selecting technology before understanding your

requirements and needs.– Not creating a business case.– Using the wrong people.– Lacking funding and empowerment.

4

Why SOA Fails

1. The enterprise/agency considers SOA a project versus what it is; a more holistic notion.

2. They use 2nd tier talent.

3. They are under-resourced.

4. They allow the vendors to define their solution.

5. Requirements are not fully gathered.

Consider the people.



Train before you go…

• Be realistic about the talent for the project.

• Sponsor training, and make sure to focus on the details.

• Don’t be afraid to make the cuts.

• Consider the politics.

Consider the Buy-in.



It comes from the top…

• Most SOAs only live with approval and support from the top.

• Thus, projects that don't have sponsors in the right places are doomed, typically due to politics, not technical failure.

• SOA is a huge change in the way you approach IT, and this change requires resources and support.

• If you don't have them, don't try SOA.

Consider your own needs.



Understand all application

semantics in your domain.

SOA

Metadata

SOA

MetadataMeta data analysis

Data abstraction

layer definition

Data

Abstraction

Layer

Data

Abstraction

Layer

Data services definition

Data

Services

Data

Services

Legacy

Metadata

Legacy

Metadata

External

Metadata

(B2B)

External

Metadata

(B2B)


Understand all services

in your domain.

Candidate

Services

Candidate

ServicesService analysis

Metadata and

services analysis

Services

And

Information

Services

And

Information

Performance analysis

Services

And

Performance

Services

And

Performance

Legacy

Services

Legacy

Services

External

Services

(B2B)

External

Services

(B2B)

SOA

Metadata

SOA

Metadata


Understand all processes

in your domain.

Candidate

Processes

Candidate

ProcessesProcess analysis.

Define metadata, services,

and processes

Processes,

Services,

And

Information

Processes,

Services,

And

Information

Process integration

analysis.

Process

Integration

Diagrams

Process

Integration

Diagrams

Candidate

Services

Candidate

Services

External

Processes

(B2B)

External

Processes

(B2B)

SOA

Metadata

SOA

Metadata


Define new services.

Candidate

Processes

Candidate

Processes

Service definition.

Service design.

Processes,

Services,

And

Information

Processes,

Services,

And

Information

Service implementation.Process

Integration

Diagrams

Process

Integration

Diagrams

SOA

Metadata

SOA

Metadata

Candidate

Services

Candidate

Services

Service

Definition

Service

Definition

Service

Design

Service

Design

Service

Implementation

Service

Implementation


Define new processes.

Candidate

Processes

Candidate

Processes

Process definition.

Process design.

Processes,

Services,

And

Information

Processes,

Services,

And

Information

Process implementation.Process

Integration

Diagrams

Process

Integration

Diagrams

MetadataMetadata

Candidate

Services

Candidate

Services

Process

Definition

Process

Definition

Process

Design

Process

Design

Process

Implementation

Process

Implementation

Consider the approach.


16

Understanding the SOA Levels…What Works for Your Enterprise?

• Level 0 SOAs are SOAs that simply send SOAP messages from system to system. There is little notion of true services, but instead, they leverage Web services as an information integration mechanism. Hardly SOA, but certainly a first step.

• Level 1 SOAs are SOAs that also leverage everything in Level 0 but add the notion of a messaging/queuing system. Most ESBs are level 1 SOAs, leveraging a messaging environment that uses service interfaces, but really does not deal with true services (behavior), and instead moves information between entities as messages through queues.

• Level 2 SOAs are SOAs that leverage everything in Level 1, and add the element of transformation and routing. This means that the SOA can move information from source and target systems, leveraging service interfaces, as well as transform the data/schemas to account for the differences in application semantics. Moreover, by adding the element of intelligent routing, you're able to route the information based on elements such as source, content, and logical operators in the SOA.

• Level 3 SOAs are SOAs that leverage everything in Level 2, adding a common directory service. The directory provides a point of discovery of processes, services, schemas, and such, allowing all those who leverage the SOA to easily locate and leverage assets such as services. Without directories, the notion of service reuse--the real reason for building SOAs--won?t work. Directories are typically standards-based, including UDDI, LDAP, and sometimes more proprietary directories such as Active Directory.

• Level 4 SOAs are SOAs that leverage everything in Level 3, adding the notion of brokering and managing true services. Here is where the brokering of application behavior comes into play. In other words, at this level we are not only about managing information movement, but the discovery and leveraging of true services.

• Finally, Level 5 SOAs are SOAs that leverage everything in Level 4, adding the notion of orchestration. Orchestration is key, providing the architect with the ability to leverage exposed services and information flows, creating, in essence, a "meta-application" above the existing processes and services to solve business problems.


How Do you Build A SOA?

Understand your business

objectives and

define success.

Define your problem domain.

Understand all application

semantics.

Understand all services.

Understand all processes.

Define new services.

Define new processes.

Select your technology set.

Deploy SOA technology.

Test and evaluate SOA solution.

Consider the business case.



So, Why SOA?

• Improved Adaptability and Agility

– Respond to business needs in near real-time

• Functional Reusability

– Eliminate the need for large scale rip and replace

• Independent Change Management

– Focus on configuration rather than programming

• Interoperability instead of point-to-point integration

– Loosely-coupled framework, services in network

• Orchestrate rather than integrate

– Configuration rather than development to deliver business needs


The Value Proposition of a SOA

• We implement SOA for two major reasons. – First is the ability to save development dollars

through reuse of services.

– Second is the ability to change the IT infrastructure faster to adapt to changing

needs of the business, or agility.

– Enhance, not replace, existing EA.


Reuse…Yes Again

• Under the concept of service reuse, we have a few things we need to determine to better define the value. These include:– The number of services that are reusable.

Complexity of the services. The degree of reuse from system to system.

• The number of reusable services is the actual number of new services created, or, existing services abstracted, that are potentially reusable from system to system.

• The complexity of the services is the number of functions or object points that make up the service.

• Finally, the degree of reuse from system to system is the number of times you actually reuse the services. We look at this number as a percentage.


So, What do you Do?• In order to determine their value we must first determine

the Number of Services that are available for Reuse (NSR), the Degree of Reuse (DR) from system to system, as well as the Complexity (C) of each service.

• The formula to determine value looks much like this:

Value = (NSR*DR) * C


SOA=Agility

• Agility is a strategic advantage that is difficult to measure in hard dollars, but not impossible. We first need to determine a few things about the business, including:

• The degree of change over time is really the number of times over a particular period that the business reinvents itself to adapt to a market.

• The ability to adapt to change is a number that states the company’s ability to react to the need for change over time.

• Finally, the relative value of change is the amount of money made as a direct result of changing the business.

24

Final Words

• Pay me now, or pay me later. Make sure you do it right the first time…get the help you need.

• Don’t be afraid to experiment, and admit you’re wrong…backup and try again.

• Keep your vendors working with you.• Empower those working, so they can work to get

things done. Avoid politics, if possible.• Learn all you can, but don’t get caught up in the hype.

• Put standards in their proper place. • Small battles win the war…Keep that in mind.• Give yourself plenty of time, never skimp on any of

the steps.

The Linthicum Group, LLC

• The Linthicum Group was established to provide quality SOA consulting services to product or end-user organizations who are seeking guidance beyond the SOA hype.

• The group seeks to understand your requirements first, and then define the correct solution to meet the particular needs of your organization.

• We leverage proven approaches and methodologies, using industry best practices.

• Schedule a free one hour consultation. Contact: [email protected].



Thanks!

• Blogs:– eBizq.net “Linthicum Channel”– InfoWorld “Real World SOA”– Intelligent Enterprise “SaaS Advisor”

• Weekly Podcast– InfoWorld SOA Report

• Columns– Web Services Journal

Documents

Starting your First SOA Project.Steps to Success