Digital Fundamentals

There are many ways in which digital systems deliver value. Some systems serve as the modern equivalent of file cabinets: massive and secure storage for financial transactions, insurance records, medical records, and the like. Other systems enable the transmission of information around the globe, whether as emails, web pages, voice calls, video on-demand, or data to be displayed in a smartphone application (app). Some of these systems support engaged online communities and social interactions with conversations, media sharing, and even massive online gaming ecosystems. Yet other systems enable penetrating analysis and insight by examining the volumes of data contained in the first two kinds of systems for patterns and trends. Sophisticated statistical techniques and cutting-edge approaches like neural network-based machine learning increase the insights of which our digital systems are capable, at a seemingly exponential rate.

Digital technology generates value in both direct and indirect ways. Some of the best known uses of digital technology were and are very indirect — for example, banks and insurance agencies using the earliest computers to automate the work of thousands of typists and file clerks. More directly, people have long consumed (and paid for) communication services, such as telephone services. Broadcast entertainment was a different proposition, however. The consumer (the person with the radio or television) was not the customer (the person paying for the programming to go out over the airwaves). New business models sprung up to support the new media through the sale of advertising air time. In other words, the value proposition was indirect, or at least took multiple parties to achieve: the listener, the broadcaster, and the advertiser. This model, originating in the analog era, has carried through into the digital economy.

From these early business models have evolved and blossomed myriads of creative applications of digital technology for the benefit of human beings in their ongoing pursuit of happiness and security. Digital and IT pervades all of the major industry verticals (e.g., manufacturing, agriculture, finance, retail, healthcare, transportation, services) and common industry functions (e.g., supply chain, human resources, corporate finance, and even IT itself). Digital systems and technologies also are critical components of larger-scale industrial, military, and aerospace systems. For better or worse, general-purpose computers are increasingly found controlling safety-critical infrastructure and serving as an intermediating layer between human actions and machine response. Robotic systems are based on software, and the IoT ultimately will span billions of sensors and controllers in interconnected webs monitoring and adjusting all forms of complex operations across the planet.

Digital Context


Positioning Digital Products

Digital services can be:

  • Directly market and consumer-facing (e.g., Facebook®, LinkedIn®), to be used by external consumers and paid for by either them or closely associated customers (e.g., Netflix®, or an online banking system)

  • Customer “supporting” systems, such as the online system that a bank teller uses when interacting with a customer; customers do not interact directly with such systems, but customer-facing representatives do, and problems with such systems may be readily apparent to the end customer

  • Completely “back-office” systems (human resources, payroll, marketing, etc.)

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).

Figure 7. Technology Adoption Categories (Rogers)

Rogers went on to characterize the various stages:

  • Innovators: venturesome risk-takers

  • Early adopters: opinion leaders

  • Early majority: deliberative, numerous

  • Late majority: skeptical, also numerous

  • Laggards: traditional, isolated, conservative

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

  • Startups that are entering an existing market

  • Startups that are creating an entirely new market

  • Startups that want to re-segment an existing market as a low-cost entrant

  • Startups that want to re-segment an existing market as a niche player

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]:

  • Customer intimacy

  • Product leadership

  • Operational excellence

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

Table 1. Companies and their Competitive Strategies
Customer Intimacy Product Leadership Operational Excellence



Dell Technologies

Home Depot



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

Defining Consumer, Customer, and Sponsor

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:

  • The consumer (sometimes called the user) is the person actually interacting with the IT or digital service

  • The customer is a source of revenue for the service

    • If the service is part of a profit center, the customer is the person actually purchasing the product (e.g., demand deposit banking). If the service is part of a cost center (e.g., a human resources system), the customer is best seen as an internal executive, as the actual revenue-producing customers are too far removed.

  • The sponsor is the person who authorizes and controls the funding used to construct and operate the service

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

Table 2. Defining Consumer, Customer, and Sponsor
Example Consumer Customer Sponsor Notes

Online banking

Bank account holder

Managing Director, consumer banking

Customer-facing profit center with critical digital component

Online restaurant reservation application

Restaurant customers

Restaurant owners

Product owner

Profit-making digital product

Enterprise human resources application

Human resources analyst

Vice-president, human resources

Cost center funded through corporate profits

Online video streaming service

End video consumer (e.g., any family member)

Streaming account holder (e.g., parent)

Streaming video product owner

Profit-making digital product

Social traffic application


Advertiser, data consumer

Product owner

Profit-making digital product

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].


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

Digital Value Methods

This topic is covered in further depth in Context II, when product management emerges as a fully formalized capability. However, even in the individual context the practitioner should have some idea of product positioning and discovery.


