Digital Practitioner Body of Knowledge™ Standard

The term learning progression refers to the purposeful sequencing of teaching and learning expectations across multiple developmental stages, ages, or grade levels. The term is most commonly used in reference to learning standards - concise, clearly articulated descriptions of what students should know and be able to do at a specific stage of their education. [115]

If a learning progression starts with overly abstract or remote concerns, it may be less accessible to the student. Some may dismiss the course of learning as irrelevant, despite the presence of valuable material further in. In this section we consider a number of models.

Lifecycle Approach

Many bodies of knowledge in the digital profession are ordered using a "lifecycle" (planning, designing, building, running). See Lifecycle Dimension. The biggest challenge with the "lifecycle" concept is that it is easily mistaken for advocacy of sequential, stage-gated, open-loop "waterfall" development methods. Ordering a standard with "requirements" or "analysis" as an initial section also raises concerns from an Agile perspective. Professionals oriented to Agile methods deprecate excessive focus on requirements prior to actual system delivery, preferring instead to deliver "walking skeletons" or "Minimum Viable Products (MVPs)" in an overall strategy of iterative learning.

Starting with planning is also challenging because planning is an abstract activity and difficult to formalize. It is an activity that is deeply controversial and scale and organization-dependent, with few "best practices" and many contrary points of view. When guidance begins with an in-depth discussion of planning (because that is "where the lifecycle starts"), it risks plunging the student or trainee immediately into remote concerns that are experienced primarily by senior personnel in larger-scale organizations.

Stack Approach

Other guidance (e.g., the Zachman® Framework for Enterprise Architecture) is based on a "stack" of abstractions. See Stack Dimension. Computer engineers and scientists start "at the bottom" of the stack, with electrical and electronic engineering, Boolean logic, automata theory, and so forth. This foundational material is difficult and abstract; not all practitioners need to follow such a learning progression (although certain fundamentals such as the concept of computability should be understood at least at a high level by all Digital Practitioners). Conversely, Enterprise Architects are taught decomposition from business objectives, to data, to applications, to technologies.

Whether bottom-up or top-down, layered approaches to technology have utility, but are also prone to reductionism; i.e., that a complex system can be understood as "merely an application" of an underlying layer, or that once a business intent is defined, automating it with a computer is "merely a matter of execution" in decomposition, design, and implementation.

Scaling Model

For maximum accessibility, a different "on-ramp" is needed to best serve the modern Digital Practitioner. The DPBoK structure is based on a scaling model, that can be summarized as "from startup to enterprise".

