Software Factories in the Real World: How an IBM WebSphere Integration Factory Helped an Automotive Retailer Keep Its Customers on the Road

Software Factories in the Real World: How an IBM® WebSphere® Integration Factory Helped an Automotive Retailer Keep Its Customers on the Road

Session 1602

André Tost,Senior Technical Staff Member, Software Group

Greg Hodgkinson,Practice Director, Lifecycle Tools and Methodology

© 2012 IBM Corporation2

The Premier Event for Software and Systems Innovation

Session Introduction

Abstract: “Getting any software development team to effectively scale to meet the needs of a large

integration project is actually harder than it sounds. For a large Automotive Retailer based in Florida,

this is exactly what they needed to do. They needed a large amount of integration to be built between

their brand new Point of Sales system and their new SAP back-end. In this session, you will hear about

how tools such as Rational Software Architect and WebSphere Message Broker Toolkit were integrated

with a Rational Team Concert-based development environment to set up super efficient software

factory employing techniques such as Model-Driven Development and Continuous Integration to help

this retailer keep their customers’ wheels on the road.”

Topics for today:

The project

The challenges faced

The software factory tools

The software factory workflow

Key practices that helped us succeed

The benefits

Final thoughts



Introducing the Project

A new automotive retail in-store experience

Replacing green screen terminals in the store with modern user interfaces

– Touch screens

– Tablets

– Customer self-service “kiosks”

– In-store WiFi

– Completely new private network (MPLS)

Replacing legacy backend application for customer management, order management and inventory management

– Transitioning from JDEdwards to SAP

Middleware integration layer

– Exposing backend functionality as reusable business services

– Fully virtualized, scalable infrastructure

– Private cloud on X86/Linux



Introducing the Project (cont.)

Service orientation as the architectural foundation

Building an integration layer consisting of service exposure AND provider creation

Diagram taken from developerWorks article “The Enterprise Service Bus, re-examined”,see http://www.ibm.com/developerworks/websphere/techjournal/1105_flurry/1105_flurry.html



Introducing the Project

Challenges faced

Multi-vendor, global development team

– US

– China

– Egypt

– Philippines

Requirements were limited to screenshots

– Hundreds of wire frames, very useful for data modeling

– No functional business requirements

Three layers (client UI, integration layer, backend/SAP) all designed and developed in parallel

– (Semi-)Agile development process required

Brand new infrastructure– New network, new platform, new middleware

Plus, all the usual project constraints – Tight schedule

– Constrained budget



Introducing the Software Factory Tools

WebSphere Message Broker

Reducing the complexity of integrating your systems

Point-to-point is expensiveIntegration requires specialist knowledge of API technologiesIntegration plumbing and mapping code wastes developer hoursMixing integration code with application code makes applications brittleIntegrations have high availability and reliability requirements – complexity

2) Dynamic mediation2) Dynamic mediation

4) Supports multiple 4) Supports multiple technologies technologies

3) Routes and transforms data3) Routes and transforms data

1) Simplified 1) Simplified integration authoringintegration authoring




Managing and communicating your software requirements

Poor requirements is the #1 reason projects failTraceability is NB, but time consumingDifficult to correlate scope lists with specificationsAs soon as requirements documents are released they can become out of dateOften the author > review > feedback > rework process is inefficient

1) All-in-one editor – 1) All-in-one editor – text as well as text as well as

diagramsdiagrams

2) Easy traceability 2) Easy traceability link creation and link creation and

“surfing”“surfing”

3) Visual focus – 3) Visual focus – process, use case, process, use case, screen mockupsscreen mockups

4) Built-in review 4) Built-in review workflowworkflow

5) Strong lifecycle links – to plans, to 5) Strong lifecycle links – to plans, to designs, to code, to builds, to tests designs, to code, to builds, to tests

Rational Requirements Composer



Controlling the architectural quality of your software

Difficult to handle software complexity – too much of itLose sight of good patterns when you are “down in the code”Refactoring of code is expensiveLarge mental leap between requirements and codeHow do you make design a “team game”?


1) Supports popular modeling 1) Supports popular modeling standards – UML, BPMN2, SoaMLstandards – UML, BPMN2, SoaML

