the business case - compliant database devops solutions ......the business case: how to convince...
TRANSCRIPT
The Business Case:How to convince business stakeholders to invest in a devops culture and set yourself up for success in three months!
Ike Ellis@ike_ellisCrafting BytesWe’re hiring a Data Experts!Microsoft MVPChairperson of the San Diego TIGBook co-author – Developing Azure Solutions Upcoming course on Azure Databrickswww.craftingbytes.comwww.ikeellis.com
Today and Week 1Plan and Pitch
How do I convince a reluctant leader that we should go to devops for the database?
How do I fix a cowboy culture?
Convince a leader of the need of devops and change the culture?
This is very difficult!!!!
That’s a culture change that you are solely in charge of.
How was that? Those of you who were
successful, was it easy?
So how do you get someone else to change?
Enron had a nice-sounding value statement that was based on four values:
• Integrity• Communication• Respect• Excellence
Did that affect Enron’s culture?No. Netflix submits that only three things control culture:• Who we hire• Who we fire• Who we promote
You can’t hire, promote, or fire a reluctant boss
So what do we do?
Bad Consultants
Every boss (and in fact everyone) listens to the same
radio station
What’sInIt
ForMe
Every leader I’ve ever met has the same few things in
common•A lingering project•A lingering problem•A publicly embarrassing event
So tune in to the radio station and calm their fear
• We can deliver faster• We’ll deliver more frequently• We’ll have fewer bugs• We’ll have more success
How do we convince reluctant team members?
CHANGE IS HARD! DEVELOPING NEW HABITS ARE HARD!
Steps to developing new habits:Step 1: Focus on One New Habit at a timeStep 2: Form a new habit? Commit to 30 days per new habitStep 3: Anchor Your New Habit to an Established Habit. Step 4: Take Baby Steps. Don’t be too hard if you misstep or step backwards…stay determined to baby step forwardStep 5: Make a Plan for Obstacles. Step 6: Create Accountability for Your Habit. Step 7: Reward Important Milestones. Step 8: Build a New Identity.
People fear change
Phrases of Fear• We tried that and we failed• That will never work here• This is just the latest fad, our processes are tried and
true• Our company is always 10 years behind the industry• I have too much to do and this will slow me down• Just another kitchy program that will eat up all our
time
But we can address their fears and slowly introduce change so that they are comfortable with it
CULTURE TIP: Make Posters
Culture TIP: Throw a Pizza Party!
Culture TIP: $15 Tee Shirts!
CULTURE TIP: Fire someone
CULTURE TIP: Make a new logo!
LEARN ON THE LOO!
• Teach DevOps Best Practices• Teach how to use Source Control• Teach good testing techniques• Teach culture
Culture TIP: BATHROOM SIGNS!
Standardizing source code only
Pros• Provides audit trail of
development changes• Manages collaboration
of team members• Standardizes coding
practices
Cons• Manual database code
validation, testing, and deployments
• Requires a custom process to prevent environment drift
Elevator pitch template:“We are doing _____ so that _____.”
“We should standardize database code and automate deployments to reduce feature time to market.”
Rapidly refresh development databases with real-world datasets
Easily support dedicated environments that isolate changes made in branches and allow experimentation
Mask sensitive data upon image creation
SQL Provision adds speed & safety
Should monitoring be in your initial project?
Pros• Visibility into production
health• SQL Monitor shows when
deployments have occurred, making it easy to track customer impact (good and bad) of changes
Cons• If an external team in
your organization already controls monitoring, proposing a change may be tricky
Once scoped, kick off any required security assessments
First MonthInitiate Changes in a Proof of
Concept (POC)
Crafting executive summary
Industry standards for success criteria
Sample schedules & help keeping the team on track
In a supported POC, ask for guidance from Redgate
• Executive Summary• Business Need• Solution to be Proven• Success Criteria and Long
Term Gains
• Prerequisites• Schedule• Team• Other Resources• Risks
Elements of a technical project pitch
Keeps your team moving in syncHelps key stakeholders understand• Target project duration• Key milestones• Proof of concept schedule and core meetings
Project schedule
Who might this project resonate with in your organization?
• C-Level• Executive & Senior Managers• Department Heads
Identify and approach potential sponsors
Help build a coalition of managers and peers
Be visible to employees throughout the project
Communicate the ‘why’ of the change to employees
Key actions for a sponsor
https://www.prosci.com/resources/articles/change-sponsor-checklist
Engage with employees with face-to-face messaging• Video and recordings work when in-person isn’t possible,
these are more effective than emails aloneAnswer questions about the business issues
• “Why is this change happening?” • “What is the risk of not changing?”
Messages from sponsors
https://www.prosci.com/resources/articles/change-management-communication-checklist
The goal of a Proof of Concept is demonstrating that the tools achieve your
success criteria
This team will:• Explore methodologies to standardize database code and
choose the best approach for your teams• Set up a proof of concept (POC), safely outside of production• Explore and test automation for provisioning, builds (code
validation) and change deployment
Choose your technical champions
It must be safe for the team to make a big mess during the process
It must be safe to fail and start over and try again
A rule for any POC
Causes of failed proof-of-conceptsNot a joint ventureKey stakeholders not involvedThink it will be more labor intensive than it isDevelopers leading without manager buy-inToo much focus on tech benefit vs business benefitBiting off too much at a time
Avoid these anti-patterns
Months 2-3Map Process Changes and
Land Your POC
The two-three month timeline applies if:• Your internal point team has other duties• You only get a few hours of their time each week
Dedicated resource teams have completed Standardize, Automate & Protect POCs in two weeks
A POC doesn’t take 2 months of sustained work
What happens when a build fails, and how do we
respond?
When will the risk of changes be assessed? Pull requests? Release
artifacts?
How often will deployments to
databases be done?
Can security assessments be moved
into checklists?
How many changes should be shipped in a
single deployment?
What approval processes are best for
deployments?
SDLC process changes to map
What team on-call rotations are needed?
How to avoid single-points of failure in the team?
How/when to escalate to subject matter experts?
Support practices to map
Shifting change review and approval to earlier in the development cycle speeds you up
First steps: can standard (pre-approved) changes help get you started?
Sponsorship: this is one place where a sponsor who can help you build a coalition will help
Shifting change approval left
• Collate results from POC and implementation plan• Finalize licensing• Set target implementation date and schedule first call and
support session• Internal presentations about business benefits
Completing your Proof of Concept
When an executive sponsor has been involved from the start, POC sign-off and completion
goes very smoothly
Ike Ellis@ike_ellisCrafting BytesWe’re hiring a Data Experts!Microsoft MVPChairperson of the San Diego TIGBook co-author – Developing Azure Solutions Upcoming course on Azure Databrickswww.craftingbytes.comwww.ikeellis.com