Tag Archives: DevOps

Review: DevOps a business perspective

9789401803724-480x600Oleg Skrynnik wrote the book DevOps a business perspective. It’s the core literature for the EXIN DevOps Foundation certification and gives a good overview of DevOps.

Definition DevOps: “DevOps is an evolution of the ideas of agile software development and lean manufacturing, applied to the end-to-end value chain in IT, which allows businesses to achieve more with modern information technology due to cultural, organizational and technical changes

The book is built around 6 chapters. The first chapter explains DevOps in general. Next, we get key facts and challenges of lean production and agile as the foundation for DevOps. Followed by an explanation of the five DevOps principles.in a next chapter DevOps is compared with traditional practices and 10 DevOps practices are explained and ends with the practical application of DevOps.

The evolution of Agile software development methods created the need for a new approach to IT management. Management of IT infrastructure as a code enabled by virtualization and cloud computing provided the opportunity for the same new approach to IT management. This new approach was the inspired emergence of DevOps.

Why DevOps:

  • reduce time to market (business idea testing, hypothesis evaluation)
  • Reduce technical debt (the debt occurs when a programmer chooses a non-optimal way to solve a problem in order to shorten the development time)
  • Eliminate fragility (fragile systems first and foremost need stability, they need to be changed as little as possible, and changes should be carefully checked both before and after the intervention)

DevOps is based on five principles:

  • Value stream. Creating value in response to a customer’s request
  • Deployment pipeline. The most automated transition of changes through all steps of the value stream, starting from the Development is complete’ point, down to ‘Deployment into operations’ (including continuous integration, delivery and deployment)
  • Everything should be stored in a version control system: source code, tests, scripts, artifacts, libraries, documentation, configuration files, development tools
  • Automated configuration management. Any changes to any environment can be made only by scripts stored in a version control system
  • The Definition of Done. Creation of new functionality is done only when the application is running in the production environment and all the assembly, testing and deployment activities are done automatically.

Ten DevOps key practices:

  • Unusual teams: not a temporary construct, responsible for a small domain, full time, cross-functional, small, versatile professionals, self-organizing, collocated, responsible for the tool in use
  • Work visualization: helps to build a pull system, improves visibility of tasks in progress, remaining amount of work, prioritization, reduces the number of hand-offs and helps to identify inefficiencies
  • Limit the WIP: helps to build a pull system, improves estimating of the lead time, identification, visibility, evaluation and elimination of constraints, decreases specialists’ work interruptions and work re-scheduling
  • Reduce batch size: reduces total amount of work, lead time and number of defects, and improves the rhythm of the flow, the quality of the products
  • Mind the operational requirements: the product owner as interested in the fully operational IT system, including both functional and other (or operational) requirements
  • Early detection and correction of defects: testers develop tests and the test environments correspondent to the production environment as accurately as possible to support fast detection of defects
  • Managed, not controlled improvements and innovations: banning any normal work during the time allocated for improvement, Kaizen Blitz (with a very definite and tangible result), hackathons
  • Funding that enables innovations: funding of products rather than projects would be more appropriate, and this means a completely different way of budgeting and resource planning
  • Task prioritization based on cost of delay divided by duration
  • Continual identification, exploitation and elevation of constraints

The last chapter describes some practical applicability and limitations of DevOps, consequences when using COTS (Commercial Off-The-Shelf), an evolving architecture towards a microservice architecture, DevOps and ITSM, Cargo Cutting (thoughtless copying), start where you are, progress iteratively and use a value stream as the core for DevOps.

Conclusion: If you want to understand what DevOps really means, this is a good book to start your journey and bring it into practice.

To order: DevOps a business perspective

Book review: The DevOps Handbook

9781942788003-200x300Gene Kim, Jez Humble, Patrick Debois and John Willis are the authors of the book The DevOps Handbook. how to create world-class agility, reliability, & security in technology organizations. If you look at the cover you see some similarities with The Phoenix Project. A novel about IT, DevOps, and helping your business win. And that is not a coincidence because Gene Kim is one of the co-authors of this book too.

Where The Phoenix Project is a business novel explaining the journey to set up a DevOps team, this book gives you the theoretical background, and the tools to build and use the DevOps philosophy by integrating product management, development, QA, IT operations, and information security to elevate your company.

The book is divided into four blocks: The first block (part I) introduces the three ways: The principles of flow, feedback and continual learning and experimentation. The second block (part II) explains where to start a DevOps movement in your organization. The third block (parts III-V) describes the technical practices of the three ways. The last block (part VI) discusses the technological practices of integrating information security, change management, and compliance.

In part II we see what it means to select the value streams with the most sympathetic and innovative groups to start with the DevOps transformation, analyse those value streams by creating a value stream map, and design the organization (functional, matrix or market oriented), fund services and products and not projects and create loosely-coupled architecture to dramatically improve the outcomes.

