One of my goals in designing a new survey textbook was to "drink my own champagne." I've been an architect and concerned with systems and service design in many forms. An educational experience is a service, requiring design. My first book, Architecture and Patterns for IT, was not providing the right experience. In thinking about a third version, I knew I had the problem of narrative, of learning progression. What was the right order of the material for my students?
I examined a lot of textbooks, and also drew on my knowledge of industry standards. I perceived two major narratives in these bodies of knowledge:
- the "Stack"
- the "Lifecycle"
The "Stack" is how we teach technical topics. Algebra and trig before calculus; algorithms and data structures before applications. We also see it in architecture: business, data, applications, technology. The "Lifecycle" is how we structure guidance: plan, build, run. (It's also influential in software engineering programs, as distinct from computer science).
The trouble with the "Stack" is what Anshu Shama calls the "stack fallacy": the “the mistaken belief that it is trivial to build the layer above yours.” Sharma thinks that building "down the stack" is easier, but I've seen plenty of failures that way, for example when architects develop ivory tower designs. I was trying to use a top-down architectural "Stack" paradigm in teaching the first 3 semesters of my course.
The problem with the "Lifecycle" is obvious: it promotes waterfall thinking. No matter how you squint at guidance like ITIL and PMBOK, and no matter how often advocates insist that you just need to "run the lifeycle faster," the mental model ties you down. What does it say when you devote a lecture -- or an entire three credit course -- to "Requirements" or "Testing & QA"? I don't think it's the right approach for the digital world.
So I went looking for something different, and I found it in discussions of organizational scaling, Dunbar's number, Barry Boehm's spiral model and Alistair Cockburn's concept of walking skeleton. I struck on the idea, why not use "from startup to enterprise" as the basis for the book progression?
A big problem with my earlier approach is that I had been assuming enterprise scale throughout the course, which is bewildering for students. On the other hand, students can more easily identify with "Larry Page and Sergei Brin, in the garage, starting Google." Even if students' career intent is to go into an enterprise, it's still a useful thought experiment. From the book:
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 information technology 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.
But the "startup" phase is only the first quarter of the book; here are the four major parts:
- Team of Teams
The question in terms of management capabilities and practices is, what do we need, when? We've been subjected to near-religious zealotry for years in our industry from advocates of various approaches who seem to believe their preferred methods are one-size-fits-all. But I don't see too many startups putting in a full set of ITSM processes, nor do I see many enterprises without formal IT risk controls and IT vendor management. So when do these things, "become things"? And why? I think answering these questions provides a good basis for the book's progression.