The label "Digital" is applied to a lot of management and technology guidance these days, and risks becoming just another in a long line of technology buzzwords. Isn’t "Digital" just one more step in the long continuum of business exploiting emerging technology? Or, have we crossed some "tipping point" causing a fundamental shift in how we manage such transformation?

My answer would be that there is something different happening this time — digital delivery is becoming core, not context. The convergence of an abundance of computing resources, improving software development management, combined with a change in market focus from the supplier to the customer is changing the way we view Enterprise Architecture and IT management, and identifying the need to develop a digital workforce. The defining characteristics of a digital enterprise are becoming clear:

  • Products or services that are either delivered fully digitally (e.g., digital media or online banking), or where physical products and services are obtained by the customer by digital means (e.g., online car sharing services)

  • A "digital-first" culture, where the business models, plans, architectures, and implementation strategies start from an assumption of digital delivery

  • A workforce who is digitally savvy enough to execute a digital-first approach

About This Book

This book, "Managing Digital: Concepts and Practices", is intended to guide a practitioner through the journey of building a digital-first viewpoint and the skills needed to thrive in the digital-first world. As such, this book is a bit of an experiment for The Open Group; it isn’t structured as a traditional standard or guide. Instead, it is structured to show the key issues and skills needed at each stage of the digital journey, starting with the basics of a small digital project, eventually building to the concerns of a large enterprise. So, feel free to digest this book in stages — the section Introduction for the student is a good guide.

Finally, the electronic publication of this book will be an experiment for The Open Group in another way, in that it is our intent for this book to be a living document updated through crowdsourced content and refreshed periodically in order to keep pace with the rapid evolution of digital business. In parallel with the publication of this book The Open Group Digital Practitioners Work Group will be developing standards and best practices for Digital Practitioners; once those normative standards are published, it is expected that this book will be revised to reflect those.

So, please let us know what you think, and please join our community as a contributor.

David Lounsbury
Chief Technical Officer
The Open Group

Preface by original author

I wrote my first book, Architecture and Patterns for IT Service Management, Resource Planning and Governance: Making Shoes for the Cobbler’s Children in 2006, with a second edition in 2011. I presented the second edition at the national SEI Saturn conference in Minneapolis in 2013, where I was approached by Dr. Bhabani Misra, the head of the Graduate Programs in Software at the University of St. Thomas in St. Paul. Minnesota. Dr. Misra asked me to teach a class called "IT Infrastructure Management," later "IT Delivery," which was to cover not just technical topics but also process and governance.

The course (which has run every semester since January 2013) has been developed during an extraordinary period for IT and digital management. Even in 2013, the trend towards a new style of IT delivery, based on Agile and DevOps practices was notable and accelerating. At this writing, these approaches seem to have “crossed the chasm” in the words of Geoffrey Moore, and are becoming the dominant models for delivering IT value. As this book describes, there are good reasons for this historical shift, and yet its speed and reach are still disorienting.

For three semesters I assigned my first book (Architecture and Patterns for IT: Service Management, Resource Planning, and Governance) as a required text for the class. However, I did not write this as a textbook, and its limitations became clear. While I gave considerable attention to Lean and Agile in writing the book, it has a strongly architectural approach, coming at the IT management problem as a series of views on a model. I do not recommend this as a pedagogical approach for a survey class. It also had a thoroughly enterprise perspective, and I began to question whether this was ideal for new students. Further thought led to the idea of the emergence model (detailed in the Introduction).

I proposed the idea of a third edition to my publisher -— one that would pivot the existing material towards something more useful in class. They agreed to this and I started the rewrite. However, by the time I was halfway done with the first draft, I had a completely new book. The previous work was analytic and technical, while the new book was more conversational, attempting to engage students of a wide background.

A number of factors converged:

  • My view that the “medium is the message,” which extends to the choice of authoring approach, toolchain, and publisher

  • A desire to freely share at least a rough version of the book, both for marketing purposes and in the interests of giving back to the global IT community

  • A desire to be able to rapidly update the book with as little friction as possible

  • A practical realization that the book might get more uptake globally if it were available, at least in some form, as open-sourced intellectual property

  • The fact that I had already started to publish my labs on GitHub and had, in fact, developed a workable continuous delivery (“DevOps”) toolchain based on virtualization for classroom use.

