jaap schekkerman s o a enterprise arch s tyle

© 2004 Capgemini - All rights reserved 1

Founding Sponsors

This Presentation Courtesy of the

International SOA Symposium

October 7-8, 2008 Amsterdam Arena

www.soasymposium.com

[email protected]

Gold Sponsors

Platinum Sponsors

Silver Sponsors

© Logica / IFEAD 2001 - 2008. All rights reserved

Services Orientation; an Enterprise Architectural Style

‘How to distinguish Reality from Parody’

Jaap Schekkerman, B.Sc.

President & Thought Leader Institute For Enterprise Architecture Developments

Opinion Leader Enterprise Architecture, Logica Management Consulting


SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 3

Agenda

• About Your Speaker

• Services Orientation: An Enterprise Architectural Style

• Geek & Poke‟s experiences with SOA

• Why so many SOA Projects Fail

• Why so few SOA Projects Succeed

• Critical Success Factors in SOA

• What can you Learn from that


About Jaap Schekkerman

Professional Associations:

Ass. Professor Technical University, Delft ; University of Amsterdam; Open University, Heerlen; The Netherlands

Advisory board member of the Federal Enterprise Architecture Certification Institute, USA.

Co-Founder & Alliance member of the Global Enterprise Architecture Organization, New Zealand.

Former Vice-President of the International Association of Enterprise Architects, USA.

Member of the Institute for Defense and Government Advancement (IDGA), USA.

Member of the European eGovernment Good Practices network, European Union.

Member of the 'MANYWORLDS' knowledge network of Business Thought Leaders, USA.

Member of the ISO/IEC 42010:2007 working group, -- Recommended practice for architectural description of software-intensive systems --, USA.

Member of the World Wide Institute of Software Architects (WWISA), USA.

Member of the Netherlands Society of Information Architects (GIA), NL.

Author / Co-Author of several EA & SO related books & publications

Some Statistics

President & Thought Leader, Institute For Enterprise Architecture Developments

Opinion Leader Enterprise Architecture, Logica Management Consulting


SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved

Hi! Are You SOA Consultants.......... or Are You Practioners......?

Services Orientation; an Enterprise Architectural Style

5


So How are we going......Trends & Developments in Enterprise Architecture

EnterpriseArchitects

Compliancy & Enterprise

ArchitectureServices Orientation as an

Enterprise Architecture style

Economic Value of

Enterprise Architecture

Portfolio Management &


Implementation of Enterprise

Architecture Function

Assessment of Enterprise

Architecture Maturity

Developmement of

Enterprise Architectures

Assessments of Enterprise

Architectures

Realtime


Business Innovation,

Strategic Planning & EA



Firts of all..... Enterprise Architecture is an Enterprise Planning Discipline


And...... Solution Architecture is a Development Discipline



However they need each other.... Where EA is Defining the Environmental Conditions...

VisionVision

Strategy &

Planning

Strategy &

Planning

Enterprise

Architecture

Enterprise

Architecture

Enterprise

Program

Management

Enterprise

Program

Management

TechnologyTechnologyBusiness

Value

Business

Value

EA

Transformation

Programs

EA

Transformation

Programs

Budget

Process

Budget

ProcessSolution

Architecture

Solution

Architecture

EA MeasurementEA Measurement

EA ProgramEA Program

MissionMission

Validation

(Feedback loop)

Validation

(Feedback loop)

StakeholdersStakeholders Enabling

Context

Enabling

Context

Goals &

Objectives

Goals &

Objectives

Services

Orientation


Is.......Solution Architecture dealing with the Domain Specific Elements

Domain Processes /

Activities & Data,

Domain Business

Services, Business

Modeling

Workflow, BPMN

Business

Domain

Technology

Domain


Environment

Solution Architecture

Environment

Services

Oriented

Concepts /

StylesSO Reference

Architecture

Services Oriented

Standards

SOE: Business

Principles, Business

Services Portfolio,

Semantics, Ontology,

Policy

Business & IT

Strategy, Transition

Planning, SO

Governance

Event

Services

QoS

Integ

ration

and

Tran

sform

ation

Services

Bu

siness E

vents

Extern

