Lecture at IT University of Copenhagen November 11, 2005 © 2005 IBM Corporation Being agile in the real world Experiences from an IBM’er Ole Rasmussen

Lecture at IT University of Copenhagen

November 11, 2005 © 2005 IBM Corporation

Being agile in the real worldExperiences from an IBM’er

Ole RasmussenSenior IT ArchitectBusiness Consulting [email protected]

2


Being agile in the real world | November 11, 2005 © 2005 IBM Corporation

A few words on me and the organisation I’m working in

Ms. Sc. in Computer Science at Aalborg University (Center), 1993 Bs. Sc. in Mathematics at Aalborg University (Center), 1990

Working for IBM since 1997– Business Consulting Services

– Senior IT Architect Teaching at Niels Brock since 1996

My context is “one of a kind” and “custom application” (partly) and for given customers

– Roles– Lead Architect, Solution architect, Reviewer, Designer, Method consultant, Teacher and

mentor

– Areas– Service oriented architecture, e-Business, Functional architecture, Object-oriented

analysis and design, Methodologies, Java, J2EE

– Industries– Public, Insurance, Distribution, Travel & Transportation, Communication

3



IBM’s is indeed based on matrixes

4



Services become increasingly important In $ billions (as reported)

■ Enterprise Investments/Other

■ Global Financing

■ Software

■ Hardware

■ Services

1998 2000 2002 2004

$28.9 $33.2$36.4

$46.2

$32.0

$34.5 $27.5

$31.2$11.9

$12.6$13.1

$15.1

$1.9$2.9

$1.4$3.5 $1.1

$3.2

$1.2$2.6

$77.5

$85.1$81.2

$96.3

5



IBM’s envision a lot of the business is driven by a BCS – the consulting business line within IGS

US

EM

EA

AP

AMS

ITS

SO

e-bHS

BCS

IBM Global Services

IBM Products& Technology

IBM Research

IBM Global Finansing

BusinessPartners

Client

IBM Sales& Distribution

ChannelPartners

BCS

6



Agenda

Lightweight versus heavyweight methodologies

Experiences with customers on agile engagements

My world of methodologies

Businesses are requiring agility – within the business

Patterns improve my “agility”

7



Agenda






8



Agile Methods: Principles and Characteristics

Principles

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Characteristics

Adaptive rather than predictive– lightweight not heavyweight

– can deal with requirements drift

People- rather than process-oriented– less document-oriented

Iterative development Development team

– empowerment of development team

– multi-skilled members in small teams (<= 6)

Customer Relations– contract price difficult to negotiate

– close business partnership & user contact required

Process Adaptation– product & process needs to be reviewed after each iteration

(and further adaptations made if needed)

– what went well? – what can be improved?– what have we learned?– what still puzzles us?

9



Agile Methods: Process Adaptation

development customerteam

project

process

projectiteration

review

applyadapt

10



Agile Methods: Applicability and Limitations

Applicability

Project environment– Unstable requirements able to be

delivered incrementally

– Suggests business systems rather than e.g. RT

Customer profile– Willing to engage in the development

process

– Different relationship with developers

Development teams– Smaller, motivated, highly skilled &

empowered to make technical decisions

Limitations

Distributed development environments

Subcontracting Building reusable artefacts Large team development Building safety-critical software Developing large, complex software

(Turk, D., France, R, & Rumpe, B., 2002)

11



Heavyweight methodology - Unified Process Overview

Unified Process is component based– system is built using software components interconnected using well defined interfaces

Unified Process uses Unified Modelling Language (UML)

Unified Process is distinguished by being– use-case driven

– architecture-centric

– iterative and incremental

Based around the 4Ps - People, Project, Product, Process

Provides disciplined approach to assigning tasks and responsibilities

Guide for how to use Unified Modelling Language (UML) effectively

Activities create and maintain (UML) models

Is a configurable process

Example

12



