Structure of the Body of Knowledge

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 [Great Schools Partnership 2013].

If a learning progression starts with overly abstract or remote concerns, it may be less accessible. 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 you being plunged 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 [Harnish 2014], describes how companies tend to cluster at certain levels of scale; see Organizations Cluster at Certain Sizes. 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 researchers and concepts, such as Larry E. Greiner’s Growth Model [Greiner 1998], Robin Dunbar [Dunbar 2010], Verne Harnish [Harnish 2014], Barry Boehm’s Spiral Model [Boehm 1988], Eric Ries' Lean Startup [Ries 2011], Alistair Cockburn’s Walking Skeleton design pattern [Cockburn 1996], John Gall’s heuristic that complex systems always evolve from simpler, functional systems [Gall 2012], Scott Ambler’s work on Agility at Scale [Ambler 2015], and the early Ward Cunningham recommendation: “Do the simplest thing that could possibly work …​ if you’re not sure what to do yet” [Cunningham 2014]. A related approach can be seen in Simon Wardley’s concept of “pioneer/settler/town planner” [Wardley 2017]. The book Scale by physicist Geoffrey West [West 2018] 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 practice shed great light on the value of IT 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 Standard 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 One. 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.