Principles of the DPBoK Standard


This document shall provide comprehensive guidance for the digital and IT professional in their professional contexts, whether market-facing or supporting. It shall address the complete spectrum of concerns encountered by the Digital Practitioner, from the initial decision for digital investment through value discovery, design, construction, delivery, operation, and ongoing evolution. It shall cover management and organizational development topics of collaboration, coordination, structure, and culture, in the context of Digital Product Management (DPM). It shall cover sourcing and human resource management in the digital context. It shall cover Governance, Risk Management, and Compliance (GRC), data and information management, and architecture. It shall strive to be the “go-to” guidance for orienting Digital Practitioners worldwide to their chosen careers.

This document shall demonstrate a thorough and current consistency with the principles and practices of Agile development and related trends, such as continuous delivery, DevOps, Lean Product Development, Kanban and Lean IT, design thinking in the digital context, Site Reliability Engineering (SRE), and web-scale computing. It shall curate notable current guidance while maintaining a neutral and clinical overall position on controversial topics. It shall serve the Digital Practitioner by identifying relationships and overarching themes across this curated body of knowledge.

The focus of this document, however, is on longer-lived professional and management practices, not the ephemeral aspects of technology. The following should be, in general, discussed primarily by reference at a level suitable for non-technical audiences:

  • Technical standards (platforms, protocols, formats, interoperability, etc.)

  • Specific programming languages and frameworks

The following in general should be avoided, even by reference:

  • Particular vendors and commercial products (this does not include notable open source products with demonstrated longevity); if commercial products are mentioned as examples, at least two examples should be supplied

  • Specific commercial methodologies (some exceptions to this may exist, such as IT Infrastructure Library® (ITIL®) and Scaled Agile Framework® (SAFe®), subject to evidence of substantial notability and demonstrated longevity)

Specific technical practices, such as Infrastructure as Code, virtualization, cloud, and SRE, may be in scope, to be determined on a case-by-case basis. Broader technical trends such as Internet of Things (IoT) and cognitive technologies may be discussed, primarily in terms of their impact on technical practices. (There are many other bodies of work for the practitioner to refer to on such topics.) In general, this document should not be so technically-neutral and abstract as to appear academic and irrelevant to the modern Digital Practitioner.


This document shall remain current with industry practices and trends, subject to evidence of notability and reasonable longevity.


Much current computing and IT guidance uses the concept of “process” as a fundamental building block, with various issues:

  • Inconsistency with the definition of “process” favored by the Business Process Management (BPM) community [Betz 2011]

  • Promotion of formalized “process” as a primary, preferred coordination and delivery model and basis for improvement, rather than one mechanism among several

This document should prefer the concept of “capability” as its fundamental structure, in a definition consistent with other works of The Open Group. The concept of “practice” may also be used. The highest-order DPBoK capabilities shall be cross-cutting, large-grained concepts, not to be confused with organizational functions or processes. They shall be derived and ordered based on a scaling model. The establishment or alteration of DPBoK capabilities and practices must be evidence-based. This document shall align with emerging Business Architecture standards in this regard.


In the computing and digital professions, there is currently a significant and destructive gap between academic theory and research and industrial practice. This can be corrected. For example, medicine has a much more productive feedback loop between researchers and practicing clinicians.

In the interest of narrowing this gap, this document shall be verifiable. Its concepts must be well-grounded, with clear evidence as to their notability. It must not propose concepts or terminology that have little or no evidence of practical adoption in industry. Its structure, principles, practices, and concepts must be falsifiable. It shall be open to rational skepticism and criticism and adaptive in the face of evidence such as surveys, market assessments, analysis of industry narratives and cases, and simulations of sociotechnical systems. It should also demonstrate an awareness of useful academic research and problem framing.

The principle of verifiability does permit for analysis, synthesis, and interpretation. This document should seek to “add value” to industry understanding wherever possible, but must also remain well-grounded while doing so.

Finally, this document must not fall into the trap of excessive semantic debate and the fruitless search for universally applicable abstract ontologies. A framework with recognized inconsistencies but well grounded in industry domain language is preferable to a perfectly consistent framework based on conjectural concepts.

Fine-Grained and Clinical Terminology

Within its capability progression, this document shall strive to employ terminology and concepts that are fine-grained, precise, objective, well-supported, and clinical. For example, it is helpful to break a management concern such as “process management” down into lower-level concepts of task ordering and dependencies, cadence, and synchronization; see Reinertsen’s work on “Managing Flow under Variability”, Chapter 7 [Reinertsen 2009].