Verne Harnish, in the book Scaling Up [122 pp. 25-26], describes how companies tend to cluster at certain levels of scale. (See Organizations Cluster at Certain Sizes, similar to [122 p. 25].) Of 28 million US firms, the majority of firms (96%) never grow beyond a founder; a small percentage emerge as a viable team of 8-12, and even smaller numbers make it to the stable plateaus of 40-70 and 350-500. The “scaling crisis” is the challenge of moving from one major level to the next. (Harnish uses the more poetic term “Valley of Death".) This scaling model, and the needs that emerge as companies grow through these different stages, is the basis for this document’s learning progression.

It draws from the concepts and research of Robin Dunbar [91] and Verne Harnish [122], Barry Boehm’s Spiral Model [38], Eric Ries' Lean Startup [232], Alistair Cockburn’s Walking Skeleton design pattern [64], John Gall’s heuristic that complex systems always evolve from simpler, functional systems [107], Scott Ambler’s work on Agility@Scale [17], and the early Ward Cunningham recommendation: "Do the simplest thing that could possibly work …​ if you’re not sure what to do yet" [79]. A related approach can be seen in Simon Wardley’s concepts of "pioneer/settler/town planner" [296]. The book Scale by physicist Geoffrey West [297] provides a useful foundation, based on fundamental physical principles.

The scaling progression can be seen as a third dimension to the previously discussed Stack and Lifecycle (see Scale as Third Dimension).

A scaling digital startup exposes with great clarity the linkage between IT and “the business". The success or failure of the company itself depends on the adept and responsive creation and deployment of the software-based systems. The lessons that digital entrepreneurs have learned through this trial by fire shed great light on IT’s value to the business. Thinking about a startup allows us to consider the most fundamental principles as a sort of microcosm, a small laboratory model of the same problems that the largest enterprises face.

The thought experiment does not limit the DPBoK Standard to entrepreneurial startups. It also may represent the individual’s journey through their career in the organization, from individual developer or engineer, to team lead, to group manager, to senior executive. Or, the journey of an experimental product within an enterprise portfolio.

The Scaling Model and Enterprise Digital Transformation

Large enterprises may find the scaling model useful in their Digital Transformation execution. By reviewing each layer of the model, they can identify whether they are sufficiently supporting critical delivery capabilities. One common problem in the enterprise is the proliferation of processes and controls at the upper levels (Contexts III and IV), to the point where team collaboration and cohesiveness (Context II) is degraded.

The DPBoK structure represents four contexts of organizational evolution:

The thought experiment is as follows:

Take a startup, one or two people in the proverbial garage, or an autonomous "skunkworks" team in a large enterprise, with a powerful idea for a new product with a large digital component. Assume they intend to remain self-funding and grow organically (no venture capital acceleration, or large corporate budget until they have proven their viability). What capabilities do these people need to attract enough revenue to hire others and form a team?

Suppose they succeed in building a viable concept, and hire a team. What new capabilities does this organization need? (And, by omission, which can be deferred until further growth?)

Suppose the team grows to the point that it must be divided into multiple teams, or the internal product is at a point where it must be re-integrated into the enterprise. Again, what new capabilities are needed? And why?

Suppose that, finally, the organization (or product value stream) grows large enough to have formal corporate governance, regulation, external audits, and/or relatively long time spans to manage in terms of its core operating concepts, product portfolio, technology base, and commitments to both suppliers and customers? What new capabilities are needed?

Criteria of Likely Formalization

Topics shall be selected to each context based on the criteria of likely formalization. For example, it would be unusual for a two-person startup to establish a formal portfolio management process for structuring investments; the startup is almost always one unitary investment (perhaps, itself, part of a larger venture portfolio). It would also be unusual for a small startup to have a formalized risk management process. Conversely, it would be unusual for an established large organization to not have a formal portfolio or risk management.

The DPBoK hypothesis is that the conflict between Agile methods and traditional approaches revolves around the transition from a single, collaborative team to a "team of teams" requiring coordination, and the eventual institution of architecture and governance practices. The DPBoK shall curate the most current and relevant industry guidance and academic research on these matters. Providing a rich set of resources and approaches for solving this problem will be valuable for DPBoK consumers struggling to integrate collaborative Agile approaches with service management, process management, project management, architecture, and governance.

The progression shall be held to the above principle of verifiability. It is expected and hoped that the concept of likely formalization will be supported by empirical evidence of organizational development research. Such research might inform further evolution or re-ordering of the proposed capabilities.

Any DPBoK capability may be a concern at any time in an organization’s evolution. Security and architectural thinking are of course required from Day 1. Formalization, however, implies one or more of the following:

As with Boehm’s spiral model, the same concern may be addressed from different perspectives or contexts in the framework. Attempting to cover all nuances of a given practice area such as requirements, or release management when it is first encountered in the team context, results in coverage that is too detailed, bringing in the enterprise context too soon. Advanced discussions or representations of the framework may include foreshadowing of higher-context concerns (e.g., discussion of security or architecture concerns in the Individual/Founder context, pre-formalization).

Brief summaries of the four levels follow.

Context I: Individual/Founder

The Individual/Founder context represents the bare minimum requirements of delivering digital value. The governing thought experiment is that of one or two founders of a startup, or an R&D team with high autonomy (e.g.,"skunkworks") in a larger organization. What are the minimum essential concerns they must address to develop and sustain a basic digital product?

Proposed capabilities include:

The startup thought experiment should be relevant for individuals in organizations of all sizes. The guidance is not intended for entrepreneurs specifically. Rather, the startup is a powerful frame for all Digital Practitioners, as it represents an environment where there can be no distinctions between "business" and "IT" concerns.

Context II: Team

The collaboration level represents the critical team-level experience. Establishing team collaboration as a fundamental guiding value is essential to successful digital product development. The insights of the Agile movement and related themes such as Lean are primary in this context. Competency Areas include:

Context III: Team of Teams

The thought experiment here is the "team of teams" (a term borrowed from the title of a well-known book by General Stanley S. McChrystal [192]). Coordinating across the "team of teams" is a hard problem. Too often, coordination mechanisms (such as overly process-centric operating models) degrade team cohesion and performance. The Agile movement can be seen in part as a reaction to this problem. There is a significant opportunity to compile industry guidance on this topic. Competency Areas are focused on the required capabilities to ensure alignment and joint execution:

Context IV: Enduring Enterprise

The thought experiment here is "the growing enterprise" and the establishment of additional feedback mechanisms for steering, managing risk, and assuring performance at scale and over increasing time horizons and increasingly complex ecosystems: