Digital Practitioner Body of Knowledge™ Standard

Digital services can be:

Note, however, that (especially in the current digitally transforming market) a service previously thought of as “back office” (when run internally) becomes “market-facing” when developed as a profit-seeking offering. For example, a human resources system built internally is “back office”, but Workday is a directly market-facing product, even though the two services may be similar in functionality.

In positioning a digital offering, one must consider the likelihood of its being adopted. Is it part of a broader “movement” of technological innovation? Where is the customer base in terms of its willingness to adopt the innovation? A well-known approach is the idea of "diffusion theory”, first researched by Everett Rogers and proposed in his Diffusion of Innovations, [236].

Rogers' research proposed the idea of “Adopter Categorization on the Basis of Innovativeness”, with a well-known graphic (see Technology Adoption Categories (Rogers), similar to [236] Figure 7-3, p.281).

Rogers went on to characterize the various stages:

Steve Blank, in The Four Steps to Epiphany [36], argues there are four categories for startups (p.31):

Understanding which category you are attempting is critical, because “the four types of startups have very different rates of customer adoption and acceptance”.

Another related and well-known categorization of competitive strategies comes from Michael Treacy and Fred Wiersma [287]:

It is not difficult to categorize well-known brands in this way:

However, deciding which strategy to pursue as a startup may require some experimentation.

In understanding IT value, it is essential to clarify the definitions of user, customer, and sponsor, and understand their perspectives and motivations. Sometimes, the user is the customer. But more often, the user and the customer are different, and the role of system or service sponsor may additionally need to be distinguished.

The following definitions may help:

Depending on the service type, these roles can be filled by the same or different people. Here are some examples:

So, who paid for the user’s enjoyment? The bank and restaurant both had clear motivation for supporting a better online experience, and people now expect that service organizations provide this. The bank experiences less customer turnover and increased likelihood that customers add additional services. The restaurant sees increased traffic and smoother flow from more efficient reservations. Both see increased competitiveness.

The traffic application is a somewhat different story. While it is an engineering marvel, there is still some question as to how to fund it long term. It requires a large user base to operate, and yet end consumers of the service are unlikely to pay for it. At this writing, the service draws on advertising dollars from businesses wishing to advertise to passersby, and also sells its real-time data on traffic patterns to a variety of customers, such as developers considering investments along given routes.

This last example illustrates the maxim (attributed to media theorist and writer Douglas Rushkoff [265]) that “if you don’t know how the product is making money, you are the product”.

Evidence of Notability

The context for the existence and operation of a digital system is fundamental to its existence; the digital system in fact typically operates as part of a larger sociotechnical system. The cybernetics literature [301, 25] provides theoretical grounding. The IT Service Management (ITSM) literature is also concerned with the context for IT services, in terms of the desired outcomes they provide to end consumers [282].

Limitations

Understanding a product context is important; however, there is feedback between a product and its context, so no amount of initial analysis will be able to accurately predict the ultimate outcome of fielding a given digital product (internally or externally). A concrete example is the concept of a network effect, in which a product becomes more valuable due to the size of its user base [117].

Related Topics

One recent book that has been influential among entrepreneurs is Alex Osterwalder’s Business Model Generation [215]. This document is perhaps best known for introducing the concept of the Business Model Canvas, which it defines as: “a shared language for describing, visualizing, assessing, and changing business models”. The Business Model Canvas uses nine major categories to describe the business model:

and suggests they be visualized as in Business Model Canvas (similar to [215], p.44).