Ultimately, the idea of starting my own publishing company, and managing my own product, appeared both desirable and practical. So I decided to self-publish, via LeanPub. Further developments, including my ongoing participation in the IT4IT™ Reference Architecture, a standard of The Open Group, led me to sign the work over to The Open Group, where it will in part serve as a basis for the new Digital Practitioner Body of Knowledge.

Many assisted with and/or contributed to this work before its transition to The Open Group:

  • Stephen Fralippolippi

  • Roger K. Williams

  • Jason Baker

  • Mark Kennaley

  • Glen Alleman

  • Jeff Sussna

  • Nicole Forsgren

  • Richard Barton

  • Evan Leybourn

  • Chris Little

  • Jabe Bloom

  • Lorin Hochstein

  • Gene Kim

  • Murray Cantor

  • Rob England

  • Firasat Khan

  • Mary Mosman

  • David Bahn

  • Amos Olagunju

  • Svetlana Gluhova

  • Mary Lebens

  • Justin Opatrny

  • Grant Spencer

  • Halbana Tarmizi

  • Will Goddard

  • Terry Brown

  • Francisco Piniero

  • Pat Paulson and his students

  • Majid Iqbal

  • Mark Smalley

  • Ben Rockwood

  • Mark Mzyk

  • Michael Fulton

  • Sriram Narayam

  • John Spangler

  • Tom Limoncelli

  • Kate Campise

  • Dmitry and Alina Kirsanov

Special thanks to Dr. Bhabani Misra for asking me to teach at the University of St. Thomas and providing direction at key points, including challenging me to add a practical component to the course, and to Dave Lounsbury and The Open Group for seeing the merit in this work.

Charles Betz, January 2018

Introduction for instructors and trainers

Welcome to Managing Digital: Concepts and Practices. So, what exactly is this book?

  • It is the first general, survey-level text on IT management with a specific Agile, Lean IT, and DevOps orientation

  • It has a unique and innovative learning progression based on the concept of organizational evolution and scaling

  • Because it is written with continuous integration and print-on-demand techniques, it can be continually updated to reflect current industry trends

The book is intended for both academic and industry training purposes. There has been too much of a gap between academic theory and the day-to-day practices of managing digital products. Industry guidance has over the years become fragmented into many overlapping and sometimes conflicting bodies of knowledge, frameworks, and industry standards. The emergence of Agile and DevOps as dominant delivery forms has thrown this already fractured ecosystem of industry guidance into chaos. Organizations and individuals with longstanding investments in guidance such as ITIL (aka the IT Infrastructure Library). [1] and the Project Management Body of Knowledge (aka PMBOK) are re-assessing these commitments. This book seeks to provide guidance for both new entrants into the digital workforce and experienced practitioners seeking to update their understanding on how all the various themes and components of IT management fit together in the new world.

Digital investments are critical for modern organizations and the economy as a whole. Participating in their delivery (i.e., working to create and manage them for value) can provide prosperity for both individuals and communities. Now is the time to re-assess and synthesize the bodies of knowledge and developing industry consensus on how digital and IT professionals can and should approach their responsibilities.

The IT industry and the rise of digital

Now agile methodologies -— which involve new values, principles, practices, and benefits and are a radical alternative to command-and-control-style management -— are spreading across a broad range of industries and functions and even into the C-suite. [223]
— Darrell Rigby et al.
Harvard Business Review

Consider the following two industry reports.

In September 2015, Minneapolis-based Target Corporation laid off 275 workers with IT skillsets such as business analysis and project management, while simultaneously hiring workers with newer “Agile” skills. As quoted by a local news site, Target stated:

“As a part of our transition to an Agile technology development and support model, we conducted a comprehensive review of our current structure and capabilities … we are eliminating approximately 275 positions and closing an additional 35 open positions. The majority of the impact was across our technology teams and was primarily focused on areas such as business analysis and project management." [149]

Jim Fowler, Chief Information Officer at General Electric, says:

