Abstract
|
Reading time for this article is less than 5 minutes. The United Kingdom consists of Northern Ireland, Wales, Scotland, and England; as of this writing, the United Kingdom is in the European Union (EU). On the coast of Northern Ireland there is a major EU port of entry – Dover. And being part of the EU, Dover has an importation process that is fast, seamless and continuous due to the trust between the 28 EU trading partners.
|
The speed of this importation process is particularly vital for perishable goods like fruits, vegetables and flowers. However with Brexit on the near horizon, the United Kingdom will no longer be part of the EU. As a result, Dover is now looking at a “hard” border that requires trade custom inspections (i.e., the importation lead time could be extended from seconds to days).
|
The above story reflects a business
with DevOps, and then without.
|
DevOps is based on a culture of trusted partners. This partnership is between software development, quality assurance, security and controls, and operations. The result is a smooth and fast transition of software from development to operations. However, like Dover, if the trusted partners are somehow reorganized into formal handoffs each with their own software acceptance procedures, the movement of software is no longer smooth nor fast.
Waterfall and the Gates Below
For years, we used the Royce waterfall solution development life cycle (SDLC) in developing software. Waterfall originated from construction and manufacturing. And, it worked [1]; the process is to elicit “all” the requirements upfront, develop, design, and test the software; and “voila” the software is “delivered” and “ready” for deployment.
|
So the software is “ready”, but still needs to be promoted through a set of risk gates of deployment. The focus of the gates is to guard [2] production to ensure there is a secure, stable, and high service level environment. Typically the gates are:
- Quality Assurance – functional, nonfunctional and data integrity,
- Security and Controls – compliance with industry standards,
- Operations – availability conformance per service level agreements.
|
Note that each of these risk gates are after development. Each having rigid review procedures that may cause delays or bottlenecks due to failed tests, standards inspections, and possibly even fulfilling requests for enhancements and new features.
Agile, but Gates Remain
Years later came the agile manifesto. Agile is a successful SDLC that embraces change; it is known as a better way to manage unstable requirements and provide shorter delivery times. And it works; the process is to elicit “some” of the requirements in small iterations while eliciting the “rest” of the changing requirements, and “voila” the software is “delivered” and “ready” for deployment. However the deployment gates, as in waterfall, still persisted.
Why the Risk Gates?
What caused these gates to exist? Negative experiences. Here are a couple of examples:
- Functional errors: software has to be pulled back from production. Management responds and establishes a separate quality assurance gate for independent testing.
- Security breaches: production must be immediately protected. A breach causes a loss in business brand value and customer data. Management responds and establishes a separate security and control gate for independent security and control review and improved standards.
- Service Outages: service level agreement is not met. Management responds with restriction on duration of migration windows and an annual customer service survey.
The bottom-line is there was a loss of trust because of negative experiences. Therefore, management pursued organization changes [3] which added handoffs (like separate companies) in the deployment process. However, management may have pursued these organizational changes without considering the impact to the lead time of the deployment process, certainly without the insight to the future “first to market” ecosystem and the competitive need of continuous customer feedback.
What is DevOps?
|
Development-Operations (DevOps) is a “trust development-operations life cycle.” It is an integration of development and several post-development activities such as security and controls, quality assurance (testing), and operation deployment. By working together, a continuous work flow (pipeline) can be realized resulting in fast deployment with continuous customer feedback.
|
What is new is that DevOps is a
partnership between development and interface activities [4] to operation deployment (i.e., no longer transactional and after development). In the vernacular, there are no longer post-development risk gates, but activities as part of development. Development and other business units now act as a single company with a common goal in serving their customers. The market motivates this partnership in order to meet the needs of businesses to answer customer requests on being more flexible, agile, and react faster to a first-to-market world. Examples of a company that have faced this challenge with DevOps are: Facebook, Netflix, Google, Amazon; these global companies can deploy literally thousands of software updates [5] on a daily basis via Dark Launching. [6] Their measurements of improvement by implementing DevOps are:
- More frequent deployment with shorter lead times
- Few failures with faster recoveries [6]
- High automation of deployment
In DevOps We Trust
However in DevOps, trust partnership is the vital requirement, but not the only requirement. DevOps includes the practices of:
- Lean – the elimination of waste in a continuous value stream [8]; the value stream in this case being sequence of activities of developing through operation deployment
- Agile
- iterative and incremental development of software features [9]
- visibility of the work activities in a continuous value stream of work activities via a Kanban board with Work In Process limits (WIP)
- System Thinking – viewing the entire process (holistically), how each activity impacts the entire value stream
-
and a toolchain [10] of supportive products that automates an incremental infrastructure for software development and deployment pipeline such as:
- Git – version control and rollback
- Gradle – building code and packaging
- JUnit – testing code
- Jenkins – integration of increments
- Puppet – deployment
- Nagios – monitor performance
Summary
In summary, DevOps is a combination of several concepts that allows fast development and deployment with continuous customer feedback. There are several successful companies that have implemented DevOps and have realized fast deployment and recovery times with fewer failures.
In Pursuit of DevOps
The purpose of this article is to define DevOps. See the references concerning how it works in various implementations. If you intend to pursue DevOps, be aware it is not so much of a technical challenge.
|
In the words of Wilbur Wright, co-inventor of the airplane, “...it is always easier to deal with things than with men.....” You don’t have to convince software, hardware, or even processes, but people are a bit of a challenge. See Kotter’s book in references for steps in managing resistance. Below is a short discussion on how to pursue DevOps.
|
First Step
The main challenge in pursuing DevOps is
establishing trust within the organization. This is particularly true if there is staff and management resistance due to past negative experiences (deployment failures) that established and reinforced the need for risk gates as stated in this article. This means that as a first step the DevOps promoters need to communicate to all the stakeholders involved: “What is the
urgency for implementing DevOps in my firm?”
- Slow in meeting customer demand (customer feedback)
- shorter lead times in developing and deploying software
- faster response in building enhancements and new features
- Keeping up and/or beating competition in the marketplace (first to market)
-
Already losing market share (declining sales)
References for Further Research
- Kim, Gene, Jez Humble, Patrick Dubois, and John Willis. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations: IT Revolution Press, LLC, 2016.
- Kim, Gene, Kevin Behr, and George Spafford. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win: IT Revolution Press, LLC, 2014.
- Kotter, John P., Leading Change, Harvard Business Review Press, September 1996.
|
Author: Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance. He holds an Advanced Master's Certificate in Project Management and a Business Analyst
|
Certification (CBA®) from George Washington University School of Business. Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) and the International Association of Facilitators (IAF).
Mark is the President of Monteleone Consulting, LLC and author of the book, The 20 Minute Business Analyst: a collection of short articles, humorous stories, and quick reference cards for the busy analyst. He can be contacted via - www.baquickref.com.
References / Footnotes:
1. Royce recognized there would be caveats concerning software development. Waterfall has development problems due to the creative nature of building software (i.e., unstable requirements, resulting in longer and longer delivery times).
2. A very different example is auditing. Just to be clear, the purpose of an auditor is to provide an independent review of best business practices, not to help build the delivery. If auditors help build, they lose their status as independent reviewers.
3. Some of these changes were also the result of well intended quality programs without regard to the lead time and money process impact (unintended consequences).
4. Note the flow of work can be in both directions – not just from development to other activities for deployment. The flow of work could be in the opposite direction in the form of requests from quality assurance, security and controls, and operations for continuous process improvements.
5. To allow for high update frequency, these companies use a microservice architecture where each microservice is autonomous and loosely coupled to implement a specific function. When development needs to change or scale-up/down an application, it only needs to update the affected microservice instead of the entire monolithic application.
6. Dark Launching is a technique using toggle switches in software. Its purpose is to turn features on and off in production for certain pilot customer segments prior to full deployment. It allows continuous:
- Development of software features with version control
- Testing of feature iterations
- Integration and testing of various features together
- Monitoring of production services
7. Historically, operations has measured performance in terms of availability. However in a 24/7 world, operations are now shifting to measure recovery time following an outage instead. Businesses that have implemented DevOps are quicker to recover from outages.
8. A value stream is a sequence of added value activities that result in a customer product or service. This is opposed to a value chain which is also a sequence of added value activities plus management controls that result in a customer product or service.
9. Agile is a SDLC. It is an iterative and incremental software delivery method, but does not include the deployment of software to production.
10. The toolchain provided is only an example. There are several alternative tools on the market. Details of each of these tools can be found on the Internet.