The canvas is then used in collaborative planning; e.g., as a large format wall poster where the business team can brainstorm, discuss, and fill in the boxes (e.g., what is the main “Value Proposition"? Mobile bank account access?).

Osterwalder and his colleagues, in Business Model Generation and the follow-up Value Proposition Design [216], suggest a wide variety of imaginative and creative approaches to developing business models and value propositions, in terms of patterns, processes, design approaches, and overall strategy.

There are a wide variety of analysis techniques for making a business case at a more detailed level. Donald Reifer, in Making the Software Business Case [228], lists:

Empirical, experimental approaches are essential to digital management. Any analysis, carried to an extreme without a sound basis in real data, risks becoming a “castle in the air”. But when real money is on the line (even the opportunity costs of the time you are spending on your startup), it is advisable to look at the decision from various perspectives. These techniques can be useful for that purpose. However, once you have some indication there might be business value in a given idea, applying Lean Startup techniques may be more valuable than continuing to analyze.

Lean Startup is a philosophy of entrepreneurship developed by Eric Ries [232]. It is not specific to IT; rather, it is broadly applicable to all attempts to understand a product and its market. (According to our definition of product management a workable market position is essential to any product.)

The idea of the Lean Startup has had profound influence on product design, including market-facing and even internal IT systems. It is grounded in Agile concepts such as:

“Do the simplest thing that could possibly work.”

Lean Startup calls for an iterative, “Build-Measure-Learn” cycle (see Lean Startup Flowchart, summary of ideas in [232]). Repeating this cycle frequently is the essential process of building a successful startup (whatever the digital proportion):

Flowcharts such as Lean Startup Flowchart are often seen to describe the Lean Startup process.

A Digital Practitioner often starts by thinking about value creation through their digital products or services. However, now is also the time to think about protecting that digital value. Your customers will be sharing data about themselves, their preferences, and even financial information; e.g., credit cards to make purchases. Failure to protect that data can irreparably damage any other digital value you manage to create; it will certainly damage your or your organization’s reputation, and may have financial consequences.

Architects of buildings need to appreciate that the physical materials that will implement their creations need to be strong enough to produce the envisioned construct. Similarly, a Digital Practitioner needs to understand that software can be weak and they need to appreciated how to examine the software artifacts for the precursors of those weaknesses that would threaten the operational capabilities and integrity of their envisioned constructs.

Attack surface analysis, design reviews for security weaknesses, static source code analysis for weaknesses, dynamic fuzz testing, adversary-based pen testing, and binary analysis are all techniques used to gain confidence that dangerous failure modes of the software-based system are not rampant and that some evidence-based argument can be made about the adequacy of the rigor used to create the software.

In the building of buildings, this is done by the engineering elements of a team, along with building code inspectors and material scientists, but the analogous activities are not the norm in software systems. So, as you go through both the analysis and description phase and the construction phase, keep in mind that that all software has strengths and weaknesses and needs to be checked for weaknesses that would impact the intended functionality, reasoning, and logic. See the [Common Weakness Enumeration (Mitre)] for examples of weaknesses with security, performance, reliability, and maintainability consequences.

As software-enabled elements become more entwined in our physical lives, both at work and not, there needs to be attention paid to this line of thinking in the education of the software-based systems work force.

A deeper treatment of this subject can be found in the later chapter on Security and in The Open Group Guide to Integrating Risk and Security Within a TOGAF® Enterprise Architecture.

Evidence of Notability

The complex process of discovering and supporting digital value is covered in industry work on Digital Transformation [298, 81]. It is also addressed as an important sub-topic within the product management literature, especially at its intersection with Agile. Product management is a large and growing professional community, with a major professional organization (the Product Development and Marketing Association) and many less formalized meetings and groups. It has a correspondingly rich body of professional literature [36, 53, 114]. Product management is also a major topic at Agile conferences.

Limitations

Some digital efforts are more instrumental, and provide value in the same way that a cog provides value to a machine. They have little independence. Discussions of value imply greater autonomy to act on the analysis. Business case analysis would rarely be applied in the engineering of a small component; similarly, business case analysis makes less sense with digital systems whose existence is required by a larger whole. It is at the level of that larger whole that value analysis should take place.

Related Topics

Any human-facing digital service can be seen as delivering a “moment of truth”. In terms of digital systems, this English-language cliche (elaborated into an important service concept by SAS group president Jan Carlzon [55]) represents the user’s outcome, their experience of value. All discussions of digital value should either start or end there.

In order to view a bank balance, a user may use an application downloaded from a “store” of applications made available to her device. On her device, this “app” is part of an intricate set of components performing functions such as:

The application, or “app”, downloaded to the phone plays a primary role, but is enabled by:

Of course, without the banking systems on the other end, there is no bank balance to transmit. These systems are similar, but on a much larger scale than the end user’s device:

Consider: what does all this mean to the user? Does she care about cell phone towers, or middleware, or triply redundant industrial-strength Power Distribution Units ? Usually, not in the least. Therefore, as we study this world, we need to maintain awareness of her perspective. The user is seeking some value that digital technology uniquely can enable, but does not want to consider all the complexity that goes into it. She just wants to go out with friends. The moment of truth (see The Digital Stack Supports the Moment of Truth) depends on the service; the service may contain great complexity, but part of its success lies in shielding the user from that complexity.

The outcome of a digital service (e.g., an account balance lookup for an online banking application) is supported by a complex, layered structure of technology. For example, a simple systems architecture might be represented in layers as:

Architecture also uses a layered method, but in a different way that is more abstracted from the particular and concrete to the conceptual; for example:

Evidence of Notability

The use of layered abstractions in digital systems engineering is well established. Such abstractions may be highly technical, such as the OSI stack describing layered networking protocols [154], or more conceptual, such as the Zachman Framework [313].

Limitations

Sometimes, organizations attempt to structure themselves around the stack, with separate functional units for user interface, middleware, data management, network, and so forth. This approach may result in monolithic, hard to change systems. See Conway’s Law.

Related Topics

Description

The digital or IT service is based on a complex stack of technology, from local devices to global networks to massive data centers. Software and hardware are layered together in endlessly inventive ways to solve problems people did not even know they had ten years ago. However, these IT service systems must come from somewhere. They must be designed, built, and operated, and continually improved over time. A simple representation of the IT service lifecycle is:

The digital service/product evolves over time, through many repetitions ("iterations") of the improvement cycle. An expanding spiral is a useful visualization:

This entire process, from idea to decommissioning (“inspire to retire”) can be understood as the service lifecycle (see The Digital Service Lifecycle). Sometimes, the service lifecycle is simplified as "plan, build, run"; however, this can lead to the assumption that only one iteration is required, which is in general incorrect in digital systems. Multiple iterations should be assumed as the product is fine-tuned and evolves to meet changing demand.

We can combine the service experience (moment of truth) with the service/product lifecycle into the “dual-axis value chain” (originally presented in [32]):

The dual-axis value chain can be seen in many representations of IT and digital delivery systems. Product evolution flows from right to left, while day-to-day value flows up, through the technical stack. It provides a basis for (among other things) thinking about the IT user, customer, and sponsor, which we will cover in the next section.

DevOps is discussed in depth later in this document. At this point, however, as originally conceived in The Phoenix Project [165], there are three core DevOps principles applicable at the earliest stages of the digital product:

DevOps emphasizes speeding up the flow of value in the product lifecycle (left to right), and the feedback of learning (right to left) "at all stages of the value stream". When this is done consistently at scale over time, DevOps advocates argue that the result is a: "generative, high-trust culture that supports a dynamic, disciplined, and scientific approach to experimentation and risk-taking, facilitating the creation of organizational learning, both from our successes and failures. Furthermore, by continually shortening and amplifying our feedback loops, we create ever-safer systems of work and are better able to take risks and perform experiments that help us learn faster than our competition and win in the marketplace." [166 p. 12].

Limitations

The limitations of relying on a lifecycle model as a basis for systems implementation are by now well known. Attempting to fully understand a system’s "requirements" prior to any development can lead to project failure, and deferring integration of sub-modules until late in a project also is risky. See Agile canon for further discussion (e.g., [250, 220, 230, 68]). Nevertheless, the concept of the lifecycle remains a useful model; these state transitions exist and drive organizational behavior.

Evidence of Notability

The evidence for this topic’s importance is seen across much guidance for software and systems professionals. Examples include the original statement of "waterfall" development [241], the overlapping phases of the Rational Unified Process [227], the ITIL Service Lifecycle’s "strategy/design/transition/operate/improve," [282], the clear reach and influence of the DevOps movement, and many more.

Related Topics