“When I am in business meetings, I hear people talk about digital as a function or a role. It is not. Digital is a capability that needs to exist in every job. Twenty years ago, we broke e-commerce out into its own organization, and today e-commerce is just a part of the way we work. That’s where digital and IT are headed; IT will be no longer be a distinct function, it will just be the way we work. … [W]e’ve moved to a flatter organizational model with “teams of teams” who are focused on outcomes. These are co-located groups of people who own a small, minimal viable product deliverable that they can produce in 90 days. The team focuses on one piece of work that they will own through its complete lifecycle … in [the “back-office”] model, the CIO controls infrastructure, the network, storage, and makes the PCs run. The CIOs who choose to play that role will not be relevant for long.” [122]

Modern Management Information Systems (MIS) courses and textbooks, especially at the undergraduate, survey level, seek to orient all students (whether IT/MIS specialists or not) to the role and function of information systems and their possibilities and value in the modern enterprise. This book, by contrast, intends to prepare the student for a career as a digital professional, in those industries that offer digital products per se as well as industries that rely on digital technology instrumentally for delivering all kinds of products. A central theme of the book is that IT, considered as a component, represents an increasing proportion of all industrial products (both consumer and business-facing). This trend towards IT’s increase is a key characteristic of Digital Transformation.

Current MIS survey texts have some common characteristics:

  • They tend to focus on the largest organizations and their applications of computing. This can lead to puzzling topic choices; for example, in one current MIS text I reviewed, one of the first sections is dedicated to the problem of enterprise IT asset management -— a narrow topic for the earlier sections of a survey course and increasingly irrelevant in the age of the cloud.

  • Because their coverage area is termed "information systems," many start with extensive and detailed coverage of database management at an enterprise scale, often focused on the classical relational database -— which is now just one choice among many in a world of NoSQL and microservices.

  • They do not (and this is a primary failing) cover Agile and its associated digital ecosystems well, if at all. Brief mentions of Agile may appear in sections on project management, but in general there is a lack of awareness of the essential role of Agile and related methods in accelerating digital transformation.

  • Their coverage of cloud infrastructure can also be limited, even with new editions coming out every year. Topics like infrastructure as code go unaddressed.

  • Finally, current texts often uncritically accept and cite “best practice” IT frameworks such as CMMI, ITIL, PMBOK, and CObIT. New digital organizations do not, in general, use such guidance, and there is much controversy in the industry as to the value and future of these frameworks. This book strives to provide a clear, detailed, and well-supported overview of these issues.

IT, or the digital function, has had a history of being under-managed and poorly understood relative to peer functions in the enterprise. It struggles with a reputation for expensive inflexibility and Dilbert-esque dysfunction, and has generated a fair amount of mistrust with its business sponsors. The DevOps and Agile movements promise transformation but are encountering an entrenched legacy of

  • Enterprise Architecture

  • Program and project management

  • Business process management

  • IT service management practices

  • IT governance concerns

Understanding and engaging with the challenges of this legacy are ongoing themes throughout this introductory text. Some of the more radical voices in the Agile movement sometimes give the impression that the legacy can be simply swept away. Mike Burrows notes that, in terms of the systems thinking at the core of Agile philosophy, such a move might be ill-advised:

“Some will tell you that when things are this bad, you throw it all away and start again. It’s ironic: The same people who would champion incremental and evolutionary approaches to product development seem only too eager to recommend disruptive and revolutionary changes in people-based systems -— in which the outcomes are so much less certain” [45 p. 827].

IT management at scale within an organization is a complex system. The IT workforce, its collective experience, and its ongoing development (through education and training) is another complex system orders of magnitude larger. Complex systems do not respond well to dramatic perturbations. They are best changed incrementally, with careful monitoring of the consequences of each small change. (This is part of the systems theory foundation underlying the Agile movement). This is why the book covers topics such as:

  • Investment, sourcing, and people

  • Project and process management

  • Governance, risk, security, and compliance

  • Enterprise information management

  • Enterprise Architecture and portfolio management

While these practices, and their associated approaches and policies, have caused friction with digital and Agile practitioners, they all have their reasons for existing. The goal of this book is to understand their interaction with the new digital approaches, but in order to do this we must first understand them on their own terms. It does no good to develop a critique based on misconceptions or exaggerations about what (for example) process management or governance is all about. Instead, we try to break these large and sometimes controversial topics into smaller, more specific topics:

  • Work and effort

  • Ordering of tasks

  • Task dependencies

  • Coordination

  • Investment

  • Cost of delay

  • Planned versus unplanned work

  • Estimation versus commitment

  • Value stream versus skill alignment

  • Repeatability

  • Defined versus empirical process control

  • Synchronization and cadence

  • Resource demand

  • Shared mental models

  • Technical debt

  • Risk, etc.