Heavyweight methodologies - main distinguishing characteristics

Use Case Driven

“A description of a set of sequence of actions, including variants, that a system performs that yields an observable result of value to a particular actor.”

(Jacobson et.al. 1999)

i.e. a piece of functionality that gives a user a result of value

Development process follows a flow• proceeds through a series of workflows derived from the use cases• use cases are specified, designed and are the source for test cases• they drive system architecture which in turn influences use case

selection• both mature as the development lifecycle continues

Architecture Centric

• Software architecture shows different views of the system being built and embodies the static & dynamic aspects of the system (design framework)

• Also influenced by the computer architecture, operating system, DBMS, network protocols etc.

• Related as function (use case) and form (architecture)

• The form must allow the system to evolve from initial development through future requirements (i.e. the design needs to be flexible)

• Key use cases influence the design of the architecture which may in turn influence development of other use cases

Iterative and Incremental

• Systems development is frequently a large undertaking - may be divided into several “mini-projects” each of which is an iteration resulting in incremental development of the system

• Iterations must be selected & developed in a planned way i.e. in a logical order - early iterations must offer utility to the users• iteration based on a group of use cases extending the usability of the system developed so far• iterations deal with the most important risks first• not all iterations are additive - some replace earlier “superficial” developments with a more sophisticated and detailed one.

Concepts of use case driven, architecture centric and iterative & incremental are of equal importance

13



Agenda






14



Applicability

Project environment– Unstable requirements able to be delivered

incrementally

– Suggests business systems rather than e.g. RT

Customer profile– Willing to engage in the development process

– Different relationship with developers

Development teams– Smaller, motivated, highly skilled &

empowered to make technical decisions

Limitations

Distributed development environments Subcontracting Building reusable artefacts Large team development Building safety-critical software Developing large, complex software

(Turk, D., France, R, & Rumpe, B., 2002)

The typical customer expects a contract with …

Huge scope Fixed deliverables Fixed price

Does this align with agile approaches?

15



Design your project to handle the nature of and uncertainties within the requirements

Requirements appearance – Part of tender => Not an agile approach

– Pre-analysis => mainly “paper work”; may include a proof-of-concept

– Elaborated during project => may become an agile approach – depends on customer willingness

Is your customer able to sign-off (an analysed version of) requirements? – The customer is uncertain about the correctness and completeness

– The customer can not envision the solution

– The customer do not want to be hindered in changing mind

Closing the “gaps” during the project

CustomerWorld

16

XXXWorld Service Platform – a logical overview

Application layer

Presentation layer

Multi-accessfunctionality

Syncron-isation

CachingContentfiltering

Personal-isation

Contentmanagement

Commerce Security

Access rightmanagement

CRM LocationPush

notifications

Streaming

SP Core

ASP

Service layer

Chat Instantmessaging

PIM(calendar,

Addresses)

Unifiedmessaging

Play Arcade Self-serviceMusic

SP Non-Core

E-mail

SMS/EMS

MCO PresentationPresentation layer

LanguageCurrency

conversionCaching

Contentfiltering

Service layer

MCOSpecificservice

MCO Services

MCOSpecificservice

MCOSpecificservice

MCOSpecificservice

XXXWorld Central MCO Local (Country)

Presentation layer

Service layer

Application layer

Back-endApplication layer

Settlement Data

WarehouseReportingCharging

3rd PartiesService layer

OIF adaptations

3rd party Specific service

3rd party specificservice


CC&B

NetworkElement(s)

PLMN3rd PartiesService layer

OIF adaptations


3rd party specificservice


XXX Integration Framework

MMS

My only project using an agile approach

17



The development approach was XP inspired

We faced two major problems The project was very large The customers customer (the countries) was not represented

in the development project

18



In most projects some agile “best practices” are applied

Proof-of-concepts (properly not originally agile;-) Iterative development (not originally agile;-)

Automated unit testing (Bi-) Nightly build, deployment and unit test