2) Turn models into 2) Turn models into code with code with

transformationstransformations3) Automatically 3) Automatically

apply model apply model patternspatterns

4) Graphical code 4) Graphical code editors and visualizerseditors and visualizers

5) Design Manager 5) Design Manager adds web-based adds web-based

collaborationcollaboration

Rational Software Architect for WebSphere



4) Built-in build support 4) Built-in build support including build engineincluding build engine

5) SCM provides support 5) SCM provides support for streams, components, for streams, components,

workspaces – flexible, workspaces – flexible, simple, powerfulsimple, powerful


Managing and enabling change

Plans can quickly become out of dateProgress views limited to point-in-time snapshots and waste effortHow to easily track what work was delivered in a new build?How to easily track SCM changes against plans?How to correlate all project data in a format that is easy to consume (and has value)

1) Like 5 tools in one – plans, work items, 1) Like 5 tools in one – plans, work items, SCM, build, project data warehouseSCM, build, project data warehouse

2) Fully integrated data 2) Fully integrated data across lifecycleacross lifecycle

3) Excellent support for 3) Excellent support for agile as well as agile as well as

“traditional” project styles“traditional” project styles

Rational Team Concert



The Software Factory Workflow

Coordinating requirements and designs across technology stacks

Constraint: 3 teams working on 3 separate but related streams.

Driven by UI wireframes Derived scope list (RRC) Transferred to plans (RTC) Requirements specs written for

service operations (RRC/RSA) Designs specs written for service

operations (RSA) Front-end-WSDL generated

(RSA) Implementations and stubs

(WMBT)




Timing is everything!

Ideal: Back-end WSDL available to SOA integration analysts.





Not so good: Back-end WSDL arrives during SOA design.





Getting bad: Back-end WSDL not available for SOA implementation.





The pits: Back-end implementation not available to test against.



Coordinating distributed development and integrating the results

Workflow tuned to high velocity without sacrificing quality.


RRC

requirements

RSA

service

model

RTC

scm

RTC

scm

WM

B

DE

V

WM

B

QA

wsdlimplementation

wsdlimplementation

Cairo

wsdlimplementation

wsdlimplementation

China

wsdlimplementation

wsdlimplementation

US

wsdl

SOA analysts

UI & back-endanalysts,

stakeholders

SOA designers

UI & back-enddesigners,

stakeholders

SOA devs

SOA devs

SOA devs

Continuousbuild/deploy

On-demandbuild/deploy

feedback

feedback



Key Practices for Success

Tighter architectural control using RSA

Solution architecture modeledin UML

Service model developed in UML

– Initial version derived fromuse case descriptions

– Collaboratively finalized viaLotusLive sessions

– ~30 services with ~160 operations

WSDL automatically generated from UML

– Using out-of-the-box RSA transformation

– Some required modification done via XSLT

Both UML and WSDL storedin RTC




Keeping the team on track using RTC

Service operation tracking

– Separate tracking for each service interface and each service operation gives indication of progress

– See later slide for example

Easy assignment of work items to individuals

– For net new development and defect fixes

– Good way of communicating with offshore teams

Impediments

– Communication of (typically blocking) issues across distributed teams

– Identified and/or assigned also during daily scrum meeting

Custom “change control” work item allowed tracking of changes to the service model

– Linkage to individual work items (model change, implementation change, etc)

– Notification to interested users




Streams for easy management of different

configurations

– Code configuration for each environment: DEV > QA > PROD

– Easy to promote changes through environments

Components allow for groups of artefacts to

be managed together

– Separate out code components, tests, stubs, models, documents

– Component per application component

• Loading and unloading

• Consolidated history

• Easy to snapshot

Collaborative configuration management using RTC




Project events provides an excellent way to

quickly see latest changes

– Easy to see what real (as opposed to planned) current focus of work is

– Can click straight into work context for more

– Keeps team aware of dependencies

The “Pending changes” view became a core

element of governance

– Good overview of who changed what and why

– Allows enforcement of compliance with established standards - Naming, code structure, etc.

– Changes are organised by component – making it easier to focus on the changes that matter to you

