Enterprise Architecture og SOA trender

Enterprise Architecture (EA)
Service-Oriented Architecture (SOA)
Web Services Architecture (WSA)
NorStella SOA-seminar 30.05.2007
Brian Elvesæter
brian.elvesater@sintef.no

ICT

1

Outline







What is an architecture?
Enterprise architecture and enterprise modelling
Interoperability
Enterprise architecture and SOA
Integration, SOA and Web services
References

ICT

2

What is an architecture?

ICT

3

Different kinds of architectures
Enterprise
architecture

Business
architecture

Conceptual
architecture

Integration
architecture
Architecture
framework
Knowledge
architecture
Serviceoriented
architecture

Realisation
architecture
Functional
architecture
ICT
architecture

Logical
architecture
Information
architecture
Web services
architecture

ICT

4

EA – SOA – WSA
 Enterprise architecture (EA) is the practice of applying a method for
describing a current and/or future structure and behaviour for an
organization's processes, information systems, personnel and organizational
sub-units, so that they align with the organization's core goals and strategic
direction.
 Holistic view of the enterprise and all its important assets.

 Service-oriented architecture (SOA) is a paradigm for organizing and
utilizing distributed capabilities that may be under the control of different
ownership domains. [OASIS 2006]
 Architectural style for designing (technical) systems.

 Web services architecture (WSA) intends to provide a common definition for
understanding Web services. A Web services architecture involves many
layered and interrelated technologies. [W3C 2004]
 A set of enabling Web technologies for implementing software systems.

ICT

5

IEEE Std 1471-2000
 IEEE Std 1471-2000
 IEEE Recommended Practice for Architectural Description of Software-

Intensive Systems
 Adopted September 2000

 Architecture definition
 Structure(s) of a system in terms of
 components,
 their externally visible properties,
 their relations,
 and the underlying principles

 Common frame of reference for architectural descriptions
 Common terminology
 architecture, architectural description, model, view, viewpoint, system,
stakeholder, concern, …

ICT

6

The fundamental organisation of a
system embodied in its components,
their relationships to each other and to
the environment, and the principles
guiding its design and evolution.

Mission
fulfills

influences

Environment

1..*
is important to

1..*

has

Stakeholder

identifies

used to cover

selects

Viewpoint

1..*

Those interests which pertain the
system’s development, operation
and other aspects that are critical
or otherwise important to one or
more stakeholders.

identifies

participates in

1..*
conforms to

organized by

1..*

View
participates in

has source

0..1

Library
viewpoint

Rationale

The expression of a
systems architecture
with respect to a
particular viewpoint.
Addresses one or more
of the concerns of the
system stakeholder.

Architectural
description

1..*

1..*

Concern

provides

Architecture

described by

1..*
is addressed to

1..*

has an

System

inhabits

Has interest in, or
concerns relative to
the system.

has

1..*

1..*

consists of

1..*

aggregates

1..*

Model

establishes methods for

1..*

ICT

Developed
using the
methods
established by
its viewpoint,
consisting of
views
expressing an
architectural
description.

7

Architecture of what and for whom?
Bus2

Bus3
Bus1

Virtual
enterprise

Bus4

Decomposition
Actor1

EA

Actor2
SW syst1

SW syst2

Business

Decomposition

SOA

Comp2

Software
system

Comp3
Comp1

Comp4

Decomposition

WSA

Object2

Software
component

Object3
Object1

Object4

Decomposition
Datatype2
Datatype1

Software
object

Operation1
Datatype3

ICT

8

Enterprise architecture and
enterprise modelling

ICT

9

History of enterprise architecture
 The major pioneering efforts:





Zachman Framework - initiated 1978
ARIS tool set - 1988
First Metis tool set - 1991
Troux Knowledge Repository - 2002

 Four major approaches:






Systems development case tools - 1984
IT process modelling - 1986
Product and process modelling - 1989
Business process management - 1995
Enterprise architecture modelling - 1997

ICT

10

Why enterprise architecture?

How can I
involve my people
in improving the
performance of the
business

?

?

How can I use best
practices to ensure
the success of the
business?

How can I
ensure that the IS
technology
helps the work of
my people?

?
ICT

11