19



Agenda






20



I employ multiple methods to perform my work

Worldwide Project Management Method

SSM defines how we sell

products and services

WWQA/MD defines IBM

business controls

during the proposal and

project

WWPMM defines how we manage

a project

IGSM defines how

to design and deliver the solution

BCSRisk Management

21



The methodologies are integration throughout the sub-processes of the overall CRM process

22



IBM has a very comprehensive methodology for projects

15 1221 51515 2 3

Engagement Family

Engagement Model

WP WP

WP

WP

WPWP

WP

WP

Process Guidance

1

1.1

1.1.1

1.1.2

1.1.3

1.2.

1.2.1

Phase

Release

DeploymentBuildCycle

MicroDesignMacro Design

Solution Outline

Solution Close

Solution Startup

Initiate BuildCycle

PlanDeployment

Confirm BuildCycleBuild Event

Driven

Develop Support Materials

Prepare for Testing

Perform Programming Cycle

Perform Development Testing

ImplementUser

Experience

Perform System Testing

Activity

Task

OutlineArchitecture Model

Architecture Overview Diagram [architecture] Architectural Decisions [architecture] Architectural Templates [architecture] Operational Model [architecture] Component Model [architecture] Reference Architecture Fit Gap Analysis [architecture] Candidate Asset List[project management] Viability Assessment [architecture]


ƒ Develop Architecture Overviewƒ Survey Available Assetsƒ Identify Sterotypical Interactionsƒ Develop High Level Component Modelƒ Develop High Level Operations Modelƒ Refine Viability Assessment

Technique Papers

Work Product Descriptions

Operations

Architecture

Application

Organization

Business

Engagement

Domain

Dependency Diagram

dependencies to and from most other WPs

Use Case Model

UI Design Guidelines

UI Conceptual Model

Class Diagram

Non-functional Requirements

System Management

Plan

Deployment Unit Matrices

Deployment Units

Viability Assessment

Technical Prototype

SLC Analysis

Current I/T Infrastructure

Current I/T Standards

Architecture Overview Diagram

Reference Architecture

Fit/Gap Analysis

Architectural Decisions

Architectural Template

Software Distribution

Plan

Operational Model

Component Model

Roles

Capability Pattern

23



Work products define the pieces of work to be done in a project.

Tangible artifacts produced during the project – Models, reports, diagrams, plans, code and other documents which are direct "stepping stones" to the final

deliverable.

– Have a specific purpose in the engagement and describes specific content using a predefined semantics and syntax.

Produced as a result of performing one or more tasks.– Some tasks produce less tangible outputs (pass/fail, trained students) and are called "outcomes".

Not necessarily the same as a deliverable, it may be an intermediate product and not delivered to the customer.

– All deliverables consist of work products.

– Not all work products are deliverables.

Are the basis of intellectual capital reuse on engagements.– Examples of WPs from other engagements are an important form of IC

– Can structure some IC around WPDs

24



Work product types are the common building blocks of engagements

Work products form the basis of– Work plan development (project tailoring)

– Deliverables management

– Intellectual capital reuse

– Quality management

WP's enable resource sharing– People from different segments can work

together effectively on the same engagement.

– Resources can move to new segments without significant retraining.

25



Work product types have a 3-25+ page Work Product Description

A Work Product Description describes a type of work product.– Some WPDs have one instance per project e.g. Release Plan.

– Some have many instances per project e.g. Design Interaction Diagram

Work product description elements– Description

– Purpose

– Impact of NOT having the work product– Reason for not needing the work product

– Notation

– Example

– Development approach

– Validation and verification

– Advice and guidance

– References

– Estimation considerations

26



Within my domain (IT architecture) an description standard forms the basis for work products

27



Common work product descriptions provided by the methodology forms an excellent communication vehicle

Technical Transaction Map

Parametric Costs

Reference Architecture

Fit/Gap Analysis

dependencies to and from most other WPs

