What is DocOps?

DocOps (Document Operations) is primarily a response to the necessities of the large enterprise, which is characterized by a numerous and geographically dispersed workforce. 

DocOps and Outsourcing

Large enterprises are characterized by the significant amount of work that they outsource to vendors and contractors. In the words of Choo (2002), “Today’s organizations are no longer circumscribed by walls and boundaries. Their borders are porous, through which materials, energy, and information continuously flow. Instead of trying to do everything, they now parcel out their work to other organizations so that each can maximize its strengths and advantages.”

The fundamental problem in the traditional outsourcing model is that entire chunks of enterprise knowledge are handed over to vendors, making it difficult for vendors to collaborate among themselves, and a challenge for the contracting enterprise to supervise their work.

In the DocOps model, in contrast, by adhering to the principle of co-creation, vendors are required to operate on a common knowledge base, in which information matches up with already existing information and vice versa. Moreover, DocOps promotes the extraction of knowledge from systems of facts—embodied in the principle of documentation as a property—which reduces the chances of content gaps, negligence, and creative obfuscation. 

DocOps and Agile

DocOps is for the agile enterprise. In the traditional waterfall model, there are dedicated stages whose outputs are ‘documents’ such as formal requirements, design, operation manuals, runbooks, and so on. DocOps is not necessarily about generating such documents in an automated fashion—it can do that too—but rather, about challenging their need in the first place.

In the agile enterprise, software is built multiple times per day. In a DevOps-enabled enterprise, it is also deployed into production several times a day (Bass et al, 2015). DocOps is not concerned with ‘documents’ per se, but with filling knowledge gaps. As such, documentation in DocOps is a continuous process without—necessarily—any deliverables, ‘hand offs’, ‘sign offs’, and so on.  

DocOps spans the entirety of the software development lifecycle (SDLC), engulfing DevSecOps, CI/CD, and Agile, but it has a special role in enabling and facilitating agile development practices by providing continuous understanding. Therefore, it is notably relevant in areas such as business strategy, business architecture, and program management which are not naturally seen as technology-enabled.

While DocOps is all about agility, it emerges as a solution to address the unspoken gap found in conventional methodologies such as XP, Scrum, and sAFE: user stories are insufficient as a sole and primary device to specify and drive change in the enterprise. XP, in particular, with the notion of pair programming and knowledge cross pollination through proximate interaction is conspicuous for its inadequacy in the post-pandemic, ‘remote-first’ world we live in today.

See more : Cancel MuseScore Subscription

DocOps and The Enterprise Context

DocOps is concerned with the overarching structure of the enterprise: what APIs are available, how the CRM application works, the countries in which it operates and so on. DocOps aims to solve problems like this in a holistic manner, without the reintroduction of waterfall processes such as lengthy business requirements and design documents. DocOps strives for less ‘documents’ and more clarity, with minimal friction.

Finally, unlike the waterfall process in which documents are fundamental outputs in the requirements and design stages, but also unlike conventional Agile, in which documentation is conspicuous by its absence, DocOps aims to ‘extract’ most documentation from systems of facts, such as source code, databases, and so on. 

DocOps, DevOps and DevSecOps

Mr. Turcotte said in 2014, “DocOps is the content sibling of DevOps” (Johnson, 2014). But what is DevOps? While many definitions abound, we find (Bass et al., 2015) definition the most useful:

“DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality”

The ‘Sec’ in DevSecOps brings to attention the need to cater for security concerns as well, ranging from static code analysis all the way down to automated penetration testing. But both in the case of ‘vanilla’ DevOps and the sugar-coated DevSecOps flavor, there is an underlying seemingly self-evident assumption which is that we already have the code in hand, and the only issue is putting it in production.

The focus in the last decade has been on automating the building, testing, and deployment of software. DevSecOps adds the ‘securing’ of code as an additional remit but the underlying, untold assumption remains:  “We’ve got the code already, writing the code is the easy part”. Except that it is not.

As clearly understood by Dijkstra in the 70s, it is the other way around. Writing the code is the difficult part: automatic transformation into binaries, containers, and so on is the mechanical, easier-to-grasp part. DocOps focuses on removing the cognitive obstacles that hinder the prompt writing of the code in the first place.

Therefore, as a “content sibling” of DevOps, and extending the definition of Bass et al. (2015) I define DocOps—in terms of its contribution to the software development life cycle—as “a set of practices intended to reduce the time between coming up with an idea or a requirement, and crystallizing it in code, while ensuring high quality.” 

References

Bass, L., Weber, I., & Zhu, L. (2015). Devops: A Software Architect’s Perspective. (p. 4) Addison-Wesley Professional. Kindle Edition

Choo, C. W. (2002). Information Management for the intelligent Organization: The Art of Scanning the Environment. Information Today, Inc. (pp. 22,23,57, 80, 101, 292, 247, 248)

Dijkstra, E. W. (1968). “Go To Statement Considered Harmful”. Communications of the ACM. Volume 11 (3): (pp. 147–148).

Dijkstra, E. W. (1979). The humble programmer. In Classics in software engineering (pp. 111-125).