soa - aligning business and it?

© 2005 IBM Corporation

Microsoft Arkitekt Forum

En dag med Service Orienteret Arkitektur platforme

SOA - Aligning Business and IT?

Ole RasmussenSenior IT Architect, Business ManagerIBM Global Business Services(+45) 2880 [email protected]

2 SOA - Aligning Business and IT? Ole Rasmussen, Microsoft Arkitekt Forum, May 2008

SOA: The Key to Business Flexibility



“Through 2010, the biggest barriers to SOA adoption will be non-technical issues related to inadequate governance, lack of clear value metrics, poorly defined requirements and scope, and insufficient business involvement in project prioritization and service identification.”

Predicts 2007: Application Strategy and Governance Emerge as Core IT Competencies, Gartner, November 2006



Do we all agree on the basics?Service-Oriented Architecture is an architectural style that supports service orientation - a way of thinking in terms of services and service-based development

The Service-Oriented Architecture architectural style has the following distinctive features It's based on the design of the services - which mirror real-world business activities comprising the enterprise (or inter-enterprise) business processes. Service representation uses business descriptions to provide context (i.e., business process, goal, rule, policy, service interface, and service component) and implements services using service orchestration. It places unique requirements on the infrastructure - it's recommended that implementations use open standards to realize interoperability and location transparency. Implementations are environment-specific - they're constrained or enabled by context and must be described in that context. It requires strong governance of service representation and implementation. It requires a "litmus test" that determines a "good service."

A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data) Is self-contained May be composed of other services Is a “black box” to consumers of the service

Open Group’s definition of SOA - http://www.opengroup.org/projects/soa/doc.tpl?gdid=10632



Your context influences your perception of SOA

A programming model complete with standards, tools, methods and technologies such as Web services

Capabilities that a business wants to expose as a set of services to clients and partner organizations

An architectural style that requires a service provider, requestor and a service description. It addresses characteristics such as loose coupling, reuse and simple and composite implementations

Implementation

Architecture

Business

OperationsA set of agreements among service requestors and service providers that specify the quality of service and identify key business and IT metrics



Core in a SOA based architecture is the services, but more is needed – convergence towards this layered model (“SOA Solution Stack”)

Data A

rchitecture & B

usiness Intelligence

QoS, Security, M

anagement &

Monitoring Infrastructure Service

Custom Application

Packaged Application


Custom Application

consumers

business processesprocess choreography

servicesatomic and composite

service components

operational systems

Service C

onsumer

Service P

rovider

OO Application

Portlet WSRP B2B Other Integration (Enterprise Service Bus approach)

Governance



Web Services can be a part of the answer ... but mostly we'll get to that later

Most of today's production Web Services systems aren't service oriented architectures - they're simple remote procedure calls or point-to-point messaging via SOAP or well structured integration architectures

Service Oriented Architecture is another partMost of today's production service oriented architectures don't primarily use Web Services - they use ftp, batch files, asynchronous messaging etc. - mature technologies

Web services = Standardization = Interoperability = Good

BOTH= Optimal

SOA = Componentization = Flexibility = Good

Is Web services part of the answer?



Everything is not services, and services are not everything! The SOA Solution Stack is an architectural view of the SOA building blocks. These are only a fraction of the architectural building blocks in the enterprise.

Data Architecture &

Business Intelligence

QoS, Security, M

anagement &

Monitoring Infrastructure

Service

Custom Application



Custom Application

consumers



service components

operational systems

Service C

onsumer

Service P

rovider

OO Application


Governance

Data Architecture &

Business Intelligence

QoS, Security, M

anagement &


Service

Custom Application



Custom Application

consumers



service components

operational systems

Service C

onsumer

Service P

rovider

OO Application


Governance

This is an application by itself composed of the “usual” components like user interface, business logic and data



1. Client requests application form2. Provider sends it3. Client fills it out and returns it4. Provider determines “yes” or “no” and sends it

back

1. Client calls provider2. Provider asks “How can I help?”3. Client: “I’d like a mortgage, please.”4. Provider: “What is your name?”5. Client: “Bond, James Bond”6. Provider: “What is your address?”7. Client: …8. …9. Provider: “Ok, your mortgage number is 42; I’ll post the details.”

By Post – the Service Style By Phone – the API Style

Service Like API Like Implications

Few, large grained interactions

Many small-grained interactions Provider and requestor can be more distant

Less overhead

Every interaction is the same

Every interaction is different Less complex to change if one aspect of the interaction must change

All requestors must accommodate the way the provider service works

Each interaction fulfills one step in a business process. There is no shared process (or state) at a lower level.

Many interactions to complete one step in a business process. Often much shared process (or state) in these interactions

Less complexity to understand or coordinate if the consumer or provider need to change

Process and state models need only agree at the level of shared business process

Anti-pattern: Chatty Services – decreasing flexibility and increasing complexity



I.e. we need a method aimed at enabling target business processes through the identification, specification and realization of business-aligned services that form the foundation of a SOA

A service is a logical representation of a repeatable business activity that has a specified outcome