By examining IT management in these more clinical terms, we can develop a responsible critique of current industry best practices that will benefit students as they embark on their careers.

A key choice in the book’s evolution was to NOT include dedicated chapters on “Project Management” and “Process Management.” Instead, more general chapter titles of “Coordination” and “Investment and Planning” were chosen. Rationale for the decision is given in those chapters and in Part III generally. Similarly, there is no one section covering “IT service management” per se; its significant concerns are seen throughout Chapters 4 through 10.

A process of emergence

Joseph Campbell popularized the notion of an archetypal journey that recurs in the mythologies and religions of cultures around the world. From Moses and the burning bush to Luke Skywalker meeting Obi wan Kenobi, the journey always begins with a hero who hears a calling to a quest …

The hero’s journey is an apt way to think of startups. All new companies and new products begin with an almost mythological vision -— a hope of what could be, with a goal few others can see …

Most entrepreneurs feel their journey is unique. Yet what Campbell perceived about the mythological hero’s journey is true of startups as well: However dissimilar the stories may be in detail, their outline is always the same. [31]
— Steve Blank
The Four Steps to Epiphany

One of the most important and distinguishing features of this book is its emergence model. In keeping with the entrepreneurial spirit of works like Ries’ The Lean Startup, the book adopts a progressive, evolutionary approach. The student’s journey through it reflects a process of emergence. Such processes are often associated with founding and scaling a startup. There are many helpful books on this topic, such as the following:

  • Nail It Then Scale It by Furr and Ahlstrom [102]

  • Scaling Up by Harnish [117]

  • Startup CEO by Blumberg [33]

  • The Lean Startup by Ries [222]

  • Hello, Startup by Brikman [35]

The emergence model and overall book structure is discussed in depth in the main introduction. Here, for the instructor, are some notes on the thought process.

A central problem in conceiving the book was the question of overall learning progression, or narrative. As noted in the Preface, it was first developed to support a required semester-long survey class on IT management at the University of St. Thomas in St. Paul, Minnesota, in the largest software engineering program in the country.

Currently, two primary narratives or learning progressions are used to in teaching computing:

  • The “stack”

  • The “lifecycle”

The stack is how the most rigorous topics are taught. Algebra is the foundation for trigonometry, trigonometry is required for calculus, for example. Logic is needed for discrete math, required for automata and compilers, and so forth. The stack is also how technology is described: physical, logical, and conceptual layers, for example, or layered abstractions in networking protocols.

The systems lifecycle, on the other hand, is how we tend to structure industry guidance. We plan and design, we build, we run. Guidance such as CObIT and ITIL show lifecycle influences, as do software engineering programs in colleges.

Kniberg vehicles
Figure 1. Systems evolve and scale iteratively

However, both the stack and the lifecycle have limitations:

  • The stack can fall into reductionism, or what venture capitalist Anshu Sharma calls the “stack fallacy,” the “mistaken belief that it is trivial to build the layer above yours” [244]. A different form of the stack fallacy is seen when practitioners assume that systems can easily be decomposed through layers (business, data, application, technology).

  • The lifecycle narrative is far too prone to promoting waterfall thinking, anathema to the current Agile and Lean Product Development approaches redefining the digital profession.

Instead, this book’s emergence narrative draws on systems theory, in particular John Gall’s idea that “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system” [103]. Henrik Kniberg created a compelling visual image showing how systems scale: through ongoing, iterative re-design and elaboration of fundamental characteristics (Systems evolve and scale iteratively [2]).

What if we treated the student’s understanding as such a systems scaling problem? What would be the simplest possible thing that could work? How would we iteratively evolve their understanding, based on practical topics? Scaling seems to be orthogonal to the other narratives (Three narrative dimensions).

As we’ll cover in the main introduction, reading books on organizational scaling inspired the idea that growth does not happen smoothly; instead organizations tend to cluster at certain scales and struggle to grow to the next scale. Hence the overall structure of the book:

  • Founder

  • Team

  • Team of Teams

  • Enterprise

narratives cube
Figure 2. Three narrative dimensions

