Upload
ghodgkinson
View
39
Download
0
Tags:
Embed Size (px)
Citation preview
© 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 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
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
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
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!
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
Wave 1 – DevOps Goals Realized
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
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.
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.
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.
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
• 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
Wave 2 – Methodology and Tooling Goals
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
Wave 2 – DevOps Goals
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
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
Simplify – Results…
33
Wave 2 – DevOps Goals Realized
• 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
Wave 3 – Methodology and Tooling Goals
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
Wave 3 – DevOps Goals
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
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.
Engage Teams – “How To” Guidance
41
Wave 3 – DevOps Goals Realized
<- Process level content
Tool level content ->
Detailed guidance for each automation ->
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…
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
• 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
RTC Source Code Management
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
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