Presented at the IBM Innovate 2014 conference in Florida.

1. © 2014 IBM Corporation
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 Kamakawiwo oleʻ
Louis Armstrong
Judy Garland
The Performers

4. The Writers
“What a wonderful world”
George David
Weiss
Bob Thiele
“Somewhere over the rainbow”
1939
1967

6. Over 500 digital music 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 ESB Architecture
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 approach to 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 of the 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 site support
– 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 Development for 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 – The Promotion 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 – Common Tooling
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 of the 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 out approach 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 – Consistent Approach Across Stack
32
Wave 2 – DevOps Goals Realized

33. Simplify – Results…
33
Wave 2 – 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 of the 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 to scale 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 Thoughts for 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! Enjoying the 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 Feedback is Important!
Access the Innovate agenda tool to complete your
session surveys from your smartphone, laptop or
conference kiosk.