A key focus of the book is explaining what practices are formalized at which level of growth. The thought experiment is, “what would I turn my attention to next as my IT-based concerns scale up?” For example, the book currently proposes that work management (implying rudimentary workflow, e.g., Kanban) correctly comes before formalized project and/or process management, which in turn tend to emerge before enterprise governance practices (e.g., formalized risk management).

Note that this would be a testable and falsifiable hypothesis if empirical research were done to take inventory of and characterize organization scaling patterns. If we found, for example, that a majority of organizations formalize governance, risk, security, and compliance practices before formalizing product management, that would indicate that those chapters should be re-ordered. In my experience, small/medium businesses may have formal product management but Governance, Risk, and Compliance, (GRC) are still tacit, not formalized. This does not mean that GRC is not a concern, but they have not yet instituted formal policy management, internal audit, or controls.

The presence of product management at an early stage in the book (Chapter 4) is intended to provoke thought and debate. Product management is poorly addressed in most current college computing curricula as well as the de facto industry standards (e.g., the TOGAF® ADM, PMBOK, and ITIL). Yet formalizing it is one of the earliest concerns for a startup, and the imperatives of the product vision drive all that comes after. Evidence to this effect is seen (as of 2015) at the University of California at Berkeley I-School, which has replaced its Project Management course with Lean/Agile Product Management, taught currently by Jez Humble, author of Continuous Delivery, Lean Enterprise, and co-author of The DevOps Handbook.

This book however is not a complete dismissal of older models of IT delivery. Wherever possible, new approaches are presented relative to what has gone before. The specifics of “what’s different” are identified, in the interest of de-mystifying what can be fraught and quasi-religious topics. (Why is a Scrum standup or a Kanban board effective, in terms of human factors?)

The emergence model can also be understood as an individual’s progression within a larger enterprise. Even starting from day one at a Fortune 100 corporation, I believe a person’s understanding still progresses from individual, to team, to team of teams, to enterprise. Of course, the person may cease evolving their understanding at any of these stages, with corresponding implications for their career.

This book does not cover specific technologies in any depth. Many examples are used, but they are carefully framed to not require previous expertise. This is about broader, longer lifecycle trends.

There is benefit to restricting the chapters to 12, as a typical semester runs 14 weeks, and the book then fits well, with one chapter per class and allowing for an introductory session and final exam. Of course, a two-semester series, with two weeks per chapter, would also work well. Each half of the book is also a logical unit. The chapters have been re-ordered and refactored many times, and based on further research may evolve further.


With three chapters in each section, the book can be covered in one intense semester at a chapter a week, although expanding it to a two-semester treatment would allow for more in-depth coverage and increased lab exposure. This required new thinking. How could students learn IT management at scale in a lab setting? A hands-on component is essential, as IT management discussions can be abstract and meaningless to many students. (“Incidents are different from problems!”)

Ten years ago, the best that would have been possible would be paper case studies, perhaps augmented with spreadsheets. But new options are now available. The power of modern computers (even lightweight laptops) coupled with the widespread availability of open-source software makes it possible to expose students to industrial computing in a meaningful, experiential way. There is great utility in the use of lightweight, pre-configured virtualization technologies such as Vagrant, VirtualBox, and Docker.

The initial course used a central server, but even that is not necessary. The class can be taught with zero computing budget, assuming that each team of students has access to a modern laptop (recommend 8 gigabytes of RAM and 250 gigabyte drive) and a fast Internet connection. Initial lab versions used free and open-source versions of Chef, Jenkins, Nagios, JUnit, Ant, and other tools, evolving to Node.js, microservices, Docker, and Kubernetes. See the dm-academy resources on GitHub for the current status.

Some may question the inclusion of command-line experience, but without some common technical platform, it is hard to provide a meaningful, hands-on experience in the first half of the course. Currently, digital professionals require hands-on technology skills; barriers to developing them being much lower than in years past. The initial course assumed that the students are at least willing to learn computing techniques, with no prerequisites beyond that. Not even a programming language is required; the Java currently used as a sample is minimal.

Truly beginning students will have to work at the Linux tutorials, but all they need to master is basic command line navigation; this is possible with a diverse student body, some with no previous computing experience. The labs for the second half of the course mostly use games, experiential paper-based classroom exercises, GUI-based software, databases, and office productivity tools.