Governance with enterprise architecture
 Architecture is a strategic tool
 not just high-level design
 Architecture goes beyond ICT
 Enterprise architecture is a key

component of the IT governance
process at any organization of
significant size.

 Stability and flexibility
 Seem to be contradictory, but a

good architecture facilitates
change!

 Communication with stakeholders
 architects, managers, customers,

engineers, …

 Analysis

 Enterprise Architecture (EA) is a
generic, abstracted and aggregated
representation of the core
structures and competences of an
enterprise.
 EA supports laying out the main
characteristics of the enterprise to
be analysed and agreed before
detailed technical design is started.
 It is shared and discussed
enterprise-wide between all
stakeholders as a common
description forms, functions and
features, components, properties
and relationships.

 impact-of-change
 cost and performance

ICT

12

Role of enterprise architecture
Mission
Vision

Strategy

Goals

as is
enterprise architecture

Actions

to be
culture
leadership

domain/aspect
architectures

products

processes

people

Operations
…

people

IT

Mark Lankhorst et al., "Enterprise Architecture at Work: Modelling,
Communication and Analysis", Springer, 2005, ISBN: 978-3-540-24371-7.
ICT

13

Describing coherence
Information architecture

Product architecture

?
Process architecture

?
?
?
Application architecture

Technical architecture

?

Mark Lankhorst et al., "Enterprise Architecture at Work: Modelling,
Communication and Analysis", Springer, 2005, ISBN: 978-3-540-24371-7.
ICT

14

Enterprise modelling
 Enterprise modelling (EM) is a
capability for externalising,
making and sharing enterprise
knowledge.
 EM tools can either be:
 used stand-alone to produce

various kinds of model views,
 integrated as front-ends to
other systems,
 part of an environment
providing a contextual userenvironment.

ICT

15

Enterprise modelling languages
 Enterprise modelling languages
should allow building the model of
an enterprise according to various
points of view such as: function,
process decision, economic, etc. in
an integrated way.
 Languages defined at high level of
abstraction as constructs for EM
are independent of the technology
of implementation

 Examples are:
 IEM
 Metis Enterprise Arcitecture












Framework (MEAF)
CIMOSA
GRAI
IDEF
PSL
WPDL
XPDL
BPML
EDOC
BPDM
EPC
Archimate

ICT

16

Enterprise architecture frameworks
 Enterprises architecture
frameworks are fundamental
structures which allows defining the
main sets of concepts to model and
to build an enterprise.
 Architectural frameworks are
designed to define views of specific
enterprise domains.
 Frameworks lack capabilities for

 Examples are:









 meta-data management



 role-driven viewing



 integration with platforms



ZACHMAN
GERAM
GRAI
ARIS
CIMOSA
DoDAF
TOGAF
TEAF
Troux/Metis/AKM
ISO 15745
MISSION

 model-driven design
 generation of interoperable

solutions

ICT

17

Representations of architecture

ARIS

ZACHMAN

GERAM

EKA POPS

EN/ISO 19439
NIST

ATHENA

ICT

18

VA Enterprise
Architecture

DATA
What

FUNCTI ON
How

NETW ORK
Where

PEOPLE
Who

TIME
When

MOTIVATION
Why

Zachman Framework

SCOPE
(CONTEXTUAL)

Things Im portant
to the Business

Processes
Performed

Business
locations

Important
Organiz ations

Ev ents Significant
to the Business

Business Goals
and Strategy

Planner

Entity = Class of
Business Thing

Function = Class of
Business Process

Node = Major
Business Locations

People = Major
Organiz ations

Time = Major
Business Event

Ends/Means =
Major Business Goals

ENTERPRISE
MODEL
(CONCEPTU AL)

Semantic Model

Business Process
Model

Business Logistic s
System

Work Flow Model

Master Schedule

Business Plan

Owner

Ent = Business Entity
Proc = Business Process
Rel = Business Relationship I/O = Business Resources

Node = Business Location People = Organization Unit Time = Business Event
Link = Business Linkage
Work = Work Product
Cycle = Business Cycle

End = Business Objectiv e
Means = Business Strategy

SYSTEM MODEL
(LOGICAL)

Logical Data
Model

Application
Architecture

