Enterprise Architecture (EA) Service-Oriented Architecture (SOA) Web Services Architecture (WSA) NorStella SOA-seminar 30.05.2007

advertisement
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
Zachman Framework
VA Enterprise
Architecture
DATA
What
FUNCTI ON
How
NETW ORK
Where
PEOPLE
Who
TIME
When
MOTIVATION
Why
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 =
End =
Means =
DATA
What
FUNCTI ON
How
NETW ORK
Where
PEOPLE
Who
TIME
When
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)
Sub-Contractor
FUNCTIONING
ENTERPRISE
MOTIVATION
Why
ICT
19
Enterprise Unified Process (EUP)
ICT
20
Interoperability
ICT
21
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 of all systems
Enterprises (MPCE) and
provider of new solutions
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*
POP*enterprise
enterprisemodel
modelrepository
repository
Integration
Integration Services
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
OMG CORBA
SOAP, XML
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
ICT
51
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
ICT
53
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
ICT
58
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
Download