The document discusses the concept of enterprise DevOps, emphasizing better software delivery practices and the end-to-end process from requirement to production. It offers ten key tips based on the author's experience to help organizations implement DevOps successfully, including defining goals, understanding application pace, and improving collaboration across teams. Additionally, it highlights the importance of adapting best practices to align with unique organizational needs and continuously improving tools and processes.

1. Enterprise DevOps from the trenches
Jonny Wooldridge
Head of Web Engineering @ M&S
&
Chief Geek @ enterpriseDevOps.com
15th May 2014

2. Intro

3. Aims of the next 30 minutes
Our definition of Enterprise DevOps
Why is Enterprise DevOps relevant to you?
10 Tips from 3+ years of getting DevOps working in an
Enterprise

4. I’m not trying to sell you a ‘DevOps’ Tool.
I’m not trying to sell you my latest book.
I have a family and a day job, so forgive the odd spelling mistake!
Word of warning
These are my personal views, not the views of my employer. If you
have a different view on anything in this presentation, I’d love to
hear from you!

5. Me
2000-2003
Web Master / Lead Java Developer
2003-2007
Lead Developer / Head of Development
2008-2011
Director of Platform Development
2011+
Head of Web Engineering

6. Definition of Enterprise DevOps?
It is about better software delivery practices
It is end to end – from requirement to production
It is about best practice in connected tooling
It is about being fast and lean
It is understanding the operational requirements of a system
and making it easier to support/deploy
It is understanding the trade offs. You can’t automate the
entire Enterprise in one go.
It’s about evangelising the power of great software
engineering practices.

7. Why (I hope) this is relevant to you?
Your start-up might be the next enterprise!
Enterprise experience is 100% relevant to a start-up
What can you do now to maintain DevOps momentum
and not slow down as you grow?
Being good at software engineering cuts across all
aspects of an organisation, of any size.

8. TIPS/LESSONS LEARNED

9. Define what you are trying
to achieve and why?
TIP#1

10. Define what you are trying to achieve and why.
Plan your attack: It may be boring but you need a plan and
define clear goals explaining the benefits of a DevOps
approach in the enterprise. What is your definition and how
exactly will that be the game changer? Spell out the benefits but
also create a sense of urgency as moving to a better software
engineering approach in your enterprise is non-negotiable.
Keep it simple: There will be a lot of people who will not
have even a basic understanding of the steps required to make
great software. They may have had experience in the past of a
bit of coding or might have some understanding of Ops but
assume that they know nothing. Knowing a little bit from 10
years ago is actually worse than knowing nothing so be sure to
explain how the industry has moved on.

11. Define what you are trying to achieve and why.
Show it working…: You can have all the powerpoint
presentations in the world describing your approach and the benefits it
will bring but in an enterprise people won’t get it until you actually
show something actually working. Choose an application that they are
familiar with.
… and supplement with diagrams and animations.
People in the enterprise are less likely to get excited by the latest
scripting platform, test automation tool or cloud service! That is until
they realise what benefits it has for them or their team. Show it in
pictures and compare and contrast old ways of working.
Make it clear that you care: In an enterprise you will find that
if you clearly articulate that you care that software engineering is done
well and can prove how ultimately it will make the organisation run
better other teams will soon start to come to you for thought
leadership

12. Define what you are trying to achieve and why.

13. Be an expert at the basics:
Greater productivity through reliability: DevOps is an
investment in tools, processes and people throughout all phases of a project to
provide repeatable, reliable, and secure environments.
Standard
Developer
Machines
Continuous
Integration
build systems
‘DoD’ *
throughout
lifecycle
Standardised
Binary
Deployment
Robust Source
Code
Management
Reliable
Environment
propagation
Security
Standards
Coding &
Testing
Standards
* Definition of Done
Define what you are trying to achieve and why.

14. Define the pace of your
apps
TIP#2

15. Define the pace of your apps
Danger: Don’t assume they all go at the same speed!
Define you path to production which will help you….
Define what paces you have. As an example:
FAST - applications you can continuously deliver that are
decoupled and have a great % of automated tests
MEDIUM – applications that are coupled and need end to
end regression testing (hopefully mostly automated)
SLOW – Projects dependent on Corporate Release Cycle
(SAP etc.)
Put in place different governance for different paces
Understand your pace dependencies

16. Define the pace of your apps
Ecommerce Engine
Basket, offers, personallisation,
up-sell, payment
Digital Assets
Image and video storage
Content Mgmt.
Page Content & Templates
Search System
Facetted navigation, search
Apps Web
Staff Apps
Responsive
Adaptive
RESS
IOS
Android
ReportsFront End User
Interface
API
Customer Mgmt.
Customer contact, CRM
Communication
Emails, text, chat
Connectivity Layer (enterprise service bus)
Routing, security, transformation, connectivity
Order Management
Orders, refunds, cancelations,
stock, fulfillment, POS
Product Information
Product Catalog and Attributes
Delivery Systems
Courier/Standard delivery/Labeling
Payment Systems
Finance
Systems
Fast
Medium
Slow
Frequency of change:

