Jaap Schekkerman S O A Enterprise Arch S Tyle

This Presentation Courtesy of the
International SOA Symposium
October 7-8, 2008 Amsterdam Arena
www.soasymposium.com
info@soasymposium.com

Founding Sponsors

Platinum Sponsors

Gold Sponsors Silver Sponsors

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

© Logica / IFEAD 2001 - 2008. All rights reserved

© 2004 Capgemini - All rights reserved 1

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

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

About Jaap Schekkerman

President & Thought Leader, Institute For Enterprise Architecture Developments

Opinion Leader Enterprise Architecture, Logica Management Consulting

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

Some Statistics
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.



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

Services Orientation; an Enterprise Architectural Style


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

Realtime Implementation of Enterprise
Enterprise Architecture Architecture Function

Business Innovation,
Assessment of Enterprise
Strategic Planning & EA
Architecture Maturity

Portfolio Management & Developmement of
Enterprise Architecture Enterprise Enterprise Architectures
Architects

Compliancy & Enterprise Services Orientation as an
Architecture Enterprise Architecture style

Economic Value of Assessments of Enterprise
Enterprise Architecture Architectures



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...

Stakeholders Enabling
Enabling
Stakeholders Mission
Mission Context
Context

Vision
Vision

Strategy &
Strategy &
Business
Business Planning
Planning Technology
Technology
Value
Value
EA Program
EA Program
Goals &
Goals &
Enterprise
Enterprise Objectives
Objectives
Program Enterprise
Enterprise
Program
Management Architecture
Architecture
Management
Validation
Validation
Services
(Feedback loop)
(Feedback loop) Orientation
EA
EA
Budget
Budget Solution
Solution
Transformation
Transformation
Process
Process Architecture
Architecture
Programs
Programs

EA Measurement
EA Measurement


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

Enterprise Architecture Solution Architecture
Environment Environment

Business & IT
Strategy, Transition
Business Planning, SO
Domain Domain Processes /
Governance
Activities & Data,
Domain Business
SOE: Business Services, Business
Principles, Business Modeling
Services Portfolio, Workflow, BPMN
Semantics, Ontology,
Policy
Security Event
Services Services
Authorization Authentication

Integration and Transformation Services
Business Events External Events System Events

BPA Organization BAM

Services Financial Services Healthcare Insurance
Government Telco

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

Concepts / SO Reference Decision
ERP
Rule

Styles Architecture
SLA
Rich Media

+ ERP
QoS SLA
Decision
Performance
Monitoring

Rule
Inference
Situational Resolution

Technology Declarative
Network
Research
Forward / Backward chaining

Persistent
<<Business Entity>>
Klant

<<Data Type>>
Klant Gegevens
1

Klant
Heeft

<<Data Type>>
SO Gegevens
1 .. N

Contract
<< Business Entity>>
Pand

Aangaande

1 .. N

Service
Overeenkomsten

Periodiek Voorschot
1 .. N

Contract
<<Data Type>>
Pand Gegevens

Betreffende
1

Bedrijfsinstallaties
Partner
Contract

Betreffende

1


Betreffende
<<Data Type>>
Partner Contract
Gegevens

Heeft

<<Data Type>>
Gegevens

<<Data Type>>
Onderhoud
Gegevens
<<Business Entity>>
Partner
<<Data Type>>
Partner Gegevens

Domain Services Oriented
1 .. N

<< Business Entity>> << Business Entity>>

Object
Financiële Onderhoud Status
Administratie Bedrijfsinstallaties
Periodieke Verrekening

Voert Uit Onderhoud

<<Data Type>>
Financiële Gegevens

Models
Enterprise
Standards Rule Work DB
Repository



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

Product
Oriented
Process
Oriented
Services
Oriented Value
Oriented
Specific Generic Agile Inteligent
Agent
Services Oriented
(ERP, CRM, Oriented
Technology Style

etc.)
Packages
Application Oriented
Oriented

1990 - 2000 2001 - 2006 2007 – 2012? 2013?? (C) Copyrights IFEAD, 2001-2008
Source:


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

• A set of technologies Transfer, also known as REST,
Representational Statethat can be used with 2 design is
philosophies
a style of software architecture defined by a collection of
• Benefits to principles. REST
architectural both approaches is applied specifically to
• Large overlap systems as the Web,
such distributedin their capabilities and stipulates
• Useful for both communities to look at resources.
mechanisms for defining and accessing the benefits of
the other camp



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

Business and Customer Results
Achieves
Business Strategies
Aligns to and implements
Enterprise Business Activities / Processes
Specifies
Enterprise Business Requirements
Business
Drives
Capability Requirements & Profile
Drives Informs &
Enables Fulfills
Technology Services Provision Layer
Integrates and provides
Services Integration Layer
Leverages