Compatibility with Other Frameworks

This document should be, to the greatest extent possible, compatible with other bodies of knowledge and frameworks, while still adhering to the previously articulated principles. It should be positioned as a “standard of standards”, with the objective of aligning and bringing a coherent approach to navigating the currently fragmented information base in the digital industry.

Because other frameworks are large-grained combinations of many concerns, it may not be possible to be compatible in all regards. This document should seek to interoperate with other frameworks using fine-grained terminology. For example, rather than asserting consistency with the Project Management Body of Knowledge® (PMBOK®) as a whole, it is preferable that this document frames its relationship in terms of components such as investment management, planning, resource allocation, risk management, and execution. Similarly, rather than characterizing its relationship to ITIL as a whole, this document should frame its relationship more specifically in terms of the ITIL approaches to product management, process management, and continuous improvement.

Where other frameworks cover a topic sufficiently, this document shall not repeat that coverage. The role of this document is to integrate and synthesize. However, this document shall not overlook or fail to identify points where its point of view varies from the recommendations of other guidance. In such cases, it shall do so in a principled fashion based on clear evidence and with specificity as to the nature of the differences.

Not all sound practice has been formalized through standards. This document may, subject to evidence of notability, reference the contributions of individuals.

Compatibility with Agile Principles

Agile software development has emerged as a dominant approach in software-intensive systems creation, and is expanding its reach and insights into non-software, non-computing fields as well [Rigby et al. 2016], [Rigby et al. 2018]. There are a variety of principles and perspectives on Agile, starting with the well-known Agile Manifesto, furthered by the work of the Agile Alliance®. Commercial Agile frameworks are increasing in number and scope; e.g., the Scaled Agile Framework® and Disciplined Agile Delivery (now owned by the Project Management Institute® (PMI®)).

Agile principles can be described in specific and precise ways; the history and influence of Agile in the computing profession are broad and notable [Larman 2003], and the underlying intellectual foundations of Agile are robust [Schwaber & Beedle 2002], [Reinertsen 2009]. Agile describes sound approaches and practices for product management with a high Research and Development (R&D) component. Using collaborative, focused, cross-functional teams with iterative, feedback-enhanced methods is the most effective approach for solving complex problems (as compared to routing problem-solving work across functional team boundaries with sequential “phase gates”). Where digital systems management involves the discovery of information and coping with “unknown unknowns”, this document shall favor Agile principles.

However, Agile (as a specific set of documented, curated practices) is at its strongest in the cohesive team context. It does not have the same level of consensus or clarity in larger contexts, and the topic of “scaling Agile” is controversial in the industry [Schwaber 2013]. This document should approach the scaling problem in part as a problem of coordination, which is a topic of research attention in academia. Scaling issues are also driven by the organization’s approach to internal investment and organizational development, up to and including culture. Corporate governance must be addressed as well. These are broad topics in management, with many notable and qualified influences for this document to curate into the digital context.

Compatibility with Enterprise Architecture

As part of the paradigm shift to digital, it is important to have a clear understanding of which existing capabilities can be retired, and which new ones will be needed. In some cases, organizations may need to deal with all these changes while keeping their current legacy platform and supporting applications. Integrating new capabilities with existing ones in an effective and efficient way requires a clear landscape and overall view of the organization context. This is provided by Enterprise Architecture. While architecture as a Competency Area is covered in Competency Area 12, this document should implicitly reflect its principles throughout:

  • A systemic view of organizational reality, capabilities, and dependencies

  • Recognizing and communicating internal and external context, integrating the “outside in” and “inside out” views

  • Driving strategic alignment and synergy among organizational components

  • Enabling innovation while also managing technical debt

This systemic and holistic view can be provided by an Enterprise Architecture capability. Due to the continuous and rapid evolution of these disruptive trends, however, a shift to a more Agile style in the Enterprise Architecture capability is also needed. Evolvability should become an Enterprise Architecture concern that facilitates the modification of the enterprise’s products and supporting operating model while preserving non-functional requirements. An example can be seen in The Open Group White Paper Agile Architecture in the Digital Age [W186].

Enterprise Architecture standards such as the TOGAF® Standard [C220] and the ArchiMate® Specification [C197] can be used to achieve this, and should be used along with other practices like Agile, Lean, and DevOps methodologies, as mentioned later. For Agile Architecture guidance, refer to the Open Agile Architecture™ Standard, also known as the O-AA™ Standard [C208].