Distributed System
Architecture

Processing
Structure

Business Rule
Model

Designer

Ent = Data Entity
Rel = Data Relationship

Proc = Application Function Node = IS Function
People = Role
I/O = User Views
Link = Line Characteristic s Work = Deliv erable

Time = System Event
Cycle = Processing Cycle

End = Structural Assertion
Means = Action Assertion

TECHNOLOGY
MODEL
(PHYSICAL)

Physical Data
Model

System
Design

Control
Structure

Rule
Design

Builder

Ent = Segment/Table
Rel = Pointer/Key

Proc = Computer Function Node = Hardware/Softw are People = User
I/O = Data Elements /Sets Link = Line Specifications Work = Screen Format

End = Condition
Time = Ex ecute
Cycle = Component Cycle Means = Action

Program

Security
Architecture

Timing
Definition

Rule
Design

Data
DETAILED
REPRESENTATIONS Definition
(OUT-OF-CONTE XT)

Technology
Architecture

Netw ork
Architecture

Human Interface
Architecture

Presentation
Architecture

Sub-Contractor

Ent = Field
Rel = Address

Proc = Language Statement Node = Addresses
I/O = Control Block
Link = Protocols

People = Identity
Work = Job

Time = Interrupt
Cycle = Machine Cycle

End = Sub-Condition
Means = Step

FUNCTIONING
ENTERPRISE

Data

Function

Netw ork

Organiz ation

Schedule

Strategy

Ent =
Rel =

Proc =
I/O =

Node =
Link =

People =
Work =

Time =
Cycle =

Based on work by
John A. Zachman
SCOPE
(CONTEXTUAL)

Planner
ENTERPRISE
MODEL
(CONCEPTU AL)
Owner
SYSTEM MODEL
(LOGICAL)

Designer
TECHNOLOGY
MODEL
(PHYSICAL)
Builder
DETAILED
REPRESENTATIONS
(OUT-OF-CONTE XT)

End =
Means =

DATA
What

FUNCTI ON
How

NETW ORK
Where

PEOPLE
Who

TIME
When

Sub-Contractor
FUNCTIONING
ENTERPRISE

MOTIVATION
Why

ICT

19

Enterprise Unified Process (EUP)

ICT

20

Interoperability research



Project type:

Network of Excellence

(NoE)




Web page:









Web page:



Interoperability Research
for Networked Enterprises
Applications and Software
Project duration: 3 years
Project budget: 12.0 M€
EU IST funding: 6.5 M€
Partners/contractors: 50
Start date: Nov 1, 2003



Integrated Project (IP)
Full title: Advanced Technologies for
Interoperability of Heterogeneous
Enterprise Networks and their
Applications
Project duration: 3 years
Project budget: 26.5 M€
EU IST funding: 14.4 M€
Partners/contractors: 19
Start date: Febr. 1, 2004



Full title:

www.interop-noe.org






Project type:

www.athena-ip.org

ICT

22

Rationale for interoperability
 Interoperability is the key to increase competitiveness of enterprises.
 “Enterprise systems and applications need to be interoperable to achieve
seamless operational and business interaction, and create networked
organizations” – European Group for Research on Interoperability, 2002

Application integration license revenue

System implementation budget
Misc.
20%

B$

Integration
40%

Hardware
10%
Imp.
Services
20%

Software
10%

The cost of non-interoperability are estimated to

(Source: the Yankee Group 2001)

40% of enterprises IT budget.

ICT

23

Knowledge integration
 The originality of the projects are to take a multidisciplinary approach by
merging three research areas supporting the development of Interoperability of
Enterprise Applications and Software:


Architecture & Platforms: to provide implementation frameworks,
 Enterprise Modelling: to define Interoperability requirements and to support solution
implementation,
 Ontology: to identify Interoperability semantics in the enterprise.

Architectures
&
Platforms

ATHENA
&
INTEROP
Enterprise
Modelling

Ontology

ICT

24

4-layered view of an enterprise
Business Operational Architecture
Operations

Strategy

Governance

Laws, rules,
principles

Agreed norms
and practices

Procedures
and routines

Business terms

Enterprise
methodology

Enterprise
models

Enterprise
templates

Metamodels
and languages