Use Case Model

UI Design GuidelinesUI Conceptual

Model

Class Diagram

IT Services Strategy

Deployment Units

Viability Assessment

Technical Prototype

Service Level Char. Analysis

Current IT Environment

Architecture Overview Diagram

Architectural Decisions

Architectural Template

Software Distribution Plan

Operational Model

Component Model

Change Cases

System Context Performance Model

Non-functional Requirements

Standards

- UML eases communication

28



Phases, activities and tasks structure the project – the engagement models provide “common” structures

Review Client Environment

Outline Solution Requirements

Assess Business

Impact

Outline SolutionStrategy

OutlineApplication

Model

Solution OutlineEvent Driven

OutlineArchitecture

Model

Confirm Solution Outline

Initiate Solution Outline

Solution Outline

MacroDesign

MicroDesign

BuildCycle

Deploy-ment

Macro Design

Build Cycle

Release

Micro Design

Solution Outline

Deployment


Architecture Overview Diagram [architecture]Architectural Decisions [architecture]Architectural Templates [architecture]Operational Model [architecture]Component Model [architecture]Reference Architecture Fit Gap Analysis [architecture]Candidate Asset List[project management]Viability Assessment [architecture]


Develop Architecture OverviewSurvey Available AssetsIdentify Sterotypical InteractionsDevelop High Level Component ModelDevelop High Level Operations ModelRefine Viability Assessment

Phases

Activities

Tasks

29



The large amount of engagement families and models reflects the broad spectrum of project that IBM engage

30



MAW

The Method

WW SDD Procedures

Tooling

Engagement participants

Project manager

Architect

Designer

Other selected participants

Method Exponent(s)

Expected MAW results

Trained participants

List of work products to be produced

Idea of project's process

Initial project plan

Project estimates

Risk Assessment

Resource Plan for the Team

A methodology always has to be designed for the specific situation. A Method Adoption Workshop (MAW) is used to bring the project and the method together

31



Agenda






32



‘On Demand Business is our way of describing a

fundamental shift in computing architecture and

how it is applied to business — a shift toward

integrated solutions and quantifiable business

value, not just technology features and

functions.’

A Time of Change

33



An On Demand Business is an enterprise

whose business processes — integrated

end-to-end across the company and with

key partners, suppliers and customers —

can respond with flexibility and speed to any

customer demand, market opportunity or

external threat.

The New Agenda

34



PredictivePredictive

VulnerableVulnerable

FixedFixed

DiffuseDiffuse

Client Pain Points From

Fusion of Business and IT

Fusion of Business and IT

Demand for best-in-classDemand for best-in-class

Standardization,commoditizationStandardization,commoditization

Selective sourcingSelective sourcing

Impact onServices Industry

Unpredictable ThreatsUnpredictable Threats

Unrelenting Financial Pressures

Unrelenting Financial Pressures

Rigorous CompetitionRigorous Competition

Continuous ChangeContinuous Change

Clients’ Needs and Expectations Are Changing

ResponsiveResponsive

ResilientResilient

VariableVariable

FocusedFocused

To

35


© Copyright IBM Corporation 2005Being agile in the real world | November 11, 2005

”a shift toward integrated solutions and quantifiable business value” mandates for business and IT alignment – Enterprise Architecture is key

BusinessStrategy

InformationTechnology

Strategy

BusinessOpportunity

TechnologyAvailability

BusinessArchitecture

ITArchitecture

- Processes- Information- People- Locations

- Applications- Data- Technology

Planning

Design andDelivery

En

terp

ris

e w

ide

fo

cu

sP

roje

ct

foc

us

Strategy

Business Operating Environmentand IT Infrastructure

IT Solutions

Enterprise Architecture

Transition Plan

Enterprise Architecture“the city plan”

System Architecture• functional aspects• operational aspects“the infrastructure and singlebuilding design”

Strategy and vision“Which city do we want to build?”

