service oriented architecture vs. enterprise architecture: competition or synergy?

Post on 05-Jan-2016

33 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

EI2N '08 Enterprise Integration, Interoperability and Networking Session 3.2. Service Oriented Architecture vs. Enterprise Architecture: Competition or Synergy?. Ovidiu Noran, Peter Bernus. 12/ 11 /2008. - PowerPoint PPT Presentation

TRANSCRIPT

EI2N2008© O. Noran, P. Bernus 2008

Service Oriented Architecture vs.

Enterprise Architecture:

Competition or Synergy?

Ovidiu Noran, Peter Bernus

EI2N '08

Enterprise Integration, Interoperability and Networking

Session 3.2

12/11/2008

EI2N2008© O. Noran, P. Bernus 2008

Service Oriented Architecture (SOA) (the verb): aims to

structure the functionality of a business using the service

(packaged business functions with all necessary information)

and service consumer as base concepts.

Enterprise Architecture (EA) (the verb): aims to describe

enterprises and manage change so as to enhance consistency

and agility. No consensus on EA definition or artefacts either.

No agreement on SOA definition and on the types and

meaning of artefacts involved in its creation / maintenance.

EI2N2008© O. Noran, P. Bernus 2008

EA and SOA had their hype and disillusionment cycles.

SOA enthusiasts realised that just like EA, SOA must

encompass the entire organisation in order to achieve

anything positive. From a glorified Web Service paradigm,

SOA gradually started to ‘look and walk’ more like EA. So,

the question arose…

SOA hype occurred during the EA ‘downturn’ and is now

recovering from its own disillusionment trough.

EI2N2008© O. Noran, P. Bernus 2008

What can SOA be in respect to EA?

Many ‘solution providers’ argue in favour of 1. The sceptics

argue in favour of 2. We argue in favour of 3.

Some possible answers:

1. A parallel approach, probably even a successor

2. A fad

3. A type of and/or a component of EA

EI2N2008© O. Noran, P. Bernus 2008

Components of the argument (not complete but it’s a start):

1. Show that EA frameworks can contain, express and suitably classify typical SOA artefacts

2. Show that an SOA endeavour can be analysed and guided from an EA perspective and that this approach:

a) facilitates a coherent approach across business units

b) provides the premise for organisational culture change

The real benefit (as we see it):

… integrating the SOA initiative in the ongoing EA effort enables the lasting success of the project.

EI2N2008© O. Noran, P. Bernus 2008

The need for a framework permeates the SOA literature. Could

an (Enterprise) Architecture Framework (EAF) play the role of

an SOA framework?

Perhaps - if it can “…help create, organise, interpret and

analyse [service-oriented] architectural descriptions”

(ISO42010) containing all the relevant (SOA-specfic) artefacts.

In the following we have tried to map such ‘SOA-specific’

artefacts on an EAF and observed the results.

The framework chosen is the GERAM EAF

EI2N2008© O. Noran, P. Bernus 2008

EM

GERAGeneralisedReference

Architecture

EEMEnterprise

Engineering Methodology

EML

Enterprise Modelling Language

EET

Enterprise Engineering Tool

Enterprise Model

EOS

Enterprise Operational System

PEM

Partial Enterprise Model

GEMC

Generic Enterprise Modelling Concept

EMO

Enterprise MOdule

supports

used in

utilised in

implemented in

used to implement

used to build

define meaning of

The GERAM EAF: ISO15704:2005Amd1

Annex C

EI2N2008© O. Noran, P. Bernus 2008

EM

GERAGeneralisedReference

Architecture

EEMEnterprise

Engineering Methodology

EML

Enterprise Modelling Language

EET

Enterprise Engineering Tool

Enterprise Model

EOS

Enterprise Operational System

PEM

Partial Enterprise Model

GEMC

Generic Enterprise Modelling Concept

EMO

Enterprise MOdule

supports

used in

utilised in

implemented in

used to implement

used to build

define meaning of

OASIS Reference

model

Open Group SOA

Ontologies

MSOAM, OASIS SAB

SOAModels

SOA Trusted Components

SOA-PG Reference

Model

SOA-PG Reference

ArchitectureBPEL, BPMN...

SOATools