Product
models

Reference
architectures

Semantics

Enterprise Knowledge Architecture (EKA)
Dictionaries
Ontologies
Nomenclatures
Classifications

Information and Communication Technology (ICT) Architecture
Business and
user services

Infrastructure
services

EKA services

Ontology
tools

Software
platforms

Modeling
tools

Management
tools

Ontology
services

ICT

25

Holistic approach to interoperability
Enterprise A

Enterprise B

Application
ICT

Knowledge
Application
Data

Data

Semantics

Knowledge

Business
Semantics

Business

Interoperability (def.) is “the
ability of two or more systems
or components to exchange
information and to use the
information that has been
exchanged” – IEEE Standard
Computer Dictionary

Communication
To achieve meaningful interoperability between enterprises, interoperability must be achieved on
all layers:
 Business layer: business environment and business processes
 Knowledge layer: organisational roles, skills and competencies of employees and knowledge
assets
 ICT layer: applications, data and communication components
 Semantics: support mutual understanding on all layers

ICT

26

Enterprise architecture and SOA

ICT

27

Motivation for SOA
Enterprise

ICT

 Challenges
 Business agility
 Flexibility and adaptability
 Enterprise architecture frameworks
+ Holistic approach
+ Different views of an enterprise as
related (visual) knowledge models
- Current enterprise architectures are
only blueprints

 Challenges
 Inflexible and difficult to adapt
 Enterprise application integration
(EAI)
 Service-oriented architecture (SOA)
+ Architectural style
+ Loosely coupled systems
+ Horizontal integration between
different business domains
+ Use case oriented service
composition
+/- Web services (enabling technology)

Requirements
 Enterprises require operational
enterprise architectures
 ICT solutions must be designed to be
inherently interoperable

ICT

28

Business and technology alignment
 Business
 Services can be seen as business








capabilities that support the
enterprise.
Services usually represent a
business function or domain.
Services provide the ‘units of
business’ that represent value
propositions within a value chain or
within business processes.
Traceability between the service as
a business capability and its
technical implementation.
Services will improve delivery
methods that are an integral part of
the business product.

 Technology





Modular design
Compositions and granularity
Services are loosely coupled
From compile-time and
deployment-time dependencies to
run-time dependencies
 Dynamic discovery and binding
 Services are standardized
(“platform independent”)
 Standard Internet and Web
protocols as the common “glue” to
provide “syntactical interoperability”

ICT

29

Problems with current EA frameworks
 User's problems
 A lot of enterprise architecture proposals on the "market"
 However, it is usually difficult to understand, compare and choose

 Researcher's problems
 There is no justification, nor evaluation of existing enterprise architectures
 No adequate architecture representation language, too many different views and

levels of detail
 Confusing notions between Enterprise Architecture, Enterprise Model, Enterprise
Infrastructure
 Lack of standardized terminology and collaboration between different EA
communities (system engineers, software engineering,…)

 Engineer's problems
 There is no "architecture continuity", it is difficult to transform an architecture from

conceptual to implementation levels, and vice versa
 There is no "architecture interoperability", enterprise applications built on different
architectures are not interoperable
 There is no scientific "architecture principles" like we have in the construction or
shipbuilding domains, enterprise architecting is still a matter of experience

ICT

30

ATHENA's approach to operational EA
 EA is the holistic expression of the enterprise’s key business
knowledge, information, application and technology strategies and
their impact on business functions and processes, that:
 Guides investment strategies and decisions
 Provides the framework needed to innovate the business
 Consists of the current targeted Enterprise Knowledge Models (EKMs):
 EBA: Enterprise Business Architecture
 EKA: Enterprise Knowledge Architecture
 EIA: Enterprise information Architecture
 EAA: Enterprise Application Architecture
 ETA: Enterprise Technology Architecture
 Oversees integration across the core architectures that provides a

synchronized set of EA artefacts that needs to be created, collected,
organized and communicated to enable adaptation to change business
and technology
 Is defined and deployed through the company-wide process councils

ICT

31

Enterprise architecture viewpoints
Enterprise
Business
Architecture
(EBA)

Integrates Across
EBA,EKA,EIA, EAA