TheGap

The Great Divide

36



Drive down costeliminate duplicate systems, build once and leverage, improve time to market

Provide a flexible business model

react to market changes more quickly

Increase revenuecreate new routes to market, create new value from existing systems

Reduce cycle times and cost for external business

partnersmove from manual to

automated transactions, facilitate flexible dealings

with business partners

Integrate across the enterpriseintegrate historically separate systems, facilitate mergers and acquisitions of enterprises

Reduce risk and exposureimprove visibility into business operations

Each represents a SOA value proposition

Each represents a SOA value proposition

The pain points implies business challenges facing enterprises today – these challenges demand the fusion of business and IT

37



“SOA in context …”

– a set of services that a business wants to expose to their customers and partners, or other portions of the organization

– an architectural style which requires a service provider, requestor and a service description

– a set of architectural principles, patterns and criteria which address characteristics such as modularity, encapsulation, loose coupling, separation of concerns, reuse, composability and single implementation

– a programming model complete with standards, tools and technologies such as Web Services

Business

Architecture

Implementation

What is Service-Oriented Architecture ?

38



A Service-Oriented Architecture is an enterprise-scale IT architecture for linking resources on demand. These resources are represented as business-aligned services which can participate and be composed in a value-net, enterprise, or line of business to fulfill business needs. The primary structuring element for SOA applications is a service as opposed to subsystems, systems, or components.

A Service is a discoverable software resource which has a service description. The service description is available for searching, binding and invocation by a service consumer. The service description implementation is realized through a service provider who delivers quality of service requirements for the service consumer.

SOA and Services Defined

39



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

Service Oriented Architecture (SOA) is another part The two are not the same thing:

– 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

– Most of today's production service oriented architectures don't primarily use Web Services - they use ftp, batch files, asynchronous messaging etc. - mature technologies

Achieving the promoted benefits of SOA and Web Services, requires both SOA and Web services

Is Web services part of the answer?

40



An SOA is composed of multiple layers that decouple the provider and consumer views

service m

odeling

Da

ta A

rch

itec

ture

& B

us

ine

ss

Inte

llige

nc

e

Qo

S, S

ec

urity

, Ma

na

ge

me

nt &

Mo

nito

ring

Infra

stru

ctu

re S

erv

ice

Inte

gra

tion

(En

terp

rise

Se

rvic

e B

us

ap

pro

ac

h)

Custom Application

Packaged Application


Custom Application

consumers

business processesprocess choreography

servicesatomic and composite

service components

operational systems

Se

rvice C

on

sum

er

Se

rvice P

rovid

er

11

22

33

44

55 66 77 88

OO Application

Composite service

Atomic service

Registry

JService Portlet WSRP B2B Other

41



At the heart of SOMA is the identification and specification of services, components and flows

RealizationDecisions

Specification of Services, Components, Flows

Identification of candidate Services, Components, and Flows

<< Input from: Business Componentization/Analysis >>

<< Output to: SOA Implementation >>

Data A

rchitectu

re & B

usin

ess Intellig

ence

Qo

S, S

ecurity, M

anag

emen

t &M

on

itorin

g In

frastructu

re Service

Integ

ration

(En

terprise S

ervice Bu

s app

roach

)

Custom Application



Custom Application

consumers

business processesprocess choreography

servicesatomic and composite

enterprise components

operational systems

Service C

onsumer

Service P

rovider11

22

33

44

55 66 77 88

OO Applicatio

n

Composite serviceAtomic serviceRegistry

JService Portlet WSRP B2B Other

The role of Service Oriented Modeling and Architecture (SOMA) in SOA development is to provide a prescriptive technique for modeling (analysis and design) necessary to create a Service-Oriented Architecture with composable services

42



SOMA activities are grouped into three major steps: Identification, Specification and Realization

What we do

How we do it

The first major step in the SOMA process identify candidate services and enterprise components.

The second major step selects and specifies the services and enterprise components that will be exposed