al Even

tsS

ystem E

vents

Au

tho

rization

Au

then

tication

Perfo

rman

ce

Mo

nito

ring

Work DB

Enterprise

Rule

Repository

InferenceSituational ResolutionResearchForward / Backward chaining

DeclarativeNetwork

PersistentObjectModels

Portlets PDF/ODF Wireless Correspondence e-Mail HTML/JSP UI

<< Business Entity>>

Service

Overeenkomsten


Bedrijfsinstallaties

Betreffende

<<Business Entity>>

Klant

Heeft1 1 .. N

Klant Contract

11 .. N

Contract Bedrijfsinstallaties

1 .. N


Onderhoud Status


Betreffende


Financiële

Administratie

<<Data Type>>

Klant Gegevens

<<Data Type>>

SO Gegevens

<<Data Type>>


Gegevens

<<Data Type>>

Onderhoud

Gegevens

<<Data Type>>

Financiële Gegevens


Partner

Contract

Betreffende

<<Data Type>>

Partner Contract

Gegevens

1 .. N

Periodieke Verrekening


Pand

<<Data Type>>

Pand Gegevens

Aangaande

1 Bedrijfsinstallaties

Periodiek Voorschot

<<Business Entity>>

Partner

<<Data Type>>

Partner Gegevens

Heeft

Voert Uit Onderhoud

Financial Services Healthcare Insurance

Government Telco

BAMOrganizationBPA

DecisionRule

ERP

SLA

Rich Media

+

DecisionRule

ERP

SLA

Security

Services

10



So Where we came from..........The Changing Face of Different Operation Styles

Application

Oriented

Product

Oriented

Technolo

gy

Sty

leB

usin

ess S

tyle

1990 - 2000

(ERP, CRM,

etc.)

Packages

Oriented

Process

Oriented

2001 - 2006

Services

Oriented

Services

Oriented

2007 – 2012?

Agent

Oriented

Value

Oriented

2013??

Specific Generic Agile Inteligent

Source: (C) Copyrights IFEAD, 2001-2008

11


And where are we now today.........Do You Wanna Be Agile.... Or Not?

Representational State Transfer, also known as REST, is

a style of software architecture defined by a collection of

architectural principles. REST is applied specifically to

such distributed systems as the Web, and stipulates

mechanisms for defining and accessing resources.

• A set of technologies that can be used with 2 design

philosophies

• Benefits to both approaches

• Large overlap in their capabilities

• Useful for both communities to look at the benefits of

the other camp

12



So, How to bring this together…..EA provides a mechanism for Services adoption

Business

Technology

Drives Informs & Enables

Business and Customer Results

Enterprise Business Activities / Processes

Business Strategies

Enterprise Business Requirements

Capability Requirements & Profile

Services Provision Layer

Services Integration Layer

Technology & Infrastructure

Applications Data/Information Services Technology

Components

Achieves

Aligns to and implements

Fulfills

Integrates and provides

Drives

Leverages

Supports

Specifies

The Enterprise Architecture model is the “line of sight” from

business strategies to services and technologies that support them Source: (C) Copyrights IFEAD, 2001-2008

13


And.... What about Services Orientation?

• Don‟t bother your

management with these

buzzwords!

• But understand how they

are related to each other

• You have to deal with these

buzzwords if you like or not!

• Explain their impact in terms

the business can

understand!

Based On Sources: Oasis, IFEAD

With Who? What? How?Why? With What? When?

Informationarchitecture

Businessarchitecture

Technicalarchitecture

Information-

architectureSystems SOA

Service

Oriented

Architecture

SOC

Service

Oriented

Computing

SPA

Services

Paradigm

Adoption

STP

Services

Transition

Plan

Enterprise Architecture Framework

Services Orientation is an Architectural Style of Enterprise Architecture

Services

Oriented

Services

OrientedSOE

Services

Oriented

Enterprise

14



How is this different....... The Characteristics of Services Orientation

• Adopting the „Services paradigm‟ requires a Services Oriented Reference Architecture

• The “Services” in SOE are business services

• Business Services connect Business Partners (Value Network)

• Services are linked together to implement business processes / activities