The emergence model is intended as the learning progression for either traditional semester-based education, or industry training. Labs tie into the emergence model and encourage the students in hands-on exploration of fundamentals, as if they were starting their own business or initiative. As they progress, they remain grounded in the basics of applied technology. Even the most highly scaled topics, such as Enterprise Architecture and portfolio management, become more real when the students are reminded that the systems in question are simply larger and more numerous versions of the examples they see in the lab.

Introduction for the student

This is a survey text, intended for the advanced undergraduate or graduate student interested in the general field of applied Information Technology (IT) management. It is also intended for the mid-career professional seeking to update their understanding of IT management’s evolution, especially in light of the impact of Agile, Lean, and DevOps.

The book is grounded in basic computing fundamentals but does not require any particular technical skills to understand. You do not need to have taken any courses in networking, security, or specific programming languages to understand this book. However, you occasionally will be presented with light material on such topics, including fragments of programming languages and pseudocode, and you will need to be willing to invest the time and effort to understand.

This book makes frequent reference to digital startups -— early stage companies bringing new products to market that are primarily delivered as some form of computer-based service. Whether or not you intend to pursue such endeavors, the startup journey is a powerful frame for your learning. Large IT organizations in enterprises sometimes gain a reputation for losing sight of business value. IT seems to be acquired and operated for its own sake. Statements like “we need to align IT with the business!” are too often heard.

A 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. Market revenues arrive, or do not, based on digital product strategy and the priorities chosen. Features the market doesn’t need? You won’t have the money to stay in business. Great features, but your product is unstable and unreliable? Your customers will go to the competition.

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.