CBDI Metamodel

Linthicum metamodel

GERAM Boundary

Executable Services

OASIS Reference

Architecture

EM

GERAGeneralisedReference

Architecture

EEMEnterprise

Engineering Methodology

EML

Enterprise Modelling Language

EET

Enterprise Engineering Tool

Enterprise Model

EOS

Enterprise Operational System

PEM

Partial Enterprise Model

GEMC

Generic Enterprise Modelling Concept

EMO

Enterprise MOdule

supports

used in

utilised in

implemented in

used to implement

used to build

define meaning of

OASIS Reference

model

Open Group SOA

Ontologies

MSOAM, OASIS SAB

SOAModels

SOA Trusted Components

SOA-PG Reference

Model

SOA-PG Reference

ArchitectureBPEL, BPMN...

SOATools

CBDI Metamodel

Linthicum metamodel

GERAM Boundary

Executable Services

OASIS Reference

Architecture

EI2N2008© O. Noran, P. Bernus 2008

Management and Control

Product or Customer Service

HumanMachine

ResourceOrganisation

InformationFunction

GenericPartialParticular

HardwareSoftware

Life Cycle Phases

Views

Instantiation

Design

Arch. design

Detailed design

Identification

Concept

Implementation

Operation

Decommission

Requirements

GERA MF

EI2N2008© O. Noran, P. Bernus 2008

SOA-PG Life Cycle

IBM Life Cycle

C

D

Op

I

DD

AD

R

Id

MCS

C

D

Op

I

DD

AD

R

Id

MCS

OASIS Ref. Arch.

SOA-PG Ref.

Arch.

GERA MFPartial Level

GERA MFPartial Level

EI2N2008© O. Noran, P. Bernus 2008

F

SOA Project Partial Level

DD

MSOAMAD

R

I

Bell’s Fwk(FIRO)

O

F

SOA Project Partial Level

DD

AD

R

I

OASISSAB

OASIS RA

SOA-PG RA

SOA Team

(FO)

CEA3

Fwk(FIR)

RO

I

EI2N2008© O. Noran, P. Bernus 2008

HM

RO

IF

SOA Project Partial Level

DD

SOAVision

AD

R

I

Governance(Mgmt side)

C

MCS

C

D

Op

I

DD

AD

R

Id

MCS

‘ESB = Specification’

‘ESB = Architecture’

‘ESB = Middleware’

‘ESB = Web Services’

‘ESB = Policies’

QoS, SLA…

Possible ESB meanings along its

life cycle

SOA-PG Life Cycle

IBM Life Cycle

EI2N2008© O. Noran, P. Bernus 2008(Life cycle) Entity Model: simplified GERA

Management and Control

Cust Service C

Entity

D

Op

I

DD

PD

R

Id

MP

Simplify

Formalism usedin the Business Model

HumanMachine

Resource

InformationFunction

Particular level

HardwareSoftware

Design

Prelim. design

Detailed design

Identification

Concept

Implementation

Operation

Decommission

Requirements

Partial level of GERA ModellingFramework

Organisation

EI2N2008© O. Noran, P. Bernus 2008

SP

AS

BPMES: Bus. Process Mgmt & Exec Serv.

DS: Data Service

IS: Infrastructure Service

AS: Application Service

HQ: Headquarters

BU: Business Unit

SP : SOA Project-------------------------------

M: Management CS: Customer Service Id: Identification C: Concept developmentR: RequirementsAD: Architectural DesignDD: Detailed DesignI: ImplementationOp: OperationD: Decommissioning

D

OpI

DD

AD

R

C

Id

MCS

BU HQ

ISBPMES

BU

Simple Sample SOA Business Model

DS

EI2N2008© O. Noran, P. Bernus 2008

Conclusions:

• We were able to map the SOA artefacts investigated with

no (major) issues. The mapping has also provided insight

into the nature of some artefacts from an EA perspective.

• Employing a business model using EAF constructs has

helped identify the true environment of the SOA project

Further Work:

• Perform further mappings to validate the concept and

• Continue to promote the integration of the SOA efforts in

the ongoing EA initiative.

EI2N2008© O. Noran, P. Bernus 2008

THANK YOU

( Questions ? )

top related