The first way describes the architecture and principles that enable the fast flow of work from left to right, from Dev to Ops to deliver quickly and safely, value to customers. Start with a single repository of truth for the entire system, make infrastructure easier to rebuild than to repair, enable fast and reliable continuous integration and automated testing and start with low-risk releases. Include running in production-like environments in your DoD.

The second way addresses the reciprocal fast and constant feedback from right to left by implementing feedback loops and use shared goals spanning Dev and Ops to improve the health of the entire value stream. The authors provide insights in telemetry from processes, behaviour and production issues, audit issues and security breaches that enables seeing and solving problems. Next we see, how we can integrate user research and feedback, peer reviews and pair programming and what it means when integrating hypothesis-driven development and A/B testing into our daily work?

The third way helps to create a culture of learning and experimentation. What can you learn from incidents, and how others can learn from your own learning by creating repositories and sharing learnings. How can you enable and inject learning into daily work by establishing a learning culture, have post-mortem meetings after accidents occur and communicate them, decreasing incident tolerances and organize game days to rehearse failures? And make sure you capture organizational knowledge by using e.g. chat rooms and chat bots.

In the last part, the three ways are extended by using them to achieve information security goals by making security a part of everyone’s job, by integrating preventive controls into a repository, by integrating security with the deployment pipeline, and integrating deployment activities with the change approval processes and reducing reliance on separating of duty.

Conclusion

If you want to start a DevOps movement, start with The Phoenix Project to make yourself enthusiastic about DevOps and continue with this book to get the real technical practices to make your DevOps a success. When buying this book, you will get a unique one-time access code to the DevOps X-ray individual assessment to benchmark your own performance against industry-wide data.

To buy: The DevOps Handbook

Book review: The Phoenix Project. A novel about IT, DevOps, and helping your business win

thephoenixprojectThe book The Phoenix Project. A novel about IT, DevOps, and helping your business win written by Gene Kim, Kevin Behr, and George Spafford gives you great insights how to improve the success rate of your IT organization by transforming your organisation in a DevOps like organisation to deliver much faster (more than 10 deployments a day), still staying compliant and with less errors, the features your customers are asking for.

This heavy book, more than 380 pages is written in an entertaining, page-turning style. If you work in IT, you will definitely recognize many situations but also the typical characters in this novel.  It’s written in the same style as Dr. Eliyahu Goldratt’s book The Goal. Which was, as the authors mentioned one of their inspiration sources.

In the book we follow Bill who is an IT manager at Parts Unlimitted. Bill is asked to fix the mess of the Phoenix Project which is massively over budget and very late and will report directly tot he CEO. I fit can’t be fixed within ninety days Bill’s entire department will be outsourced.

Bill will get help from Erik, a prospective board member who teaches Bill that IT work has a lot in common with manufacturing plant work. Erik takes Bill several times to a manufacturing plant to show what he means.

We follow Bill and his team taking the five steps of the Theory of Constraints as described in The Goal.:

  • Identify the constraint
  • Exploit the constraint
  • Subordinate all the other activities to the constraint
  • Elevate the constraint to new level
  • Find the next constraint

In this story it becomes clear that a developer Brent is the constraint. He is needed for every small or big change and the team puts all kind of measures in please like putting a Kanban board around his activities, prioritizing the work, reducing his workload et cetera.

During the journey we see Development, Quality Assurance, Compliancy, Operations working more and more together and becoming what we would call a DevOps organization.

Step be step Bill starts to understand that he has to create and integrate three ways of working:

  • The first way is a left-to-right flow of work from Development to IT Operations to the customer. This flow needs to maximize by managing the Work In Progress (WIP) and have continuous build, integration, and deployment practices.
  • The second way is about the constant flow of fast feedback from right-to-left at all stages of the value stream.
  • The third way is about creating a culture that fosters two things: continual experimentation, which requires taking risks and learning from success and failure and understanding that repetition and practice is the prerequisite to mastery.

To understand the flow with the IT value stream Bill had to find out that there are four types of work: Business projects, Internal IT projects, Changes and Unplanned work or recovery work. See attached figure.

Dia1Following Bill we get, on one hand, a great story about his struggle to drastically improve the way the work within Parts Unlimitted and you, as reader, wants to know how he succeeds and on the other hand we get fantastic insight in the world of DevOps.

The final forty pages is called The Phoenix Project Resources Guide. Why do you want to implement DevOps and where DevOps came from? Explaining the three ways and the four types of work as well as a demystification of some of the top DevOps myths. The last chapter is a list of recommended reading and further resources to learn more about DevOps philosophies, tools, and techniques that were used in the book.

I would say a must for those who are entering the world of DevOps.