Collaborative configuration management using RTC




RTC’s simple build engine + Prolifics Build Conductor

= effortless builds!

– ANT build engine simple and easy to use

– PBC adds automation scripts for WebSphere apps: WESB, WMB, WPS, Portal

– Automated build, override, deploy

Build record publishes a wealth of information

– What was built – BARs

– What tasks/requirements/fixes included

– What change sets included

– Full log files as well as activity view

Hassle-free build and deploy using RTC




Different builds for different purposes

– Continuous integration build that only catches compile errors can look for changes every few minutes

– Continuous integration build that deploys to DEV can be run every 2 hours

– On-demand build to target QA can be triggered when needed

Accelerated fix delivery

– From build record snapshot, can create a new fix workspace within seconds

– Suspend and unload existing changes, then code the fix and deliver to fix

– As soon as delivered, on-demand build can deploy changes automatically to environment of choice

– Fantastically quick turnaround of fixes!

Hassle-free build and deploy using RTC




Project dashboard using RTC - Overview




Project dashboard using RTC – Release Status




Project dashboard using RTC – Impediments




Project dashboard using RTC – Change Controls



How Did We Benefit?

Improving team efficiency

Using RTC client plug-in for Eclipse-based tooling supports online and offline work

– Especially helpful when having many travelling developers

Fine grained control over which changes are replicated/downloaded

Using one component per service was a good structure

– Good support of having development teams work concurrently on different service implementations

Minimal delays to get changes to testers

Separate build streams for dedicated, continuous builds

– More build engines would have been beneficial

Shared build infrastructure meant developers didn’t maintain their own



How Did We Benefit?

Improving deliverable quality

Using a UML-based service model

– Visual representation used to communicate interface to the development team

Component-based source control made developers think more about how their code was structured

Automated build and deploy caught issues earlier

Handed over a fully automated and structured build and deploy infrastructure along with the source code - to the benefit of the maintenance team



Final Thoughts

Session wrap-up

A large project, with a global team of developers and testers, required global collaboration and cooperation

Tying individual development tools into one team environment, RTC, facilitated sharing of artefacts and joint development of solutions

– Need good structure of streams and components, based on target runtimes and team organization

Project management features of RTC allow direct integration of planning activities with the developed artifacts

Continuous automated builds important enough to have a full time release engineer

Using Eclipse as the foundation for all tooling makes it easier to integrate different environments and target runtimes

You still need good developers and strong governance!



www.ibm.com/software/rational

http://www.ibm.com/software/rational



Daily iPod Touch giveaway

Complete your session surveys online each day at a conference kiosk or on your Innovate 2012 Portal!

Each day that you complete all of that day’s session surveys, your name will be entered to win the daily IPOD touch!

On Wednesday be sure to complete your full conference evaluation to receive your free conference t-shirt!



Acknowledgements and disclaimers

© Copyright IBM Corporation 2012. All rights reserved.

– U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

IBM, the IBM logo, ibm.com, Rational, the Rational logo, Telelogic, the Telelogic logo, Green Hat, the Green Hat logo, and other IBM products and services are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml

If you have mentioned trademarks that are not from IBM, please update and add the following lines:

[Insert any special third-party trademark names/attributions here]

Other company, product, or service names may be trademarks or service marks of others.

Availability: References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates.

The workshops, sessions and materials have been prepared by IBM or the session speakers and reflect their own views. They are provided for informational purposes only, and are neither intended to, nor shall have the effect of being, legal or other guidance or advice to any participant. While efforts were made to verify the completeness and accuracy of the information contained in this presentation, it is provided AS-IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this presentation or any other materials. Nothing contained in this presentation is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software.

All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results.

http://www.ibm.com/legal/copytrade.shtml



© Copyright IBM Corporation 2012. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

www.ibm.com/software/rational

http://www.ibm.com/software/rational

Software Factories in the Real World: How an IBM WebSphere Integration Factory Helped an Automotive Retailer Keep Its Customers on the Road

Software

software factories

software development

rational software architect

software groupgreg hodgkinson

premier event

large integration project

continuous integration

new middlewareplus