Speakers: Greg Hodgkinson, Prolifics; Andre Tost, IBM
Description: 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.
Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...
A Software Factory Integrating Rational Team Concert and WebSphere tools
1. A Software Factory Integrating Rational
& WebSphere Tools
Greg Hodgkinson,
Practice Director, Lifecycle Tools and Methodology
André Tost,
Senior Technical Staff Member, Software Group
Session 1741
1
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
2
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
3
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”,
4
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
5
– Constrained budget
6. Introducing the Software Factory Tools
WebSphere Message Broker
1) Simplified
Reducing the complexity of integration authoring
integrating your systems
Point-to-point is expensive
Integration requires specialist
knowledge of API technologies
Integration plumbing and mapping
code wastes developer hours
Mixing integration code with
application code makes
applications brittle
Integrations have high availability
and reliability requirements – 2) Dynamic mediation
complexity 3) Routes and transforms data
4) Supports multiple
technologies
6
7. Introducing the Software Factory Tools
Rational Requirements Composer
1) All-in-one editor – 2) Easy traceability
Managing and communicating text as well as link creation and
your software requirements diagrams “surfing”
Poor requirements is the #1
reason projects fail
Traceability is NB, but time
consuming
Difficult to correlate scope lists
with specifications
As soon as requirements
documents are released they can
become out of date 3) Visual focus –
Often the author > review > 4) Built-in review
process, use case, workflow
feedback > rework process is screen mockups
inefficient
5) Strong lifecycle links – to plans, to
designs, to code, to builds, to tests
7
8. Introducing the Software Factory Tools
Rational Software Architect for WebSphere
Controlling the architectural 1) Supports popular modeling
quality of your software standards – UML, BPMN2, SoaML
2) Turn models into
Difficult to handle software
code with
complexity – too much of it
transformations
Lose sight of good patterns when
3) Automatically
you are “down in the code”
apply model
Refactoring of code is expensive
patterns
Large mental leap between
requirements and code
How do you make design a “team 4) Graphical code
game”? editors and visualizers
5) Design Manager
adds web-based
8
collaboration
9. Introducing the Software Factory Tools
Rational Team Concert
1) Like 5 tools in one – plans, work items,
Managing and enabling change SCM, build, project data warehouse
Plans can quickly become out of
date
Progress views limited to point-in- 2) Fully integrated data
time snapshots and waste effort across lifecycle
How to easily track what work was
delivered in a new build? 3) Excellent support for
How to easily track SCM changes agile as well as
against plans? “traditional” project styles
How to correlate all project data in
a format that is easy to consume 4) Built-in build support
(and has value) including build engine
5) SCM provides support
for streams, components,
workspaces – flexible,
simple, powerful
9
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)
10
11. The Software Factory Workflow
Timing is everything!
Ideal: Back-end WSDL available to SOA integration analysts.
11
12. The Software Factory Workflow
Timing is everything!
Not so good: Back-end WSDL arrives during SOA design.
12
13. The Software Factory Workflow
Timing is everything!
Getting bad: Back-end WSDL not available for SOA implementation.
13
14. The Software Factory Workflow
Timing is everything!
The pits: Back-end implementation not available to test against.
14
15. The Software Factory Workflow
Coordinating distributed development and
integrating the results
Workflow tuned to high velocity without sacrificing quality.
implementation
wsdl
SOA SOA
analysts designers
implementation feedback
wsdl
RSA Cairo SOA
Continuous
build/deploy
RRC RTC devs RTC
service
requirements scm implementation scm
model wsdl
WMB
DEV
wsdl
implementation
wsdl
On-demand
China SOA build/deploy
WMB
QA
devs
UI & back-end UI & back-end
implementation
analysts, designers, wsdl
stakeholders stakeholders
implementation
wsdl feedback
US SOA
devs
15
16. Key Practices for Success
Tighter architectural control using RSA
Solution architecture modeled
in UML
Service model developed in UML
– Initial version derived from
use case descriptions
– Collaboratively finalized via
LotusLive 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 stored
in RTC
16
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
17
18. Key Practices for Success
Collaborative configuration management using RTC
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
18
19. Key Practices for Success
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
19
20. Key Practices for Success
Hassle-free build and deploy 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
20
21. Key Practices for Success
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!
21
23. Key Practices for Success
Project dashboard using RTC – Release status
23
24. Key Practices for Success
Project dashboard using RTC - Impediments
24
25. Key Practices for Success
Project dashboard using RTC – Change controls
25
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
26
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
27
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!
28
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
29
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.
31
Hinweis der Redaktion
File Name Here.ppt File Name Here.ppt 02/10/10 03:37
File Name Here.ppt File Name Here.ppt 02/10/10 03:37
File Name Here.ppt File Name Here.ppt 02/10/10 03:37
File Name Here.ppt File Name Here.ppt 02/10/10 03:37
File Name Here.ppt File Name Here.ppt 02/10/10 03:37
File Name Here.ppt File Name Here.ppt 02/10/10 03:37 Used to implement architecture described in slide 4.
File Name Here.ppt File Name Here.ppt 02/10/10 03:37
File Name Here.ppt File Name Here.ppt 02/10/10 03:37
File Name Here.ppt File Name Here.ppt 02/10/10 03:37 Jazz .. Open source… open platform… people can integrate with.
File Name Here.ppt File Name Here.ppt 02/10/10 03:37 Show how requirements are identified from UI mockups, transalated to scenarios, scenarios are specified by each of integration and SAP stacks, designs are created for each of integration and SAP stacks, reviews ensure cross-stack integrity.
File Name Here.ppt File Name Here.ppt 02/10/10 03:37 Show how requirements are identified from UI mockups, transalated to scenarios, scenarios are specified by each of integration and SAP stacks, designs are created for each of integration and SAP stacks, reviews ensure cross-stack integrity.
File Name Here.ppt File Name Here.ppt 02/10/10 03:37 Show how requirements are identified from UI mockups, transalated to scenarios, scenarios are specified by each of integration and SAP stacks, designs are created for each of integration and SAP stacks, reviews ensure cross-stack integrity.
File Name Here.ppt File Name Here.ppt 02/10/10 03:37 Show how requirements are identified from UI mockups, transalated to scenarios, scenarios are specified by each of integration and SAP stacks, designs are created for each of integration and SAP stacks, reviews ensure cross-stack integrity.
File Name Here.ppt File Name Here.ppt 02/10/10 03:37 Show how requirements are identified from UI mockups, transalated to scenarios, scenarios are specified by each of integration and SAP stacks, designs are created for each of integration and SAP stacks, reviews ensure cross-stack integrity.
File Name Here.ppt File Name Here.ppt 02/10/10 03:37 Show how design work identifies specific services for implementation, these are developed by distributed team, and integrations of the code are delivered to test team.
File Name Here.ppt File Name Here.ppt 02/10/10 03:37 Mention RSA Design Manager as an alternative to collaborative sessions via LotusLive.
File Name Here.ppt File Name Here.ppt 02/10/10 03:37
File Name Here.ppt File Name Here.ppt 02/10/10 03:37 Describe how high-level design is used to come up with set of components across code and other artifacts. Describe how combination of repo workspaces and streams allow team to work separately and share changes. Describe how streams are created for each environment to allow changes to be promoted. Describe how snapshots are used to track configurations of both design and code.
File Name Here.ppt File Name Here.ppt 02/10/10 03:37 Describe how high-level design is used to come up with set of components across code and other artifacts. Describe how combination of repo workspaces and streams allow team to work separately and share changes. Describe how streams are created for each environment to allow changes to be promoted. Describe how snapshots are used to track configurations of both design and code.
File Name Here.ppt File Name Here.ppt 02/10/10 03:37 Describe continous integration build and all of its advantages. Describe he features that build conductor provides off the shelf. Describe other builds – and build conductors flexible reuse model.
File Name Here.ppt File Name Here.ppt 02/10/10 03:37 Describe continous integration build and all of its advantages. Describe he features that build conductor provides off the shelf. Describe other builds – and build conductors flexible reuse model. Nature of build problems in WMB different – dependencies, etc. Also many deploy time problems caught early – and there were many caused by the way the code had been configured to build. Overriding properties in BAR files. Hugely important because we could be flexible about what environment we deployed into.
File Name Here.ppt File Name Here.ppt 02/10/10 03:37 Describe continous integration build and all of its advantages. Describe he features that build conductor provides off the shelf. Describe other builds – and build conductors flexible reuse model.
File Name Here.ppt File Name Here.ppt 02/10/10 03:37 Describe continous integration build and all of its advantages. Describe he features that build conductor provides off the shelf. Describe other builds – and build conductors flexible reuse model.
File Name Here.ppt File Name Here.ppt 02/10/10 03:37 Describe continous integration build and all of its advantages. Describe he features that build conductor provides off the shelf. Describe other builds – and build conductors flexible reuse model.
File Name Here.ppt File Name Here.ppt 02/10/10 03:37 Describe continous integration build and all of its advantages. Describe he features that build conductor provides off the shelf. Describe other builds – and build conductors flexible reuse model.
File Name Here.ppt File Name Here.ppt 02/10/10 03:37
File Name Here.ppt File Name Here.ppt 02/10/10 03:37
File Name Here.ppt File Name Here.ppt 02/10/10 03:37