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 world Experiences from an IBM’er Ole Rasmussen Senior IT Architect Business Consulting Services ora@dk.ibm.com

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 2 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

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 4 Services become increasingly important In $ billions (as reported) ■ Enterprise Investments/Other ■ Global Financing ■ Software ■ Hardware ■ Services 1998200020022004 $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

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 5 IBM’s envision a lot of the business is driven by a BCS – the consulting business line within IGS USEMEAAP AMS ITS SO e-bHS BCS IBM Global Services IBM Products & Technology IBM Research IBM Global Finansing Business Partners Client IBM Sales & Distribution Channel Partners BCS

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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”

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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?

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 9 Agile Methods: Process Adaptation development customer team project process project iteration review apply adapt

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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)

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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?

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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-access functionality Syncron- isation Caching Content filtering Personal- isation Content management CommerceSecurity Access right management CRMLocation Push notifications Streaming SP Core ASP Service layer ChatInstant messaging PIM (calendar, Addresses) Unified messaging Play Arcade Self-service Music SP Non-Core E-mail SMS/EMS MCO Presentation Presentation layer Language Currency conversion Caching Content filtering Service layer MCO Specific service MCO Services MCO Specific service MCO Specific service MCO Specific service XXXWorld Central MCO Local (Country) Presentation layer Service layer Application layer Back-end Application layer Settlement Data Warehouse Reporting Charging 3 rd Parties Service layer OIF adaptations 3rd party Specific service 3rd party specific service 3rd party Specific service CC&B Network Element(s) PLMN 3 rd Parties Service layer OIF adaptations 3rd party Specific service 3rd party specific service 3rd party Specific service XXX Integration Framework MMS My only project using an agile approach

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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 BCS Risk Management

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 21 The methodologies are integration throughout the sub- processes of the overall CRM process

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 22 IBM has a very comprehensive methodology for projects 15 1 22 1 515 1 5 2 3 Engagement Family Engagement Model WP Process Guidance 1 1.1 1.1.1 1.1.2 1.1.3 1.2. 1.2.1 Phase Release Deployment Build Cycle Micro Design Macro Design Solution Outline Solution Close Solution Startup Initiate Build Cycle Plan Deployment Confirm Build Cycle Build Event Driven Develop Support Materials Prepare for Testing Perform Programming Cycle Perform Development Testing Implement User Experience Perform System Testing Activity Task Outline Architecture 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] Outline Architecture Model ƒ 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

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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.

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 26 Within my domain (IT architecture) an description standard forms the basis for work products

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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 Guidelines UI 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

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 28 Phases, activities and tasks structure the project – the engagement models provide “common” structures

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 29 The large amount of engagement families and models reflects the broad spectrum of project that IBM engage

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 34 Predictive Vulnerable Fixed Diffuse Client Pain PointsFrom Fusion of Business and IT Fusion of Business and IT Demand for best-in-class Demand for best-in-class Standardization, commoditization Standardization, commoditization Selective sourcing Impact on Services Industry Unpredictable Threats Unrelenting Financial Pressures Unrelenting Financial Pressures Rigorous Competition Continuous Change Clients’ Needs and Expectations Are Changing Responsive Resilient Variable Focused To

Lecture at IT University of Copenhagen © Copyright IBM Corporation 2005 Being agile in the real world | November 11, 2005 35 ”a shift toward integrated solutions and quantifiable business value” mandates for business and IT alignment – Enterprise Architecture is key Business Strategy Information Technology Strategy Business Opportunity Technology Availability Business Architecture IT Architecture - Processes - Information - People - Locations - Applications - Data - Technology Planning Design and Delivery Enterprise wide focus Project focus Strategy Business Operating Environment and IT Infrastructure IT Solutions Enterprise Architecture Transition Plan Enterprise Architecture “the city plan” System Architecture functional aspects operational aspects “the infrastructure and single building design” Strategy and vision “Which city do we want to build?” The Gap The Great Divide

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 36 Drive down cost eliminate duplicate systems, build once and leverage, improve time to market Provide a flexible business model react to market changes more quickly Increase revenue create new routes to market, create new value from existing systems Reduce cycle times and cost for external business partners move from manual to automated transactions, facilitate flexible dealings with business partners Integrate across the enterprise integrate historically separate systems, facilitate mergers and acquisitions of enterprises Reduce risk and exposure improve visibility into business operations Each represents a SOA value proposition The pain points implies business challenges facing enterprises today – these challenges demand the fusion of business and IT

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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 ?

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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?

Lecture at IT University of Copenhagen © Copyright IBM Corporation 2005 Being agile in the real world | November 11, 2005 40 An SOA is composed of multiple layers that decouple the provider and consumer views service modeling Data Architecture & Business IntelligenceQoS, Security, Management & Monitoring Infrastructure Service Integration (Enterprise Service Bus approach) Custom Application Packaged Application Custom Application consumers business processes process choreography services atomic and composite service components operational systems Service Consumer Service Provider 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 OO Application Composite service Atomic service Registry JServicePortletWSRPB2BOther