Business Processes
• Information Flows (between
processes)
• People, Teams, RAA
• Business Policy & Strategy

Enterprise
Knowledge
Architecture
(EKA)

Business Information
• Information Policy & Strategy

Enterprise
Application &
Architecture
(EAA)

Applications
• Application Data
• Data Flows (between Apps)
• Application Policy & Strategy

(EA)

Enterprise
Technical
Architecture
(ETA)

IT Platform and Infrastructure
• Hardware & OS
• SW Services & Middleware
• Productivity Apps.
• Technical Policy & Strategy
ICT

32

From EM to Enterprise Visual Scenes
(EVS)
 Utilizing the powers of visual
enterprise knowledge scenes
 Redefining Enterprise
Knowledge Modelling
 EM is externalizing and sharing
enterprise knowledge,
developing the enterprise
knowledge architecture and
enabling EVS.
 EKM is extending EM by
Intelligent Infrastructure and
knowledge architectures to
support continuous enterprise
architecting, business
management and more.

Four types of
views: meta.data, content,
functional and
context.

Different kinds
of views to
support
process roles.

Many kinds
of diagrams

Views have
their specific
view styles, and
dependencies.

Views can
also be turned
into and be
models

ICT

33

ICT
34

Visual enterprise
architecture management

Enterprise architecture layers –
Integrated by intelligent infrastructures
Inter-related reflective views of key roles – replacing frameworks as mosaics of static
kinds and types of views (the knowledge legacy from paper carriers)
Layers, aspects:
Business layer:
Methods, models,
operations, strategy,
governance, …
Enterprise Knowledge
Architecture (EKA) layer:
POPS methods, EIS
templates, UEML +++

ICT architecture layer:
Services as reusable
tasks, servers and EKM
repositories

Logic and content:
Law, rules, principles, agreed
practices and norms, day to
day routines

EKAPOPS

User views (types and kinds),
Enterprise-models and submodels, Meta-models:
Languages, Structures and
Type-hierarchies

Access services, capabilities to
integrate legacy systems,
extract data, handle
parameterised sub-models

ICT

35

POP* dimensions
The Process Dimension includes constructs
related to activities, tasks and processes going
on in the enterprise or between enterprises.

The Organisation Dimension focuses on
organisational structures, as well as members
and positions thereof. Also, focus is set on
interaction between structures, both as a whole
and between members.

The Decision Dimension is concerned with
the collection of concepts and constructs that
allow describing the decision-making structure
in terms of decision centres and decision
activities.

The Product Dimension is used to model
product architectures or product structures, for
the purpose of design, development and
engineering or product data management.

The purpose of the Infrastructure Dimension
is to support modelling of infrastructures and
the services they provide.

ICT

36

Mutually reflective views
 An object in one view will
have reflections in other
dimensions

Process

 No orthogonal, layered

meta-hierarchy
 No difference between
modelling and
metamodelling

 View connections and
dependencies are designed
or automatically created
 Types and kinds of views for
each design role
 A content view for role A may
be a definition view or
functional view for role B

Complex
relationships,
tasks,
decisions

Product

ICT

37

Enterprise knowledge spaces

Enterprise
Knowledge
Spaces
(EKSs)
are
externalised
knowledge
spaces of four or more
knowledge dimensions that
contain mutual and complex
dependencies of domains and
elements
in
the
four
dimensions.

ICT

38

Modelling Platform for Collaborative
The integrator
systems
Enterprises (MPCE) and provider ofof all solutions
new
Model-designed and
generated working
environments supporting
concurrent design,
planning and execution.

Model-generated workplaces
with business and user services

Modelling tools
Administration
Modelling support services
Services
Modelling support
Administration services
services

Repository management
services
services

.

POP* enterprise model repository
POP* enterprise model repository
Integration Services
Integration Services

The ICT infrastructure is
a platform of software
component services.

Enterprises’ ICT infrastructures
ICT

39

Model-designed and generated Workplaces
Modelling clients

Client

Roles, users, pages, permissions, projects

Storage

Server

Menus
Navigation

Modules with Web UI
- Page editor & runtime
- Dynamic forms ed. & runtime
- Problem tracker
- Document uploader
- Simple EKA text browser

POP* metamodel

New Models