Service-Oriented Architecture is based on the design of the services - which mirror real-world business activities comprising the enterprise (or inter-enterprise) business processes.

Service-oriented modeling is necessary to define a service-oriented architecture - just as OOAD is necessary to define object-oriented systems and component-based development is used to define component-based architectures

Data A

rchitecture & B


QoS, Security, M

anagement &


Service

Custom Application



Custom Application

consumers



service components

operational systems

Service C

onsumer

Service P

rovider

OO Application


Governance

Data A

rchitecture & B


QoS, Security, M

anagement &


Service

Custom Application



Custom Application

consumers



service components

operational systems

Service C

onsumer

Service P

rovider

OO Application


Governance

Process

DataService

Leading bad practice: Using use cases for service identification!



Be careful about modeling responsibilities – especially expectations for business people. We want to align business and IT, but have to acknowledge that understanding and creating models is complicated

Process

DataService

Business people can model processes, but typically do not bother with variances, compensation and low level details regarding data

Business people can model data on conceptual level, but typically gets into troubles modeling on the logical level.

Business people can identify services and describe them on “conceptual” level

Conceptual Logical Physical (XML)



Candidate Services

Business Alignment Composability

Externalized Service Description Redundancy Elimination

ServiceLitmusTest

Services (Exposed)

All business activities are not good services.We must distinguish between candidate and exposed services

SOA requires a "litmus test" that determines a "good service."

Remember: Deciding to promote a service has a price tag

– Modeling

– Infrastructure (in operations)

– Governance

Composability is defined as an attribute that enables the service to participate in a service composition

The service must be traceable back to a business task or goal or it may not yield benefits required for SOA implementation

The most basic property of a service is that it has an externalized service descriptionThe service must be usable

in all contexts where its function is required



We want to omit point-to-point interaction: Central in an SOA you find the Enterprise Service Bus – mediating the service consumer and the service provider

Who has what responsibility? Can you see performance challenges?

Provider Applications

Requester Applications

Requester SIP

Bus

Provider SIP

Mediation

Service Registry

Human Tasks

Existing Application

External Service

New Business Logic

Business Rules

Process Coordination

Interact

QoSMediate

MonitorMonitor CorrelateCorrelateDistributeDistributeRouteRouteTransformTransformProtocol Switch

Protocol Switch EnrichEnrich

Consider this in a multi-provider environment



“Effective IT Governance is the single most important predictor of value an organization generates from IT.”

MIT Sloan School of Mgmt.

SOA approach mandates strong governance …

BusinessOpportunity

TechnologyAvailability

Planning

Model & Assemble

Strategy

Deploy & Manage

BusinessStrategy

InformationTechnology

Strategy

ITArchitecture

Business Operating Environmentand IT Infrastructure

IT Solutions

BusinessArchitecture

Ente

rpris

e-w

ide

focu

s

Consistent Service Model

ReconcileMultiple

Viewpoints & Interests

The governance model defines: What has to be done? How is it done? Who has the authority to do it? How is it measured?

Actually“Inter-

enterprise”



Eating the SOA elephant is about planning your services and increasing your Service Orientation capabilities

Silo

Level 1

Services

Level 4

Composite Services

Level 5

VirtualizedServices

Level 6 Level 7

DynamicallyRe-Configurable

ServicesComponentized

Level 3

Integrated

Level 2

Modules Services Process Integration via Services

Dynamic Application AssemblyComponentsObjectsApplicationsApplications

Structured Analysis & Design

Service OrientedModeling

Service OrientedModeling

Grammar OrientedModeling

Component Based Development

Object OrientedModelingMethodsMethods

Function Oriented

ServiceOriented

ServiceOriented

ServiceOriented

Function Oriented

Function Oriented

Business View Business View ServiceOriented

Service Oriented Modeling

Process Integration via Services

Platform Specific

PlatformSpecific Technology Neutral

DynamicSense & Respond

PlatformSpecific

PlatformSpecificInfrastructureInfrastructure

Monolithic Architecture

Emerging SOA Grid Enabled SOA

Dynamically Re-Configurable Architecture

ComponentArchitectureLayered ArchitectureArchitectureArchitecture SOA

PlatformIndependent

Application Specific Skills Technology Adoption Cultural & behavioral

Transformation Human Service BusIT GovernanceIT TransformationGovernance & Organization

Organizational Transformation

Application specific data solution

LOB wide standardized Data

vocabularies

Flexible Data vocabularies for

expansion

Data vocabularies are Standards

based

Business Data can be shared outside

the Silo.

Data Subject Areas establishedInformationInformation

Enterprise wide standardized Data

vocabularies

Service Foundation Levels

Ope

n G

roup

Ser

vice

Inte

grat

ion

Mat

urity

Mod

el



SOA – Not a Silver Bullet

Essential Difficulties - the difficulties inherent in the nature of software

– Complexity

– Conformity

– Changeability

– Invisibility

Accidental Difficulties – only due to our (mis-) behavior

http://www-inst.eecs.berkeley.edu/~maratb/readings/NoSilverBullet.html

soa - aligning business and it?

Documents