Broadcast Music Inc - Scaling Up, Doing More, Having More Fun!

© 2014 IBM Corporation

1867, Broadcast Music – Scaling Up, Doing More, Having More Fun!Greg HodgkinsonPractice Director – Lifecycle Tools and Methodology, Prolifics

Jim HarveySenior Director of Business Analysis and Quality Assurance, Broadcast Music Inc.

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

The Performers

Israel Kamakawiwo oleʻ

Louis Armstrong

Judy Garland

The Performers

The Writers

“What a wonderful world”

George David Weiss

Bob Thiele

“Somewhere over the rainbow”

1939

1967

Over 500 digital music services worldwide offer consumers the opportunity to legally

access up to 26 million songs© 2012 Pro-Music

IBM

Prolifics Best practices Guidance

Integration Technologies

Implementation

8

Overall Architecture

SOAP/HTTPSOAP/HTTP

Federated ESB Architecture

WebSphere Service Registry and Repository(WSRR)

Data transformations

Portal, BPM and Mobile Consumers

SOAP/HTTP SOAP/HTTP (S)(S)

ReST/HTTP ReST/HTTP (S)(S)

JDBCJDBC

SOAP/HTTP SOAP/HTTP (S)(S)

Security (authentication and authorization)

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

• 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

• 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

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 RealizedGetting Started with Agility@Scale

RSA Model-Driven Development for Tighter Control

13

• Solution architecture modelledin 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 storedin RTC

Wave 1 – Methodology and Tooling Goals Realized

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

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

Saving Time – Scripted Deployment of Code

16


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

Saving Time – The Results…

17


• 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!

Simplify – The Promotion Pipeline

18

Wave 1 – DevOps Goals RealizedD

EV

DE

V

INT

INT

TE

ST

TE

ST

PR

OD

PR

OD

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.

Simplify – Common Tooling

19


Importantly, the build engineering team utilizes the same tooling stack as scrum masters, developers and testers: Rational CLMResult: Better integration between teams activities.

Importantly, the build engineering team utilizes the same tooling stack as scrum masters, developers and testers: Rational CLMResult: Better integration between teams activities.

Added Value – Enabling Rollback

20


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.

Added Value – Leaving an Audit Trail

21


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.

Added Value – Solving the Traceability Problem

22


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.

Added Value – The Results…

23


• Instead of having this…

• We have this…

• When did I deploy?• What was in the deployment?• Where have I deployed to?

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

• 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


26

Wave 2 – Methodology and Tooling Goals RealizedInterdependent Projects in RTC

27

Wave 2 – Methodology and Tooling Goals RealizedFocal 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

Wave 2 – Methodology and Tooling Goals RealizedJoining Up BlueWorksLive and RRC

ActorActor

Story/FeatureStory/Feature

TermTerm

Non-Functional Requirement

Non-Functional Requirement

Business RuleBusiness Rule

ProcessProcess

IntegrationSpec

IntegrationSpec

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

• Save time• Include automated testing• Include automated service registry

publish

• Simplify• Apply consistent approach across

technology stack


Saving Time – Scripted Execution of Automated Tests

30


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

Saving Time – Scripted Execution of Service Registry Publish

31


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

Simplify – Consistent Approach Across Stack

32


Simplify – Results…

33


• Instead of having this…

• We have this…

ODMODM

BPMBPM

WDPWDP

PortalPortal

WESBWESB

WSRRWSRR IIBIIBHPSTHPST

DBDB

Build engineering work

Build engineering snapshots

Builds

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

• 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


36

Wave 3 – Methodology and Tooling Goals RealizedMultiple Streams of Work – Both Onshore and Offshore

37

Wave 3 – Methodology and Tooling Goals RealizedMetrics 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

• Engage teams• Provide requesting mechanism• Keep team in the loop• Keep track of lessons learnt• Provide how-to content


Engage Teams – Requesting Releases

39


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

Engage Teams – Keeping Everyone in the Loop

40


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.

Engage Teams – “How To” Guidance

41


<- Process level content

Tool level content ->

Detailed guidance for each automation ->

Engage Teams – Improving Self Sufficiency

42


• Searching for build problems…

• Provides list of previously noted issues…

• From which you can determine previous solutions…

Engage Teams – The Results…

43


Start ReleaseStart Release Observe ReleaseObserve Release

Learn How to ReleaseLearn How to Release Improve Release ProcessImprove Release Process

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

Wave 4 – Looking Ahead

Assembly action

Automation Today

RTC Build Engine

Deploy action

RTC Source Code Management


46

Wave 4 – Looking Ahead

Assembly action

The Future: Automation ++ UrbanCode Deploy

RTC Build Engine

Deploy action(s)


UrbanCode Deploy

Inventory of application deployments

Deploy process

47

Wave 4 – Looking AheadIntended 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

The Fun! Enjoying the ImprovementsSummarizing 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

Thank You!

Your Feedback is Important!

Access the Innovate agenda tool to complete your session surveys from your smartphone, laptop or

conference kiosk.

Software

Broadcast Music Inc - Scaling Up, Doing More, Having More Fun!