Lecture at IT University of Copenhagen © Copyright IBM Corporation 2005 Being agile in the real world | November 11, 2005 41 At the heart of SOMA is the identification and specification of services, components and flows Realization Decisions Specification of Services, Components, Flows Identification of candidate Services, Components, and Flows > Data Architecture & Business IntelligenceQoS, Security, Management & Monitoring Infrastructure Service Integration (Enterprise Service Bus approach) Custom Application Packaged Application Custom Application consumers business processes process choreography services atomic and composite enterprise components operational systems Service Consumer Service Provider 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 OO Applicatio n Composite service Atomic service Registry JServicePortletWSRPB2BOther 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

Lecture at IT University of Copenhagen © Copyright IBM Corporation 2005 Being agile in the real world | November 11, 2005 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 Decisions Specification of Services, Components, Flows Identification of candidate Services, Components, and Flows Domain Decomposition Subsystem Analysis Service Specification message & event specification component flow specification service flow specification Realization Decisions Goal-Service Modeling Existing Asset Analysis Component Specification information specification service allocation to components component layering technical feasibility exploration

Lecture at IT University of Copenhagen © Copyright IBM Corporation 2005 Being agile in the real world | November 11, 2005 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 Model Service Portfolio State Management DescriptionSOMA step Candidate services discovered during SOMA service identification activities.  Domain Decomposition  Goal-Service Modeling  Existing Asset Analysis Candidate services organized using a business significant categorization scheme to make evaluation more manageable  Domain Decomposition  Goal-Service Modeling  Existing 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

Lecture at IT University of Copenhagen © Copyright IBM Corporation 2005 Being agile in the real world | November 11, 2005 44 Governance is yet another key… IT and Operations align with Business Business Opportunity Technology Availability Planning Model & Assemble Strategy Deploy & Manage Business Strategy Information Technology Strategy IT Architecture Business Operating Environment and IT Infrastructure IT Solutions Business Architecture Enterprise-wide focus Consistent Service Model Reconcile Multiple 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?

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 45 SOA Reference Architecture Supporting your SOA Lifecycle Business Innovation & Optimization Services Development Services 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 Service Management Infrastructure Services Optimizes throughput, availability and performance ESB Facilitates communication between services Apps & Info Assets Partner ServicesBusiness App ServicesAccess Services Connect with trading partners Build on a robust, scaleable, and secure services environment Facilitates interactions with existing information and application assets Interaction ServicesProcess ServicesInformation Services Enables collaboration between people, processes & information Orchestrate and automate business processes Manages diverse data and content in a unified manner

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 49 The Service Component Compound Pattern – A Recommended Design Source: Ali Arsanjani, “Enterprise Component Pattern”, Pattern Languages of Programming 2001 Façade Mediator Rule Object Composite [Factory] [Adaptors]

© Copyright IBM Corporation 2004 Being agile in the real world | November 11, 2005 Lecture at IT University of Copenhagen 50 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 General Ledger Document Management Customer Dialogue Contact Routing Staff Administration Business Administration New Business Development Relationship Management Servicing & Sales Product Fulfilment Financial Control and Accounting Sector Planning Portfolio Planning Account Planning Sales 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

Lecture at IT University of Copenhagen © Copyright IBM Corporation 2005 Being agile in the real world | November 11, 2005 53 Many of the Reference architectures provides huge amount of details (e.g. as work products) Infrastructure Services Application and Data Access Services Business Application and Data Services Business Performance Management Services Business Application Services Process Services Information Services Development Platform Enterprise Applications and Data Interaction Services Partner Services Enterprise Service Bus IBM Business Integration Reference Architecture

Lecture at IT University of Copenhagen © Copyright IBM Corporation 2005 Being agile in the real world | November 11, 2005 54 The reference architectures provides models and - for some of them - work products to be used in engagements Infrastructure Services Application and Data Access Services Business Application and Data Services Business Performance Management Services Business App Services Process Services Information Services Development Platform Enterprise Applications and Data Interaction Services Partner Services Enterprise Service Bus 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

Lecture at IT University of Copenhagen © Copyright IBM Corporation 2005 Being agile in the real world | November 11, 2005 55 Infrastructure Services Application and Data Access Services Business Application and Data Services Business Performance Management Services Development Platform Enterprise Applications and Data Partner Services Enterprise Service Bus WebSphere BI Modeler WebSphere Studio DB2 Information Integrator WebSphere BI Server WebSphere BI Server Foundation WebSphere Portal Server WebSphere BI Connect WebSphere Application Server WBI Adapters DB2 II Classic HATS WBI Monitor Process Services Information Services Interaction Services Business App Services Web Services Gateway WBI Event/Message Broker WebSphere MQ IBM Software Offerings … some of them even beyond a conceptual level

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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

Lecture at IT University of Copenhagen Being agile in the real world | November 11, 2005 © 2005 IBM Corporation 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

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.

Similar presentations

Presentation on theme: "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."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

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.

Similar presentations

Presentation on theme: "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."— Presentation transcript:

Similar presentations

About project

Feedback