Download to read offline
More Related Content
Similar to Broadcast Music Inc - Scaling Up, Doing More, Having More Fun!
Broadcast Music Inc - Scaling Up, Doing More, Having More Fun!
- 1. © 2014 IBMCorporation 1867, Broadcast Music – Scaling Up, Doing More, Having More Fun! Greg Hodgkinson Practice Director – Lifecycle Tools and Methodology, Prolifics Jim Harvey Senior Director of Business Analysis and Quality Assurance, Broadcast Music Inc.
- 2. 2 • Broadcast Music,Inc. - 1939 • Performing Rights Organization (PRO) • Pay public performance royalties • Operate on a non-profit-making basis • 7 locations: Nashville, New York, Los Angeles, Atlanta, Miami, Puerto Rico, London • 600 employees • 7.5 million works • 500,000 songwriters and composers This is BMI – Who We Are and What We Do
- 3. The Performers Israel Kamakawiwooleʻ Louis Armstrong Judy Garland The Performers
- 4. The Writers “What awonderful world” George David Weiss Bob Thiele “Somewhere over the rainbow” 1939 1967
- 6. Over 500 digitalmusic services worldwide offer consumers the opportunity to legally access up to 26 million songs © 2012 Pro-Music
- 7. IBM Prolifics Best practices Guidance Integration Technologies Implementation
- 8. 8 Overall Architecture SOAP/HTTPSOAP/HTTP Federated ESBArchitecture WebSphere Service Registry and Repository(WSRR) Data transformations Portal, BPM and Mobile Consumers SOAP/HTTPSOAP/HTTP (S)(S) ReST/HTTPReST/HTTP (S)(S) JDBCJDBC SOAP/HTTPSOAP/HTTP (S)(S) Security (authentication and authorization)
- 9. 9 • Our approachto rolling out change is very well summarized in the IBM Rational Development Environment Architecture (DEA) framework. Riding the Wave - Waves of Change
- 10. 10 • Scope ofthe First Wave • Establish a new, integrated software development environment • RRC • RTC • RQM • RSA • Roll out methodology as part of an Agility@Scale engagement • Stand up an initial DevOps Center of Excellence Wave 1 – The Tooling Tsunami
- 11. 11 • New tools,new process • Risk of over complicating process • Risk of tools ending up on the shelf • Adopt Scrum-based project methodology • To organize teams • To steer meetings • To track requirements through to delivery • To measure progress • Keep process as simple as possible while still meeting goals • Leverage tools to enact process across lifecycle, from requirements (RRC) to plans/implementation (RTC), to testing (RQM) • Use SOA principles for creating service- based architecture Wave 1 – Methodology and Tooling Goals
- 12. 12 On sitesupport – Inception (3 weeks) – Construction Iteration 1 (2 weeks) – Construction Iteration 2 (2 weeks) Activity Types – Workshops: Just-in time short duration knowledge transfer sessions on the CLM for IT agility@scale process framework concepts and solution tool mentors – Working sessions: hands on mentoring session facilitated by an IBM consultant focused on creating real project assets – Activity support: unstructured support session for critical activities that continue after the working sessions such as one- on-one mentoring, team meetings, asset reviews, white board discussions, etc. Wave 1 – Methodology and Tooling Goals Realized Getting Started with Agility@Scale
- 13. RSA Model-Driven Developmentfor Tighter Control 13 • Solution architecture modelled in UML • Service model developed in UML – Initial version derived from user story descriptions – Collaboratively finalized – ~x services with ~y operations • WSDL automatically generated from UML – Using out-of-the-box RSA transformation • Both UML and WSDL stored in RTC Wave 1 – Methodology and Tooling Goals Realized
- 14. 14 • Save time •Reduce time required to assemble releases • Reduce time required to deploy releases • Simplify • Manage promotion of changes through pipeline of environments • Fit in with tools used by the entire team • Add value • Have an audit trail of releases • Provide traceability • Track snapshots, and allow us to go back to previous Wave 1 – DevOps Goals
- 15. Saving Time –Scripted Assembly of Code 15 Wave 1 – DevOps Goals Realized Manual creation and delivery of assembled code used to take time away from developers. Now done by build engineering using automated reusable scripts! Estimated savings of 6,010 hours per year. Manual creation and delivery of assembled code used to take time away from developers. Now done by build engineering using automated reusable scripts! Estimated savings of 6,010 hours per year. AutomateAutomate
- 16. Saving Time –Scripted Deployment of Code 16 Wave 1 – DevOps Goals Realized Furthermore, manual deployment took time away from developers. Also now done by build engineering using automated reusable scripts! Estimated savings of 6,710 hours per year. Furthermore, manual deployment took time away from developers. Also now done by build engineering using automated reusable scripts! Estimated savings of 6,710 hours per year. AutomateAutomate
- 17. Saving Time –The Results… 17 Wave 1 – DevOps Goals Realized • Instead of needing this… • We have this… Based on stats, we have one build engineer doing the work of 6-8 people! Based on stats, we have one build engineer doing the work of 6-8 people!
- 18. Simplify – ThePromotion Pipeline 18 Wave 1 – DevOps Goals Realized DEVDEV INTINT TESTTEST PRODPROD PromotePromote PromotePromote PromotePromote Setup simple stream-based model where changes can be moved through each of the environments in the pipeline, using automation scripts at each step. Promotion model is a simple reflection of real-world environments. Build engineer controls promotion. Setup simple stream-based model where changes can be moved through each of the environments in the pipeline, using automation scripts at each step. Promotion model is a simple reflection of real-world environments. Build engineer controls promotion.
- 19. Simplify – CommonTooling 19 Wave 1 – DevOps Goals Realized Importantly, the build engineering team utilizes the same tooling stack as scrum masters, developers and testers: Rational CLM Result: Better integration between teams activities. Importantly, the build engineering team utilizes the same tooling stack as scrum masters, developers and testers: Rational CLM Result: Better integration between teams activities.
- 20. Added Value –Enabling Rollback 20 Wave 1 – DevOps Goals Realized How do I go back to a previous release? Every build has an automatic snapshot taken. Result: Easy to go back to previous versions, easy to see what is different. Every build has an automatic snapshot taken. Result: Easy to go back to previous versions, easy to see what is different.
- 21. Added Value –Leaving an Audit Trail 21 Wave 1 – DevOps Goals Realized How do I see what releases were deployed, when, and by who? Constant automatic audit, with various views. Result: Easy to find out what has been happening. Constant automatic audit, with various views. Result: Easy to find out what has been happening.
- 22. Added Value –Solving the Traceability Problem 22 Wave 1 – DevOps Goals Realized How do I see what planned scope went into a release? Click through to get list of items included in every build. Result: Easy cross-referencing. Click through to get list of items included in every build. Result: Easy cross-referencing.
- 23. Added Value –The Results… 23 Wave 1 – DevOps Goals Realized • Instead of having this… • We have this… • When did I deploy? • What was in the deployment? • Where have I deployed to?
- 24. 24 • Scope ofthe Second Wave • Need to ramp up to a number of application projects • Many more technologies being rolled out • New styles of analysis required • Better integration with testing and service registry required • Fix disjoint between project execution and PMO Wave 2 – Stepping Up and Riding the Wave
- 25. 25 • Roll outapproach and tooling to multiple parallel project streams • Need to track scope separately • Need to reflect some project interdependencies • Project teams and shared teams • Pipeline planning of projects • Need tooling support for existing project pipeline planning approach • Needed to integrate pipeline planning with execution in RTC • Need to adapt the approach using RRC to BPM projects • Include process analysis using IBM BlueWorksLive • Need traceability matrix to prove completeness of scope Wave 2 – Methodology and Tooling Goals
- 26. 26 Wave 2 –Methodology and Tooling Goals Realized Interdependent Projects in RTC
- 27. 27 Wave 2 –Methodology and Tooling Goals Realized Focal Point for Pipeline Planning Objectively compare different strategies for prioritization. Align investments with business objectives. Objectively compare different strategies for prioritization. Align investments with business objectives. Support capacity planning and project sequencing. Support capacity planning and project sequencing. Visualize trade-offs.Visualize trade-offs. Review program status at a glance with dashboards. Review program status at a glance with dashboards. Plans can be taken into RTC for execution. Plans can be taken into RTC for execution.
- 28. 28 Wave 2 –Methodology and Tooling Goals Realized Joining Up BlueWorksLive and RRC ActorActor Story/FeatureStory/Feature TermTerm Non-Functional Requirement Non-Functional Requirement Business RuleBusiness Rule ProcessProcess Integration Spec Integration Spec ActivityActivity CapabilityCapability UI SpecUI Spec 1. Capture process from BWL 2. Define functional requirements 4. Add user experience and integration requirements Extend glossary 3. Define rules 5. Define non- functional requirements CollectionCollection Import from FP 6. Define scope
- 29. 29 • Save time •Include automated testing • Include automated service registry publish • Simplify • Apply consistent approach across technology stack Wave 2 – DevOps Goals
- 30. Saving Time –Scripted Execution of Automated Tests 30 Wave 2 – DevOps Goals Realized Remembering to execute regression tests on a regular basis used to take time away from the testers. Also now done by build engineering using automated reusable scripts! Estimated savings of 1,050 hours per year. Remembering to execute regression tests on a regular basis used to take time away from the testers. Also now done by build engineering using automated reusable scripts! Estimated savings of 1,050 hours per year. AutomateAutomate
- 31. Saving Time –Scripted Execution of Service Registry Publish 31 Wave 2 – DevOps Goals Realized Remembering to publish the latest service artifacts to the WSRR service registry was proving time consuming. Now done by build engineering using automated reusable scripts! Estimated savings of 1,040 hours per year. Remembering to publish the latest service artifacts to the WSRR service registry was proving time consuming. Now done by build engineering using automated reusable scripts! Estimated savings of 1,040 hours per year. AutomateAutomate
- 32. Simplify – ConsistentApproach Across Stack 32 Wave 2 – DevOps Goals Realized
- 33. Simplify – Results… 33 Wave2 – DevOps Goals Realized • Instead of having this… • We have this… ODMODM BPMBPM WDPWDP PortalPortal WESBWESB WSRRWSRR IIBIIB HPSTHPST DBDB Build engineering work Build engineering snapshots Builds
- 34. 34 • Scope ofthe Third Wave • Many teams included in joint delivery • Overall team increased in size • Included offshore • Oversight is very important Wave 3 – Big Wave Surfing
- 35. 35 • Need toscale to support program of projects • Also scale out to include offshore teams • Support oversight of extended teams by making use of metrics and reports Wave 3 – Methodology and Tooling Goals
- 36. 36 Wave 3 –Methodology and Tooling Goals Realized Multiple Streams of Work – Both Onshore and Offshore
- 37. 37 Wave 3 –Methodology and Tooling Goals Realized Metrics for Reporting on Team Progress • Large distributed team > Increased need for metrics to track! • Short-term solution: Excel-based metric reporting using RTC APIs to get data • Long-term solution: Rolling out Rational Insight
- 38. 38 • Engage teams •Provide requesting mechanism • Keep team in the loop • Keep track of lessons learnt • Provide how-to content Wave 3 – DevOps Goals
- 39. Engage Teams –Requesting Releases 39 Wave 3 – DevOps Goals Realized Create…Create… List of changes to include in release… Scrum masters able to directly request a release, specify what should go into it, and say where it should be deployed. Result: Crisp and precise communications Scrum masters able to directly request a release, specify what should go into it, and say where it should be deployed. Result: Crisp and precise communications
- 40. Engage Teams –Keeping Everyone in the Loop 40 Wave 3 – DevOps Goals Realized Status of releases Breakdown per environment Build engineering dashboard provides live view of all releases. Email notifications inform team of changes. Result: Reduced communication overhead, increased awareness. Build engineering dashboard provides live view of all releases. Email notifications inform team of changes. Result: Reduced communication overhead, increased awareness.
- 41. Engage Teams –“How To” Guidance 41 Wave 3 – DevOps Goals Realized <- Process level content Tool level content -> Detailed guidance for each automation ->
- 42. Engage Teams –Improving Self Sufficiency 42 Wave 3 – DevOps Goals Realized • Searching for build problems… • Provides list of previously noted issues… • From which you can determine previous solutions…
- 43. Engage Teams –The Results… 43 Wave 3 – DevOps Goals Realized Start ReleaseStart Release Observe ReleaseObserve Release Learn How to ReleaseLearn How to Release Improve Release ProcessImprove Release Process
- 44. 44 • Some Thoughtsfor the Fourth Wave • Currently any coordination between deployments across application tiers or across applications is handled manually • It is not easy to see what components have been deployed to which environments, and which version is deployed Wave 4 – Wave of the Future
- 45. 45 Wave 4 –Looking Ahead Assembly action Automation Today RTC Build Engine Deploy action RTC Source Code Management RTC Source Code Management
- 46. 46 Wave 4 –Looking Ahead Assembly action The Future: Automation ++ UrbanCode Deploy RTC Build Engine Deploy action(s) RTC Source Code Management UrbanCode Deploy Inventory of application deployments Deploy process
- 47. 47 Wave 4 –Looking Ahead Intended Benefits from UrbanCode Deploy Deployment is no longer just a step – now can be a process which orchestrates multiple steps Deployment is no longer just a step – now can be a process which orchestrates multiple steps Inventory shows which components of are deployed to which environments Inventory shows which components of are deployed to which environments Assemblies are versioned and stored for future deployments Assemblies are versioned and stored for future deployments Deploy action(s) UrbanCode Deploy Inventory of application deployments Deploy process
- 48. 48 The Fun! Enjoyingthe Improvements Summarizing What We Have Covered 1. Everyone knows what is expected of them in the process – less uncertainty in teams 2. Slick process for moving from service contract design to having service interface framework code delivered into SCM and ready to add code to 3. Reduced the risk and stress involved in producing regular releases to Test 4. Free up a lot of developer and tester time 5. Taken the headache out of application patch deployments 6. Provided a useful secondary communication medium for the offshore team 7. No need to understand a whole new deployment mechanism for each technology – all work in a similar way 8. Looking forward to the additional benefits promised by UrbanCode
- 49. Thank You! Your Feedbackis Important! Access the Innovate agenda tool to complete your session surveys from your smartphone, laptop or conference kiosk.