17. A typical start-up route to production
Start-up*
★★★★
Stage 1 > Stage 2 > Stage 3 > Stage 4 >
Development
Continuous
Integration
Staging /
Performance
Production
Define the pace of your apps
Relatively Easy to continuously deliver
Into this environment– buy the book!
* Assumes a startup-up with a non-complex architecture
Fast
Frequency of change:

18. Are you brave enough to do continuous deployments for
a payment module that your whole £multi-billion business
relies on?
Not all apps should be treated in the same way.
How well de-coupled are they? Automated tests?
Define the pace of your apps
Slow
Frequency of change:

19. Define the pace of your apps
Development
Continuous
Integration
System Test
Product
Group SIT
Fully connected
Corporate SIT
Staging
/ Performance
Production
Decoupled
Isolated
Project
Corporate
★★★★
★★★
★★
★
ContinuouslyDeliverySlider
Continuous
Continuous
Continuous Continuous
Continuous Continuous
Continuous Continuous
Continuous Continuous
N/A
N/AN/AN/A
N/AN/A
Standard Standard Standard
Standard Standard
Standard Standard
Continuous StandardKey:
An environment continuously
deployed to
An environment where deployments
Are managed in a standard way
Standard
Different Release types affect how fast your apps can go into production

20. Define the pace of your apps
The idea being that you should always aim to
continuously deliver your apps into production
HOWEVER, if there are reasons why you can’t or
don’t want to, make sure you can continuously deliver
your apps into lower environments.
Factors influencing how far you go with Continuous
Delivery:
how many environments you have
how well you have control over the deployments made into
those environments
how many other teams are sharing the environment

21. Kill dependenciesTIP#3

22. Kill Dependencies
– Obsessively understand and control your dependencies
– Decouple your apps & architecture – create services
– Decouple your people – give them more responsibility E2E
– Integrate with 3rd parties carefully
– Stubbing is a solution
– Less Dependencies = Easier Testing

23. Focus on MVPTIP#4

24. Focus on Minimal Viable Products
– What is the minimum you could go live with that will
add value for your customer
– See if it works then improve it
– A change to culture and requirements only but has a
massive impact on solution
DevOps is therefore End 2 End from requirement to
production

25. Be aware that DevOps affects
every aspect of your organisation
TIP#5

26. DevOps affects every aspect of your organisation
– Technology and Architecture choice
– HR, recruitment and rewards
– Finance – funding allocation and Total cost of
ownership
– Governance
– Auditors – should love DevOps btw ;-)
– Suppliers & Contracts – which projects to
offshore?
– Ways of working – always can improve

27. DevOps affects every aspect of your organisation
Stage 1 > Stage 2 > Stage 3 > Stage 4 > Stage 5 > Stage 6 >
Development
Continuous
Integration
System Test
Product
Group SIT
Corporate SIT
Staging
/ Performance
Production
Decoupled
Isolated
Project
Corporate
★★★★
★★★
★★
★
CAB
CAB CAB
VS
Same Day
Every
Quarter
Angular.js, bootstrap.js, mongodb, Scala
BDD and Continuous integration,
Struts, mainframe, test data issues, infrastructure
SLAs
Affect on recruitment
Do more with Less

28. You are unique.
Think for yourself.
TIP#6

29. You are unique. Think for yourself
Take guidance from best practice, but don’t be afraid to
innovate
What’s appropriate for you may not be appropriate for
somebody else
Having a DevOps Team might be an ‘anti-pattern’ but it
might work for you:
To build frameworks to empower agile teams to do their own
devops
Provide shared tooling where it makes sense
Sort out contractual arrangements for the enterprise for cloud
and tooling providers

30. Make your tools work for
you.
TIP#7

31. Make your tools work for you
Make your tools work for you, not the other way around
Embrace OpenSource it’s generally years ahead of the
main vendor thinking
Don’t believe the hype
Why has the GUI seduced you?
Deployment for Dummies? If you can script it, why do you
need an expensive tool?
TOOLS GAP: one area that is lacking in OpenSource is
visibility of your working pipelines – how are the
deployments progressing? What stage are they at? What’s
the status?

32. Build a Software FactoryTIP#8

33. Build a software factory
Build a software factory
What is a factory? Let developers focus on the creative aspects
of writing code, not how their code gets into environments for
testing
Connect your tooling to get value
EXAMPLE: what’s in a build, differences between two versions
Don’t forget security! Add them into your build pipeline.
Maintain ownership of your delivery pipeline at all costs
Force all suppliers through your pipe without exception
Get visibility of every code commit
Out source your dev, but keep them honest by making
everybody come through your factory Machines.

34. Build a Software Factory

35. Don’t (just) focus on
Deployment automation
TIP#9

36. Don’t (just) focus on Deployment
automation
Requirement to Production
Risk of local optimisation
Make it as fast as possible but be realistic
Testing is the real problem – and how do you scale it
Requirements – INVEST sessions

37. Think like you’re the Enterprise
of tomorrow
TIP#10

38. Think like you’re the Enterprise of tomorrow
Make the right choices with:
Technology
Hiring
Contracts
3rd Parties
Make the wrong choices and your DevOps dreams can be shattered

39. We need each other
Thanks for listening!