The third major step captures realization decisions (concurrently with steps one and two)

Identification

Specification

Realization

RealizationDecisions

Specification of Services, Components, Flows

Identification of candidate Services, Components, and Flows

Domain Decomposition

SubsystemAnalysis Service

Specificationmessage & event

specification

component flowspecification

service flowspecification

Realization Decisions

Goal-ServiceModeling

Existing AssetAnalysis

Component Specification

informationspecification

service allocation to components

component layering

technical feasibility exploration

43



The Service Model captures information related to services and is built incrementally as SOMA activities are iteratively carried out

Service Hierarchy

Service Exposure

Service Dependencies

Service Composition

Service NFR

Service Messages

Realization Decisions

Service ModelService Model

Service Portfolio

State Management

Description SOMA step

Candidate services discovered during SOMA service identification activities.

Domain DecompositionGoal-Service ModelingExisting Asset Analysis

Candidate services organized using a business significant categorization scheme to make evaluation more manageable

Domain DecompositionGoal-Service ModelingExisting Asset Analysis

Decisions of why a given candidate service or group of services was exposed.

Service Specification:: Service Litmus Test Service Specification:: Exposure Decisions

Dependencies between services in the model. Service Specification:: Service Dependencies

Choreography of services to form a composite service.

Service Specification:: Service Composition Service Specification ::Flow

Non-functional requirements of the service. Service Specification:: Service Non-Functional Requirements

Messages that are exchanged between service consumer and service provider.

Service Specification:: Service Message Specification

Architectural decisions about service realization, such as buy, build, subscribe, etc.

Service and Component Realization

State management architectural decisions. Service Specification:: State Management Decisions

44



Governance is yet another key…IT and Operations align with Business

BusinessOpportunity

TechnologyAvailability

Planning

Model & Assemble

Strategy

Deploy & Manage

BusinessStrategy

InformationTechnology

Strategy

ITArchitecture

Business Operating Environmentand IT Infrastructure

IT Solutions

BusinessArchitecture

En

terp

rise

-wid

e fo

cus

Consistent Service Model

ReconcileMultiple

Viewpoints & Interests

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

MIT Sloan School of Mgmt.

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

45



SOA Reference ArchitectureSupporting your SOA Lifecycle

Business Innovation & Optimization Services

Dev

elo

pm

ent

Ser

vice

s

Integrated environment for design

and creation of solution

assets

Manage and secure services,

applications &

resources

Facilitates better decision-making with real-time business information

IT S

ervi

ceM

anag

emen

t

Infrastructure Services

Optimizes throughput, availability and performance

ESBFacilitates communication between services

Ap

ps

&

Info

As

setsPartner Services Business App Services Access Services

Connect with trading partners

Build on a robust, scaleable, and secure services environment

Facilitates interactions with existing information and application assets

Interaction Services Process Services Information Services

Enables collaboration between people,

processes & information

Orchestrate and automate business

processes

Manages diverse data and content in a

unified manner

46



The developer roles are changing in the SOA era

47



Agenda






48



Patterns prevail most of my efforts

Coding and design (the few times I get into these activities) Analysis – industry analysis models Business models Architectural patterns Reference architectures

49



The Service Component Compound Pattern – A Recommended Design

«aFacade»TheFacade

+ Operation1 ( )

«Mediator»FuncMediator

+ Operation11 ( )

«InternalFlow»MicroFlow

+ «steps» nextStep

+ «exec» doNextStep ( )

«factory»TheFactory

+ «creator» createCmp ( )«CompositeCmp»FunctionalCmp

+ «ruleMethod» checkX ( )+ Operation12 ( )

«ClassicDomainObject»ADomainObject

+ «ruleMethod» hasY ( )+ Operation13 ( )

«MediumGrainedCmp»aMediumGrainedCmp

«RuleObject»ARule

+ «condition» cond1 ( )+ «action» action1 ( )