• Services are reusable and supplied or consumed by many

• Connectivity and functionality are truly separated

• Services orientation requires a redesigned clean common data infrastructure

• Services are Loosely coupled

• Offers reusability at a functional level

• Favors business agility over technical efficiency

Based On Sources: Oasis, IFEAD





Information

architectureSystems

• Between Partners

• Between Businesses

• Between Business processes / Activities

• Between Business Services

• Between Software Services

• Between Service Components

• Between Network Services

15


How Getting It Right………….Services Oriented Enterprise

(C) OASIS, IFEAD, ZAPTHINK, OMG, W3C, 2008

Joined up processes

Semantics

Ontology's

Common data infrastructure SO Reference Architecture





Information

architectureSystems

Business agility requires shared understanding and alignment of:

SOA requires shared understanding and alignment of:

Message Format

Status (manageability)

Protocols

Security

Services

Business Outcome & Goals

Business Processes

Business Semantics

Business Obligations

Business Services

16



Enterprise Business Modelling

Solution Delivery

But You have to Go to the Details to Understand.......

Service Portfolio Planning

Service Provisioning

Business Process Design

Capabilities

Required Services

Operational

Services

Business

Process Model

Planned Service Descriptions Service

policies

Business Ontology

Business Type model

Business

Policies

Value

Chains

Define Policies

Identify Services

Describe Services

Publicize Portfolio Plan

Specify a Service

Acquire the Service

Certify, Deploy Service

Publish Service in Catalog

Model Business Process

Design Software Solution

Request Services and Operations

Construct Software Solution

Test Software Solution

Define Business Capabilities

Define Business Relationships

Define Business policy

Model Business Semantics

Model Business Capability

Model Value Chains

SO Reference Architecture

WS* / SOA Standards

SO Concepts / Styles

SO Principles

Business Concepts

Reference Environment

17


And then....... SOA again more complicated by ESB proliferation

• "There's a whole space emerging

among enterprise architects called

ESB intermediation,". "They're finding

that two or three different divisions of

their company are using different

ESBs from different vendors. Yet

they're trying to build business

processes across these ESBs. But

the ESBs are designed to be their

own center of the universe. How do

you intermediate transactions across

these ESBs?"

Dave Linthicum CEO of the Linthicum Group, LLC

and SOA Guru said:

“Call me crazy, but would it not make more sense to

have a centralized plan as to what the SOA should

be, based on the requirements of the business,

versus people dashing out and shelling out the

dollars for an ESB for some one-off tactical reason,

or more likely just acting out of reaction to the hype?

Now, you’re left with a dysfunctional mess that’s not

easily corrected, and clearly costly. …why the heck

are you attempting to integrate these integration

engines when they should perhaps be displaced

altogether? Because, call me crazy again, that

would be cheaper.”

18



Why so many SOA Projects Fail

• Burton Group found a 50% complete failure rate in the 20 companies that took part in their study in 2008. Another 30% were considered neither successful nor wholly failed.

• "Many of them had deployed multiple successful projects, but most of those projects were focused on just one integration problem,“. "It was just a bunch of Web services. … The service is only built for one application and it's never going to be used again."

• Such projects amount only to a less efficient method of doing EAI. Instead users focus projects around quality data, systems modernization or business process automation.

• "BPM and SOA are like the peanut butter and the chocolate in the commercial the way they go together,“.

• The Burton Group listed numerous other failure factors, including:

– Lack of defined service models

– Infrastructure focus

– Governance only of SOAP-based systems

– Failure of developers to leverage the runtime governance in place

– Initiatives led by and solely involving the application development group

– Roadmaps lacking specificity

– Inability to measure ROI

– Project-centric culture

– An "I'm special" attitude

Source: Burton Group, July 2008

"The attitude is I'm so special I can't use this service

everyone else is using,". "I need my own thing."

19


Why so few SOA Projects Succeed

• The Burton Group found that success came to SOA proponents who pay attention to the cultural shift that needs to take place within the business, cemented by good governance. The successful businesses had “incredibly inspiring” stories to tell.

• Here are the common denominators Burton Group found within the successful efforts:

– Business and IT reorganization, usually with a new CIO coming on board

