a software factory integrating rational & websphere tools
TRANSCRIPT
1
A Software Factory Integrating Rational & WebSphere Tools
Session 1741
André Tost,Senior Technical Staff Member, Software Group
Greg Hodgkinson,Practice Director, Lifecycle Tools and Methodology
2
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
3
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
4
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
5
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
6
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
7
Introducing the Software Factory Tools
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
8
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”?
Introducing the Software Factory Tools
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
9
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
Introducing the Software Factory Tools
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
10
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)
11
The Software Factory Workflow
Timing is everything! Ideal: Back-end WSDL available to SOA integration analysts.
12
The Software Factory Workflow
Timing is everything! Not so good: Back-end WSDL arrives during SOA design.
13
The Software Factory Workflow
Timing is everything! Getting bad: Back-end WSDL not available for SOA implementation.
14
The Software Factory Workflow
Timing is everything! The pits: Back-end implementation not available to test against.
15
Coordinating distributed development and integrating the results
Workflow tuned to high velocity without sacrificing quality.
The Software Factory Workflow
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
16
Key Practices for Success
Tighter architectural control using RSA
Solution architecture modeledin UML
Service model developed in UML– Initial version derived from
use 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
17
Key Practices for Success
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
18
Key Practices for Success
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
19
Key Practices for Success
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
20
Key Practices for Success
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
21
Key Practices for Success
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
22
Key Practices for Success
Project dashboard using RTC - Overview
23
Key Practices for Success
Project dashboard using RTC – Release status
24
Key Practices for Success
Project dashboard using RTC - Impediments
25
Key Practices for Success
Project dashboard using RTC – Change controls
26
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
27
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
28
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!
29
We love your Feedback!
Don’t forget to submit your Impact session and speaker feedback! Your feedback is very important to us, we use it to improve our conference for you next year.
Go to impactsmartsite.com from your mobile device
From the Impact 2012 Online Conference Guide:
– Select Agenda
– Navigate to the session you want to give feedback on
– Select the session or speaker feedback links
– Submit your feedback
30
© IBM Corporation 2012. All Rights Reserved.
IBM, the IBM logo, ibm.com are trademarks or registered trademarks of International Business Machines Corp.,
registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies.
A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at
www.ibm.com/legal/copytrade.shtml.
Copyright and Trademarks
31
Please Note
IBM's statements regarding its plans, directions, and intent are subject to change or withdrawal at IBM's sole discretion.
Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision.
The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.
Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here.