A Software Factory Integrating Rational Team Concert and WebSphere tools

1,510 views

Published on

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.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,510
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
37
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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
  • File Name Here.ppt
  • File Name Here.ppt
  • File Name Here.ppt
  • A Software Factory Integrating Rational Team Concert and WebSphere tools

    1. 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 17411
    2. 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 thoughts2
    3. 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/Linux3
    4. 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. 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 schedule5 – Constrained budget
    6. 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 technologies6
    7. 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 tests7
    8. 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-based8 collaboration
    9. 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, powerful9
    10. 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. 11. The Software Factory Workflow Timing is everything!  Ideal: Back-end WSDL available to SOA integration analysts.11
    12. 12. The Software Factory Workflow Timing is everything!  Not so good: Back-end WSDL arrives during SOA design.12
    13. 13. The Software Factory Workflow Timing is everything!  Getting bad: Back-end WSDL not available for SOA implementation.13
    14. 14. The Software Factory Workflow Timing is everything!  The pits: Back-end implementation not available to test against.14
    15. 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 devs15
    16. 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 RTC16
    17. 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 users17
    18. 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 snapshot18
    19. 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 you19
    20. 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 view20
    21. 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
    22. 22. Key Practices for Success Project dashboard using RTC - Overview22
    23. 23. Key Practices for Success Project dashboard using RTC – Release status23
    24. 24. Key Practices for Success Project dashboard using RTC - Impediments24
    25. 25. Key Practices for Success Project dashboard using RTC – Change controls25
    26. 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 maintain26 their own
    27. 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 team27
    28. 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. 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 feedback29
    30. 30. Copyright and Trademarks © 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.30
    31. 31. Please Note IBMs statements regarding its plans, directions, and intent are subject to change or withdrawal at IBMs 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 users 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

    ×