– Sponsorship at the C-level or by the Board of Directors

– Agile/iterative Development Methodologies put into place

– Projects tied to and measured by Business Goals, not IT drivers

– Well-defined Funding and Maintenance models that balance the needs of service providers and consumers

– A simplified architecture, making it easier to access and manage quality data

– A Culture of trust between Business and IT

Source: Burton Group, July 2008

Time

SOA IT Cost Curve Over

Time

Requirements

Gathering, Services

Development &

Integration

Investments

€€

Investm

ents

Maintenance

€ € Costs

reduction

Compared to

Traditional

Approach

Source:

Year 0 Year 5? Year 10?

20



Source: Thomas Erl, IFEAD

Critical Succes Factors in Implementing Services Orientation

1. Not Measuring the Services Oriented Maturity• Organizations are at different levels of maturity in the adoption and incorporation of Services Orientation.

Some are just beginning to explore the world of SO while others have already experienced with web services

but that is not SO.

2. Building SOA like traditional Distributed Architecture• The number one obstacle organizations have been facing when attempting to achieve SOA is building

service-oriented solutions in the same manner in which traditional distributed solutions have been built, under

the pretence that SOA is actually being achieved.

3. Not Standardizing SOA• SOA, like any other architecture, requires the creation and enforcement of internal design standards for its

benefits to be truly realized. For example, if one project builds a service-oriented solution in isolation from

others, key aspects of its solution will not be in alignment with the neighbouring applications it may be

required to interoperate or share agnostic services with one day.

4. Not Creating a Transition Plan• The chances of a successful migration will be severely diminished without the use of a comprehensive

transition plan. Because the extent to which service endpoints are positioned within an enterprise can lead to

a redefinition of an environment‟s infrastructure, the affects of a poorly executed migration can be significant.

5. Not Starting with an XML Foundation Architecture• In the world of today‟s SOA, everything begins with Web services. That statement has become a mantra of

sorts within some organizations, but it is not entirely true. In the world of today‟s SOA, everything, in fact,

begins with XML. It is the standard from which multiple supplementary standards have evolved to form a de

facto data representation architecture.

21


Critical Succes Factors in Implementing Services Orientation, Cont.

6. Not Understanding SOA Performance Requirements• Loose coupling comes at a price. When implemented with Web services, SOA introduces layers of data

processing as well as the associated performance overhead imposed by these layers.

7. Not Building Services based on Business Semantics & Ontology's• Software services need to be based on agreed business semantics and ontology's otherwise services can‟t

be reused from a business perspective.

8. Not having a harmonized and clean Data / Information infrastructure• Key to the success of sharing data/information is the necessity to have a harmonized and clean data

infrastructure with responsible ownership and procedures in place to keep data clean and correct.

9. Not Understanding to find the right balance in Services Granularity• Stating that Services are the central part of SOA and SOE will probably not offend anybody. But methods to

identify Services at the right granularity are only slowly emerging. When talking about SOA the Services are

often seen as a task that will be require only a small effort – so small that we almost don‟t bother talking

about it. However making services small in functionality will deliver larger reusability but also a larger

maintenance and performance problems. Making services larger will deliver more functionality but less

reusability and less maintenance and performance problems, so depending on the generality versus

specificity of a service define the appropriate granularity.

10. Not Understanding the Quality of Services• One important missing requirement often seen in the context of Services Orientation is the management of

Quality of Services. Appropriate control of quality leads to the creation of quality products and services;

these, in turn, fulfill customer expectations and achieving customer satisfaction. Part of this thinking of QoS is

related to requirements about roll back of Services transaction sequences, Error handling, Security,

Authorization and Authentication, etc. Key issue in this context is also, how to check / control the behavior

and functionality of services that are delivered by third parties and how to test and guarantee their behavior.

22

Source: Thomas Erl, IFEAD



But if you can’t meet those........ Here are Some other Solutions.....

23


Thanks for your attention.....

24

http://www.verismall.com/help.htm

jaap schekkerman s o a enterprise arch s tyle

Design

copyrights logica institute

leader institute

business services

rights reserved9

rights reserved6

rights reserved5

soa projects

trends developments