Technology
Data/Information Applications Services
Components

Supports
Technology & Infrastructure
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


And.... What about Services Orientation?

Enterprise Architecture Framework

Why? With Who? What? How? With What? When?
• Don‟t bother your
management with these Business
architecture
buzzwords!
• But understand how they
are related to each other Services
Information
• You have to deal with these architecture Oriented
SPA SOE STP
buzzwords if you like or not!
Services Services
• Explain their impact in terms Services
Information Paradigm
- Oriented Transition
the business can Systems
Adoption
Enterprise SOA Plan
understand! architecture Services Service
SOC
Oriented Oriented
Architecture Service
Oriented
Technical Computing
architecture

Services Orientation is an Architectural Style of Enterprise Architecture

Based On Sources: Oasis, IFEAD



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

• Adopting the „Services paradigm‟ Why? With Who? What? How? With What? When?
requires a Services Oriented Reference
Business • Between Partners
Architecture architecture

• The “Services” in SOE are business • Between Businesses
Information
services architecture • Between Business processes / Activities
• Business Services connect Business • Between Business Services
Partners (Value Network) Information
Systems
architecture • Between Software Services
• Services are linked together to
implement business processes / Technical
• Between Service Components
activities architecture
• Between Network Services
• 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


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

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

Business
architecture Business
Business Outcome & Goals

agility requires Business Obligations
Semantics shared
Business Processes
Information understanding
architecture
and alignment Business Services

of: Business Semantics

Information Services
Systems
architecture SOA requires Message Format
shared
understanding Protocols
Technical
architecture and alignment Status (manageability)
of:
Ontology's Security

Joined up processes Common data infrastructure SO Reference Architecture
(C) OASIS, IFEAD, ZAPTHINK, OMG, W3C, 2008



But You have to Go to the Details to Understand.......
SO Reference Architecture
WS* / SOA Standards Business Concepts
Enterprise Business Modelling

SO Concepts / Styles Define Business Capabilities
Business Ontology Define Business Relationships
SO Principles Business Type model
Reference Environment Define Business policy

Service Portfolio Planning Model Business Semantics
Define Policies Model Business Capability
Capabilities
Identify Services Model Value Chains

Describe Services Business Value
Policies Chains
Publicize Portfolio Plan

Service Planned Service Descriptions
policies
Required Services Business Process Design
Model Business Process

Business
Service Provisioning Process Model

Specify a Service Solution Delivery
Design Software Solution
Acquire the Service
Operational Request Services and Operations
Certify, Deploy Service Services
Construct Software Solution
Publish Service in Catalog
Test Software Solution


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

• "There's a whole space emerging Dave Linthicum CEO of the Linthicum Group, LLC
among enterprise architects called and SOA Guru said:
ESB intermediation,". "They're finding “Call me crazy, but would it not make more sense to
that two or three different divisions of have a centralized plan as to what the SOA should
their company are using different be, based on the requirements of the business,
ESBs from different vendors. Yet versus people dashing out and shelling out the
dollars for an ESB for some one-off tactical reason,
they're trying to build business or more likely just acting out of reaction to the hype?
processes across these ESBs. But
the ESBs are designed to be their Now, you’re left with a dysfunctional mess that’s not
easily corrected, and clearly costly. …why the heck
own center of the universe. How do are you attempting to integrate these integration
you intermediate transactions across engines when they should perhaps be displaced
these ESBs?" altogether? Because, call me crazy again, that
would be cheaper.”



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 "The attitude is I'm so special I can't use this service
everyone else is using,". "I need my own thing."
– An "I'm special" attitude
Source: Burton Group, July 2008


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 SOACIOCost Curveboard
new IT coming on Over
Time
– 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
€ € Investments

– Well-defined Funding and Maintenance models that balance the needs of service
providers and consumers € € Costs
reduction
– A simplified architecture, making it easier to access and manage quality Compared to
data
– A Culture of trust between Business and IT Traditional
Approach

Requirements Maintenance
Gathering, Services Time
Year 0 Development & Year 5? Year 10?
Integration Source:
Investments
Source: Burton Group, July 2008



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.

Source: Thomas Erl, IFEAD


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.
Source: Thomas Erl, IFEAD



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


Thanks for your attention.....



Jaap Schekkerman S O A Enterprise Arch S Tyle

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

Destacado

Destacado (17)

Similar a Jaap Schekkerman S O A Enterprise Arch S Tyle

Similar a Jaap Schekkerman S O A Enterprise Arch S Tyle (20)

Más de SOA Symposium

Más de SOA Symposium (20)

Último

Último (20)

Jaap Schekkerman S O A Enterprise Arch S Tyle