MPCE Web Services
-update users, projects, roles,
-update dynamic forms etc
-load, save EKA etc

MPCE Server (non-UI) modules
-Permissions, users, groups, roles
-Projects, portals, menus, navigation
-File storage and retrieval
-Model transformation services
-EKA load, save, merge, etc

MPCE Storage
- with models as
EKA structures
-files
-internal MPCE
data as models

Reference models as
EKA structures

Web Service Enactment
-call other systems
-return results for viewing

File
Repository
(Blobs)

EKA Object
repository

ICT

40

Integration, SOA and Web
services

ICT

41

The waves of client/server technology

First
Wave

Second
Wave

Third
Wave

Fourth
Wave

Fifth
Wave

MDA, Web
Services, .Net
Server-side
Distributed
Service-oriented
componentsc
Objects
Architecture
J2EE/EJB SOAP, XML
OMG CORBA
COM+
COM/OLE
WSDL/WSFL
Corba Comp
Web/Internett
Agents, P2P
Java

File
Servers

FIPA

1982

1986

1990

1994

Grid

1998 1999 2000 2001 2002 2003

Base Source: Client/Server Survival Guide, 1994
Robert Orfali, Dan Harkey
OS/2 Edition, VNR Computer library + AJB update 2004

ICT

42

Web service
 Web service
 “Applications identified by a URI, whose interfaces and bindings

are capable of being defined, described and discovered as XML
artefacts. A Web service supports direct interactions with other
software agents using XML-based messages exchanged via
Internet-based protocols.” (W3C)


http://www.w3.org/

 SOA ~ architectural style
 Web services stack ~ technology/protocol standards
 SOA =/= Web services

ICT

43

Web services architecture
 Web services can
be used to
implement serviceoriented solutions
 They adhere to the
set of roles and
operations
specified by the
service oriented
model.
 They have also
managed to
establish a
standardized
protocol stack.

ICT

44

WS-* stack to-be
 Simplified version of the to-be WS-* stack
 Families of related specs not expanded
 Competing spec families not shown
 “Historical” or abandoned specs not shown
WS-Addressing
WS-Notification
WSDL

SOAP
WS-Coordination
XML
WS-Security

BPEL

WS-CDL

WS-Federation

UDDI

WS-Policy

WS-ReliableMessaging
WS-MetadataExchange
WS-Resource

WS-Transfer

ICT

45

WS-* stack as-is
 Complete version of the as-is WS-* stack
 The 3 widely-accepted specs today are the same as 5 years ago
 BPEL and WS-Security is gaining momentum
 Orchestration, discovery and brokering do not exist in today’s world

WS-Addressing
WS-Notification
WSDL

SOAP
WS-Coordination
XML
WS-Security

BPEL

WS-CDL

WS-Federation

UDDI

WS-Policy

WS-ReliableMessaging
WS-MetadataExchange
WS-Resource

WS-Transfer

ICT

46

Application architecture vs. SOA

Segmented business areas
a

Collaborative business areas

b

c
SOA

r

x

s

x

y1
y2
Application architecture

r

a

y

s

b

y

t

c

z

t

z

a

r
b

x

t

c
s

z

z
y

Service-oriented architecture (SOA)

ICT

47

SOA and integration
 Fundamental change for integration: X <-> Y
 Pre-SOA: outside, after development
 Post-SOA: inside, integral part of development / computational model

 Consequences
 How should integration be done?
 Innovation and experience
 Competition, expansion, consolidation

 Not understood:
 IDC Directions 2006 (3/2/06): SOA important but not understood or

deployed as claimed
 Gartner (2/15/06): “Globally, organizations placing minor emphasis on
understanding the role of data integration in SOA and creation of data
services at the foundation of their architectures”

ICT

48

History of integration
 1950 – 2006: Integration = develop then integrate
 1950s-1970s: Simple, manual integration
 1970s-1980s: Distributed Computing
 Applications (interoperation)
 Databases (integrate)

 1990s: Business Driven Integration – concepts, technologies, and
tools – increased automation, internet-based computing
 Concepts: Workflows, Processes, Web,
 Integration solutions blossom (diverge): ETL, EAI, BPM, …

 2000: SOA Emerges
 2000: Web services
 2003: Integration solution evolution accelerates, vendor chaos ensues
 2005: Growth in all integration categories

