This week marked an event I’ve been anticipating for a long time: the general availability of the revised edition of my book, Architecture and Patterns for IT: Service Management, Portfolio Management, and Governance (Making Shoes for the Cobbler’s Children).
(Amazon should go live on Friday, including the $9.99 Kindle version, such a deal – but DON’T buy it before then via Amazon, you’ll get the 1st ed. Also note if you click “Look Inside” on Amazon the cover is wrong, but the rest is the actual 2nd ed. Sigh.)
This was a substantial rethinking and rewriting of the material. Some of the new material includes:
– Consideration of Lean IT, and how to interpret it from an architecture perspective
– Precise distinction of IT lifecycles and processes from IT function, and an entirely new lifecycle/process reference model based on BPM best practices
– Revised and simplified IT data model
– Updated IT management systems architecture
– Updated IT patterns, categorized by IT process and lifecycle
– Updated matrices cross-referencing lifecycle, process, function, data, and system
It’s not a short book, and in the past six years I’ve heard from many people who use it as a desk reference, fewer who’ve sat down and simply read the whole thing. Why did I write the thing in the first place? The motivation is still best summed up by the second subtitle: “Making Shoes for the Cobbler’s Children.” To quote the first edition:
Would you trust a banker dressed in shabby clothes? An auto mechanic whose car backfires and emits black smoke? How would you feel if you visited a financial planner’s office and saw past-due credit card notices on her desk?
Information technology is who society turns to when it needs to organize complexity. If IT cannot solve its own problems, how can it be entrusted with the burdens of its customers?
Perception is reality. An information technology organization that appears to not know what it is managing does not inspire confidence, no matter how resilient system operations may be, or how pleased individual project sponsors are. Culturally and psychologically, society’s expectation is that IT will be organized, rational, and measurable.
From the second edition:
Massive IT capital investments and supply chains, critical operations, and pivotal implementation initiatives are managed with emails, spreadsheets, and seat- of–the-pants intuition, with narrow goals elevated over global objectives. Often absent is the data-driven, analytic, continuously improving management philosophy employed in the primary value chains of the world’s most successful companies.
In order to improve IT management, we need to make its methods more definite. The current industry frameworks (ITIL, COBIT, and CMMI) with the most influence on enterprise IT provide much good material, but fall short of being definite – they are often characterized as “not prescriptive.” I reviewed them all in depth, treating them as statements of requirement. They served as the “what” for the “how” of the book.
I think there’s been a tendency in the industry to think that prescriptive frameworks would have to be way too long. If one insisted on every task and activity being documented, that would be the case. However, there’s another way to look at creating a definite method, and that is by using top-down enterprise architecture (EA) techniques. EA, as I apply it, requires first listing the major concepts of interest and ensuring that they are mutually exclusive and comprehensive. For example, distinguishing process from function was a huge help here. It gave me a new lifecycle/process graphic depiction that I like a lot – it represents my experiences in Fortune 100 IT shops better than any other picture I’ve seen:
The four horizontal lifeycles interact in unpredictable ways, and the job of the IT service organization is to “line them up” to create, deliver, and improve services. This is easier said than done, especially given the immature tools and practices we see today in large scale IT management.
The “Accept Demand” process is a privileged process; it can be seen as front-ending the other eight IT processes, and if managed in this way gives the ability to control IT demand in a unified way – a hot topic lately in the industry. Notice that many of the usual suspects such as capacity, availability, problem, service level, and IT financial management don’t appear here. That’s because I view them as functions, not primary lifecycles or processes that span boundaries and serve as the critical focal points for IT collaboration. Some of those activities might be found in the generic “Improve Service” process. Such a process, while well accepted in the IT management frameworks, is often not understood to be a primary, demand-generating process competing for resources with things like Project Management.
I don’t have the room to go into the functional or data architectures, but here’s the overall systems architecture. This has gone through many iterations and yet I still find myself questioning it every day; certainly my activities here at EMA give me plenty to reflect on!
One notable omission is Application Lifecycle Management, which would generally live in the bottom left corner. (I’ve been struggling with its scope, which is why I haven’t put it in yet.) Notice the rough counterclockwise tendency of the picture. Notice also the proposed “Continuous Improvement System,” a system type that doesn’t exist in the market place yet, but which I think is essential to coordinate the IT activity that falls into the gray area between projects and service desk. (See ITIL 2011′s call for a CSI Registry, and Dee Carri’s excellent “Integrated Compliance, Quality, and Process Management System” in BPTrends.)
Finally, the popular patterns sections have been rewritten and enhanced. I structured the patterns around the processes and lifecycles, to keep them aligned with end to end IT value, and added a number of new patterns that have presented themselves over the years since the first edition.
As always, there are a few regrets. I’d hoped to do something significant with systems dynamics in this book, but that will have to await another volume. More could have been said on any number of topics (my thinking on IT Finance and Software Asset Management has certainly developed further since the manuscript was finalized). I’ll be supplementing some of the less well covered areas on my blogs from time to time.
As always, I am interested in feedback from anyone. Please email me at firstname.lastname@example.org if you have comments, corrections, questions, or criticisms of the book.
If you’re interested in multiple copies, drop me a line & we’ll hook you up with the publisher. Also, VERY interested in hearing from anyone who is using as a classroom text.