The term "DevOps" refers to tight integration between the Software Development and Operations parts of an organization.

Holistic Software Development fully embraces close collaboration and a holistic approach to developing systems that involves all stakeholders, including developers and operations. As such HSD is a DevOps process however we do not treat Development and Operations as separate parts of an organization - instead we address the entirety of the Software Development Business that includes Development, Operations, Business Strategy, People issues, Quality Assurance, Portfolio Management etc.

The purpose behind the DevOps movement is to ensure that Operations stakeholders are engaged throughout a software development lifecycle so that operational requirements (especially  Non-functional requirements) are included properly. In line with this idea Operations stakeholders, and Operational constraints, must be included in top level requirements and well represented throughout development activity. Operations work, like testing, happens throughout the software lifecycle, not afterwards. Operational stakeholders are involved in the Portfolio Build/Selection practice to ensure that the impact of new product development or maintenance decisions on current Operational positions, and Enterprise Architecture, are understood. Significant changes to current Operational positions are raised as Portfolio Requests so they can be properly costed and scoped.

Work aligned to the principles of HSD must by definition include addressing the needs of all stakeholders from any part of the business. If a divide exists between parts of the business, then the dysfunctional relationship (an example of Conway's Law) needs addressing rather than process and tooling being introduced. Processes and Tools are helpful to gain agreement on a common approach and automate ways of working but not to solve dysfunctional relationships.

Since HSD promotes regular builds and releases in either iterative/agile or continuous flow models Operations stakeholders must be involved early and often in software development product delivery as a product is likely to be delivered frequently, or even continuously, and so will need transitioning activities performed repeatedly. We recommend treating transition to live environments as a top level Integration Stream and automating transition where possible.

• Cultural
  • We promote trust, close collaboration and fast-fail. Most importantly we focus on flow and pull throughout an organization.
• Requirements
  • Operational requirements are explicitly covered by non-functional requirements when examining Architectural Profiles.
• Environments and automation
  • We strongly recommend automation of environments, build and deployment

Please share this page