ICT

49

Integration in SOA
 2006 – 2012: Integration = dominant programming model
 2001-2010: Wrapping
 2005-2010: Re-Engineering
 2006-2008: Consolidation
 2006-2008: Research on Semantic SOA
 2007-2012: Emergence of SOA Platforms and Solutions
 2006-2012: Problem Solving Era: IT/integration relegated to low

level function

ICT

50

SOA platform consolidation
 Data and information integration ➪ Information Fabric
 EII: Enterprise information integration
 ETL: Extract, transform and load

 Application integration ➪ Integration Suite
 EAI: Enterprise application integration
 B2Bg: Business-to-business gateway
 ESB: Enterprise service bus

 Applications and Processes ➪ Business Process Management
Suite
 BPM: Business process management
 B2Bi: Business-to-business integration

 Enterprise workplace ➪ Interaction Platform

ICT

52

Integration suite services

 Goal: Composite applications
 Components: EAI, BPM, B2B, B2Bi
 Extensions: Adapter, collaboration, analysis, reporting, development,
monitoring, contracts, SOA standards, …
ICT

54

Business process management suite
& interaction services

 Goal: Continuous process improvement
 Components: BPM



human-centric: people-intensive processes
Integration-centric: system-intensive processes

ICT

55

Information fabric services

 Goal: Holistic view of data (information virtualisation)
 Components: DBMS, EII + ETL + replication
 Extensions: Distributed meta-data repository, distributed data access,
integrated data management
ICT

56

Trends
 Consolidation ➪ comprehensive platforms
 Merging of Human Workflow and System
Orchestration/Process services
 Integration of Business Rules Engines
 Support for Event Notification services (publish and
subscribe)
 Integration of Model-generated workplaces and role/taskoriented user interfaces, user interaction services, portals,
and multi-device interfaces
 Explicit use of models (Enterprise and System)
 Enterprise architecture + SOA

ICT

57

References
[ATHENA] ATHENA, "ATHENA Home Page", ATHENA IP. http://www.athena-ip.org/
[DnD] DnD, "Faggruppen for applikasjonsintegrasjon – metoder og arkitektur", Den norske dataforening
(DnD). http://www.dnd.no/
[Elvesæter, et al. 2005] B. Elvesæter, R. K. Rolfsen, F. Lillehagen, and D. Karlsen, "Integrated
Enterprise Service Architecture", in Proc. of the 12th ISPE International Conference on Concurrent
Engineering (CE 2005), Fort Worth, Texas, USA, 2005, M. Sobolewski and P. Ghodous (Eds.),
International Society for Productivity Enhancement, Inc., NY, USA, pp. 129-134.
[INTEROP] INTEROP, "INTEROP Home Page", INTEROP NoE. http://www.interop-noe.org/
[Lillehagen, et al. 2005] F. Lillehagen, D. Karlsen, H. G. Solheim, H. D. Jørgensen, H. Smith-Meyer, B.
Elvesæter, and R. K. Rolfsen, "Enterprise Architecture - from Blueprints to Design Services", in Proc.
of the 12th ISPE International Conference on Concurrent Engineering (CE 2005), Fort Worth, Texas,
USA, 2005, M. Sobolewski and P. Ghodous (Eds.), International Society for Productivity
Enhancement, Inc., NY, USA, pp. 121-128.
[NESSI] NESSI, "Networked European Software & Services Iniative (NESSI)". http://www.nessieurope.eu/Nessi/
[OASIS 2006] OASIS, "Reference Model for Service Oriented Architecture 1.0", OASIS, OASIS
Standard, 12 October 2006. http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf
[W3C 2004] W3C, "Web Services Architecture", World Wide Web Consortium (W3C), W3C Working
Group Note, 11 February 2004. http://www.w3.org/TR/ws-arch/

ICT

59

Enterprise Architecture og SOA trender

More Related Content

What's hot (20)

Viewers also liked (10)

Similar to Enterprise Architecture og SOA trender (20)

More from Brian Elvesæter (18)

Recently uploaded (20)

Enterprise Architecture og SOA trender