Once context is at least initially understood, there are a number of well-known approaches that can help the practitioner bridge from an understanding of your product context, to an effective vision for building and sustaining a product:

  • Traditional business case analysis

  • Alexander Osterwalder’s Business Model Canvas

  • Eric Ries' Lean Startup

The Business Model Canvas and the Lean Startup may seem more suitable for truly entrepreneurial contexts, but there are many practitioners in larger organizations who apply these techniques as well; the thought experiment is "business within a business"; i.e., intrapreneurship [162].

Business Model Canvas

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:

  • Key Partners

  • Key Activities

  • Value Proposition

  • Customer Relationships

  • Customer Segments

  • Key Resources

  • Channels

  • Cost Structure

  • Revenue Streams

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

business model canvas
Figure 8. Business Model Canvas

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.

Business Case Analysis

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:

  • Breakeven analysis

  • Cause-and-effect analysis

  • Cost/benefit analysis

  • Value chain analysis

  • Investment opportunity analysis

  • Pareto analysis

  • Payback analysis

  • Sensitivity analysis

  • Trend analysis

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

Lean Startup flowchart
Figure 9. Lean Startup Flowchart

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):

  • Develop an idea for a "Minimum Viable Product" MVP

  • Measure its effectiveness in the market (internal/external)

  • Learn from the experiment

  • Decide to persevere or pivot (change direction while leveraging momentum)

  • New idea development, evolution of MVP

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

Digital Security

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.


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

The Digital Stack


The Moment of Truth

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:

  • Accepting “input” (user intent) through a screen or voice input

  • Processing that input through software and acting on her desire to see her bank balance

  • Connecting to the phone network

  • Securely connecting over the mobile carrier network to the Internet and then to the bank

  • Identifying the user to the bank’s systems

  • Requesting the necessary information (in this case, an account balance)

  • Receiving that information and converting it to a form that can be represented on a screen

  • Finally, displaying the information on the screen

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

  • The phone’s Operating System (OS) and associated services

  • The phone’s hardware

  • The telecommunications infrastructure (cell phone towers, long distance fiber optic cables, switching offices, and much more)

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:

  • Internet and middleware services to receive the request from the international network

  • Application services to validate the user’s identity and route the request to the appropriate handling service

  • Data services to store the user’s banking information (account identity and transactions) along with millions of other customers

  • Many additional services to detect fraud and security attacks, report on utilization, identify any errors in the systems, and much more

  • Physical data centers full of computers and associated hardware including massive power and cooling infrastructure, and protected by security systems and personnel

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.

Stack Examples

Figure 10. The Digital Stack Supports the Moment of Truth

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:

  • User interface

  • Middleware/business logic

  • Data management

  • OS

  • Network

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:

  • Business process architecture

  • Information architecture

  • Application architecture

  • Technical architecture

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].


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

The Digital Lifecycle

The Essential States of the Digital Product


IT States
Figure 11. The Essential States of the Digital Product

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:

  • An idea is developed for an IT-enabled value proposition that can make a profit, or better fulfill a mission

  • The idea must garner support and resources so that it can be built

  • The idea is then constructed, at least as an initial proof of concept or MVP (construction is assumed to include an element of design; in this document, design and construction are not represented as two large-scale separate phases; the activities may be distinct, but are conducted within a context of faster design-build iterations)

  • There is a critical state transition, however, that will always exist; initially, it is the change from OFF to ON when the system is first constructed - after the system is ON, there are still distinct changes in state when new features are deployed, or incorrect behaviors ("bugs" or "defects") are rectified

  • The system may be ON, but it is not delivering value until the user can access it; sometimes, that may be as simple as providing someone with a network address, but usually there is some initial "provisioning" of system access to the user, who needs to identify themselves

  • The system can then deliver services (moments of truth) to the end users; it may deliver millions or billions of such experiences, depending on its scale and how to count the subjective concept of value experience

  • The user may have access, but may still not receive value, if they do not understand the system well enough to use it; whether via a formal service desk, or informal social media channels, users of IT services will require and seek support on how to maximize the value they are receiving from the system

  • Sometimes, something is wrong with the system itself; if the system is no longer delivering value experiences (bank balances, restaurant reservations, traffic directions) then some action must be taken promptly to restore service

  • All of the previous states in the lifecycle generate data and insight that lead to further evolution of the system; there is a wide variety of ways systems may evolve: new user functionality, more stable technology, increased system capacity, and more - such motivations result in new construction and changes to the existing system, and so the cycle begins again

  • Unless …​ the system’s time is at an end; if there is no reason for the system to exist any longer, it should be retired

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

IT service changes
Figure 12. The Digital Service Lifecycle

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]):

dual axis value chain
Figure 13. Dual-Axis Value Chain

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.

The Three Ways of DevOps

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:

  • Flow (the "First Way")

  • Feedback (the "Second Way")

  • Continuous Learning (the "Third Way")

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].


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