Verne Harnish, in the book Scaling Up [117 pp. 25-26], describes how companies tend to cluster at certain levels of scale. (See Organizations cluster at certain sizes (concept by Harnish) footnote:[similar to [117 p. 25]). Of 28 million U.S. 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 book’s learning progression.

Figure 3. Organizations cluster at certain sizes (concept by Harnish)

However, this is not a textbook (or course) on entrepreneurship. It remains IT-centric. And, the book is also intended to be relevant to students entering directly into large, established enterprises. In fact, it prepares the student for working in all stages of growth because it progresses through these four contexts:

  • Individual (founder)

  • Team

  • Small company (team of teams)

  • Enterprise

Whether your journey begins in a startup or within a larger, established organization, you will (hopefully) become aware as you progress of a broadening context:

  • Other team members

  • Customers

  • Suppliers

  • Sponsors

  • Necessary non-IT capabilities (finance, legal, HR, sales, marketing, etc.).

  • Channel partners

  • Senior executives and funders

  • Auditors and regulators

Part of maturing in your career is understanding how all these relationships figure into your own overall system of value delivery. This will be a lifelong journey for the student; the author’s intent is to provide some useful tools.

This book’s structure

Figure 4. IT management evolutionary model (read bottom to top)

IT management evolutionary model (read bottom to top) is a conceptual illustration of an IT management progression (read the figure bottom to top). Elaborating the outline into chapters, we have:

  1. Founder

    1. Digital value. Why do we need computers? What can they do for us? What are the essential aspects of computer systems: their sponsorship, use, construction, operation, and evolution?

    2. Digital infrastructure. We want to build something. We have to choose a platform first, with attention to fundamentals such as operating systems, storage, and networking. Understanding and choosing among cloud alternatives is immediately required, and managing the configuration of the new digital product is essential.

    3. IT applications delivery. Let’s start building something of use to someone. Software development has evolved from waterfall to Agile, and continuous delivery is now the de facto standard.

  2. Team

    1. Product management. What exactly is it that we are building? What is the process of discovering our customer’s needs and quickly testing how to meet them? How do we better define the product vision, and the way of working towards it, for a bigger team?

    2. Work management. How do we keep track of what we are doing and communicate our progress and needs at the simplest level? How do we manage the quantity of work in progress?

    3. Operations management. How do we sustain this surprisingly fragile digital service in its ongoing delivery of value? How do we incorporate lessons from its operation back into the product?

  3. Team of Teams

    1. Coordination. When we have more than one team, they need to coordinate, which we define as “the process of managing dependencies among activities.” There are many techniques to help us coordinate, including process management and Agile concepts. What is the future of process management as a delivery model?

    2. Investment and planning. We make investments in various products, programs, and/or projects, and we are now big enough that we have portfolios of them. How do we decide? How do we choose and work with our suppliers? How do we manage the finances of complex digital organizations? What is the future of project management as a delivery model?

    3. Organization and culture. We’re getting big. How do we deal with this? How are we structured, and why that way? How can we benefit from increasing maturity and specialization while still maintaining a responsive digital product? How do we hire great people and get the most out of them? What are the unwritten values and norms in our company and how can we improve them?

  4. Enterprise

    1. Governance, risk, security, and compliance. We need to cope with structural and external forces such as investors, directors, regulators, vendor partners, security adversaries, and auditors, to whom we are accountable or who are otherwise constraining our options. What are the motivations for governance? How do we understand and control risk? How are we assured that our strategy, tactics, and operations are reasonable, sound, and thorough? And how do we protect ourselves from malicious adversaries?

    2. Enterprise information management. We’ve been concerned with data, information, and knowledge since the earliest days of our journey. But at this scale, we have to formalize our approaches and understandings; without that, we will never capture the full value available with modern analytics and big data. Compliance issues are also compelling us to formalize here.

    3. Architecture and portfolio. We need to understand the big picture of interacting lifecycles, reduce technical debt and redundancy, accelerate development through establishing platforms, and obtain better economies of scale. We do so in part through applying techniques such as visualization, standardization, and portfolio management. However, some of the suggested practices are costly and can interfere with our teams' performance.

  5. Appendices

    1. The major frameworks

    2. Project management

    3. Process management and modeling

    4. References

    5. Glossary

    6. Backlog

    7. Colophon

    8. Author biography

The boundary between the “Team” and the “Team of Teams” is a challenging area, and industry responses remain incomplete and evolving.

Emergence means formalization

The emergence model seeks to define a likely order in which concerns are formalized. Any concern may of course arise at any time — the startup founder certainly is concerned with security! Formalization means at least one or more of the following:

  • Dedicated resources

  • Dedicated organization

  • Defined policies and processes

  • Automated tooling

In general, startups avoid overly formalized process and project management. To the extent the concerns exist, they are tacit (understood or implied; suggested; implicit). Certainly, a small startup does not invest in an enterprise-class service desk tool supporting a full array of IT management processes or a full-blown project management office with its own vice president and associated portfolio automation. Simple work management, with a manual or automated Kanban board, is likely their choice for tracking and executing tasks.

But by the time they are a team of teams, specialization has emerged and more robust processes and tools are required. Finally, the more complex, enterprise-scale concerns at the end of the book are presented as part of a logical progression.

The danger, of course, is that the formalization effort may be driven by its own logic and start to lose track of the all-critical business context. By carefully examining these stages of maturation, and the industry responses to them, it is the author’s hope that the student will have effective tools to critically engage with the problem of scaling the digital organization.

Finally, the scaling model also emphasizes the critical importance of the high-performing, multi-skilled, collaborative team. Coordination and enterprise problems must be given their due, but too often the proposed solutions destroy the all important team value. As stated elsewhere in this book, it is possible that there is no higher unit of value in the modern economy than the high-performing team. Maintaining the cohesion and value of this critical asset is presented as a clear priority throughout the subsequent chapters.

Some of you may be familiar with the idea of a Minimum Viable Product (MVP), minimum marketable release, or similar. In these terms, it is important to understand that each section of the book represents an MVP but not each chapter. IT value cannot be delivered without the components discussed in each of chapters 1 through 3. The chapters of each section tend to be interdependent in other words.

Assumptions about the reader

  • This book is written at the advanced undergraduate/graduate student level. It is also intended for mid-career and senior IT practitioners seeking to update their knowledge.

  • It is currently available only in English.

  • There is no assumption of deep IT experience, but it is assumed that the person interacts with computers in some capacity and has basic technical literacy. They should, for example, understand the concepts of operating system and application software. An introductory course on networking or programming, for example, should more than adequately prepare someone for this book.

  • A person completely unfamiliar with computing will need to supplement their reading as suggested throughout the text. There is a wealth of free and accurate information on IT fundamentals (e.g., computing, storage, networking, programming, etc.)., and this book seeks more to curate than replicate.

1. Technically, ITIL is now just the abbreviation, but we spell it out here for reference.
2. Image credit Henrik Kniberg, used by permission