A Learning Artifact

Participants in developing this document shall recognize their responsibility in developing a learning artifact. This document may be used in both commercial and academic settings for educating the next generation of Digital Practitioners, and assisting Digital Practitioners and leaders in understanding their challenges and options. This document may in part be expressed as Competencies and Learning Objectives compatible with Bloom’s Taxonomy.

Developed as a Digital Product

This document itself must exemplify the new practices it describes. It is, itself, a product entering a market. It must have:

  • Clear and broad feedback channels

  • Clear audience targeting

  • A defined release cadence

  • As frictionless and collaborative a development process as possible

  • A production pipeline automated to the highest degree possible

Its audiences also need to be clearly stated; for example:

  • Executive

  • Management

  • Technologist

  • New to workforce

  • Domain audiences

    • Service management

    • Architecture

    • Information management

Competency-Based Content

This document shall contain competency-based content, and shall be organized based on the structure of the 2016 rewrite of the Masters level Information Systems guidance (MSIS2016) [Topi 2016]. It shall contain:

  • Contexts (four, ordered by scale; this layer is additional to MSIS2016)

  • Competency Areas (Chapters)

  • Competency Categories

  • Example Competencies

DPBoK content framework
Figure 1. DPBoK Structure

Contexts and Competency Areas contain descriptions and higher-level “dimensions” that will list the expected competency outcomes for the area as a whole.

Formalized Competency Categories shall be the majority of the standard and shall follow this structure:

  • Description statement(s): the Competency Category consists of …​

  • Evidence of Notability statement: the evidence for this competency’s importance is …​ (sources must be cited)

  • Limitations: known ways in which the Competency Category can fail, be misapplied, or lead to undesired results

  • Example Competencies: competencies are granular and more transient; a decision will need to be made as to how “normative” they are

    Note that Example Competencies are not the same as Learning Objectives, especially Learning Objectives that are “lower order” dimensions in Bloom’s Taxonomy (Remembering, Understanding). They may be based on, or reflect, “higher order” dimensions in Bloom’s Taxonomy (Applying, Evaluating, Creating). This document follows the MSIS2016 lead in describing competency as “an integrative concept that brings together [the learner’s] knowledge, skills, and attitudes” [Topi 2016].

As in the DPBoK Standard, Version 1, competencies are mostly undefined and some stated dimensions may need further evolution from a learning outcome bias to a true competency orientation.
  • Related Competency Categories: the following topic(s) underpin/relate to/depend on this topic


This is an example only and the actual Competency Category for this topic may differ from this.

  • Context: Individual

  • Competency Area: Infrastructure

  • Competency Category: Infrastructure as Code

    • Description

      According to Kief Morris, “Infrastructure as Code is an approach to infrastructure automation based on practices from software development” [Morris 2016]. For example, instead of using an interactive console to create and configure virtual servers on a one-time basis, an Infrastructure as Code approach would define the parameters of the desired resources (Operating System (OS), capacity, software installed) as a text artifact. This text artifact can then be employed by configuration management tooling to create the infrastructure consistently.

    • Evidence

      Evidence for this topic’s importance is pervasive throughout the modern cloud, DevOps, Agile, and SRE communities. Current examples include The Phoenix Project [Kim et al. 2013] and Infrastructure as Code: Managing Servers in the Cloud [Morris 2016].

    • Limitations

      Infrastructure as Code may not be possible in certain environments where infrastructure management platforms are not driven by text artifacts.

    • Competency Example

      Suggested competencies with reference to current sources are as follows:

      • Compare and contrast various current approaches for Infrastructure as Code, such as shell scripts, declarative configuration management, and open source cloud-native technologies (e.g., Helm®, Cloud Native Application Bundle (CNAB)) and define an appropriate approach for a given organization

      • Define, deploy, and manage an application as a distributed system across several nodes using Infrastructure as Code techniques

End of Example

It is expected that the material will have extensive internal cross-referencing. The above example depends on other Competency Areas, such as source control and configuration management. Use of pervasive cross-referencing will help with the inevitable taxonomy debates over “does X belong under Y?”.

Scaling Model as Learning Progression

The sequence or learning progression of any body of knowledge is critical for its transmission and adoption [Alonzo & Gotwals 2012]. Bodies of knowledge are used in part to educate newcomers to a field, and should reflect an ordering suitable for this purpose. For maximum accessibility, the structure of this document shall be based on a scaling model, that can be summarized as “from startup to enterprise”.

See Models for Learning Progression in the next chapter.