«Adaptor»OutPutAdaptor

+ xlate ( )

«Adaptor»InputAdaptor

+ xlate ( )

«Mediator»TranslationRouter

«TechnicalCmp»ATechnicalCmp

«interface»AnInterface

+ Operation1 ( )

«Configuration»AProfile

1..*

0...

*

1..*

0...

*

0..1

0..1

1

0..1 0..1

0..1

1

Source: Ali Arsanjani, “Enterprise Component Pattern”, Pattern Languages of Programming 2001

FaçadeMediatorRule ObjectComposite[Factory][Adaptors]

50 © Copyright IBM Corporation 2004Being agile in the real world | November 11, 2005


Component Business Modelling is technique used to show the entire enterprise – and make analysis and decisions on the business

control

execute

direct Business Planning

Business Unit Tracking

Sales Management

Credit Assessment

Reconciliation

Compliance

Staff Appraisals

Relationship Management

Sector Management

Product Management

Production Administration

Product Fulfillment

Sales

Marketing Campaigns

Product Directory

Credit Administration

Customer Accounts

GeneralLedger

Document Management

Customer Dialogue

Contact Routing

StaffAdministration

BusinessAdministration

New Business Development

Relationship Management

Servicing & SalesProduct

FulfilmentFinancial Control and Accounting

Sector PlanningPortfolio Planning

Account Planning

Sales PlanningFulfilment Planning

Fulfilment Planning

A Business Component is a part of an enterprise that has the potential to operate independently, in the extreme as a separate company, or as part of another company.

Columns are Business Competencies, defined as large business areas with characteristic skills and capabilities, for example, product development or supply chain.

An Accountability Level characterises the scope and intent of activity and decision-making. The three levels used in CBM are Directing, Controlling and Executing.

Directing is about strategy, overall direction and policy.

Controlling is about monitoring, managing exceptions and tactical decision making

Executing is about doing the work

51



Architectural patterns are actually published by IBMwww.redbooks.ibm.com

52



The approach is strict an followed in all the patterns

53



Many of the Reference architectures provides huge amount of details (e.g. as work products)


Application and Data Access Services

Business Application and Data Services

Business Performance Management Services

Business Application

Services

ProcessServices

Information Services

Development Platform

Enterprise Applications and Data

Interaction Services

Partner Services

Enterprise Service Bus

IBM Business Integration Reference Architecture

54



The reference architectures provides models and - for some of them - work products to be used in engagements





Business App Services

Process Services Information Services



Interaction Services

Partner Services


Model

Comprehensive Services

Test

Choreography

Transactions

Staff

Federation

Replication

Transformation

Delivery

Experience

Resource

Community

Document

Protocol

Component

Interface

Core

Event Transport Mediation

Event Detect On-Ramp

Process Monitoring IT Monitoring

Design Implement

55









Partner Services


WebSphere BI Modeler WebSphere Studio

DB2 Information Integrator

WebSphere BI Server

WebSphere BIServer Foundation

WebSphere Portal Server

WebSphere BI Connect

WebSphere Application Server

WBI Adapters DB2 II ClassicHATS

WBI Monitor

Process Services Information ServicesInteraction Services

Business App Services

Web Services Gateway WBI Event/Message BrokerWebSphere MQ

IBM Software Offerings

… some of them even beyond a conceptual level

56



But patterns doesn’t really make me agile

Patterns express experience and ‘best practices’

Patterns make me and my solutions more flexible

Patterns make me and my solutions more robust

Patterns make me productive– Applying the pattern

– Comparing with the pattern

57



Overall – the customers are very seldom ready for agile approaches

... But we should be ready to suggest an agile approach

In other types of development organizations – e.g. internal development departments – agile approaches may be very suitable

58



Documents

Lecture at IT University of Copenhagen November 11, 2005 © 2005 IBM Corporation Being agile in the real world Experiences from an IBM’er Ole Rasmussen