I'm struggling with a new preface and introduction for my 2nd edition. So here goes with new writing. Comments greatly appreciated. If you read the passage below, would you buy the book?
==============================================================
Around 2003, when I was leading an application team at Best Buy, I met a senior business executive. The conversation went something like this:
Exec: "So, what do you do?"
Me: "I'm building a metadata repository."
Exec: "Boy, that sounds like a business we shouldn't be in."
Demoralizing! Yet this interaction, and others like it, sowed the seeds of this book.
A light bulb went off as I was reading an interview with Ralph Szygenda, who was then Chief Information Officer at General Motors. In 2003, he said:
"The next thing is IT ERP [enterprise resource planning]. At GM the complexity of managing IT is an astronomical thing. How do I manage hundreds and even thousands of SLAs? And how do I cash in on penalties if I don't monitor them? There are software companies that have great interest in IT ERP. One module could be project management, another might be SLA management, another one might be operational reporting for problem resolution or configuration or change management."
In many ways, that single passage inspired the next eight years of my career, including both editions of this book.
I had spent several years previously building ERP systems as an Accenture consultant, and was familiar with concepts like "procure to pay" and "hire to retire." And as I focused more on internal IT systems, the question kept coming up - why didn't all this expensive and often troubled IT activity have a similar center of gravity? I'd already worked in organizations with IT budgets approaching one billion dollars, and had witnessed the ongoing struggles with failed projects and operational outages. Szygenda's call therefore hit me like a thunderbolt, and started my quest.
The quest led me to the major IT "frameworks" - systematically organized "best" or "good practice" collections, the best known of which are the Information Technology Infrastructure Library (ITIL), Control Objectives for Information Technology (CObIT), and the Capability Maturity Model - Integrated (CMMI). I dove into all of these, studying and comparing them with my daily experiences. (There were interesting contradictions, many of which I discuss in this book...)
This education was invaluable, as it gave me a framework for better understanding the purpose of the systems I was developing. The outsourcing of Best Buy's IT to Accenture in 2004 provided further insight. I observed the strategy and priorities of the incoming Accenture IT leadership, who had a priority of managing "IT demand management." To support this, they implemented a new project portfolio management system, which had interesting overlaps with the initiatives I'd been leading.
Of all the major functional areas in the enterprise (sales, marketing, supply chain, outbound logistics, finance, HR, and so forth) it was and is clear that IT is the most poorly supported in terms of process integration, common data, and centralized systems to bring the diverse actors and concerns together. There was not, and still is not, the equivalent of PeopleSoft or SAP for the IT function itself.
The cynical might say, "So? There's been so many failures of ERP, that's probably a good thing!" But I disagree. ERP has also succeeded brilliantly for companies that executed its formidable culture change requirements.
I think there is a more fundamental point. The ERP successes arose because core problems like materials forecasting, process integration, and the information needed for decision support were clearly stated and understood, in a way that led to effective automation. And - the efforts of the IT frameworks notwithstanding - I don't think we have done that yet for large scale enterprise IT. Not quite at the level we need to, in order to manage IT as a holistic system and key subsystem of the modern enterprise.
Therefore - the book you are holding is the analysis and high level design of an IT value system.
It is an enterprise architecture. It was written through first defining the fundamentals of IT value, identifying the largest, longest-lived flows of IT activity, understanding the major processes that seek to coordinate those flows, and considering the information and automated systems required.
It treats major IT industry frameworks and related literature as a statement of requirements. Process, information, and distributed systems modeling techniques were applied to deriving a unified, vendor-neutral structure from these requirements, an architectural effort no different from applying those techniques to supply chain or HR problems.
The approach is inspired by Toyota’s great Lean thought leader Taiichi Ohno and his call to “study the work.” As a consulting enterprise architect for the “business of IT," I have had privileged visibility into large IT organizations for extended periods of time, with the responsibility of investigating many matters large and small. Out of this experience, my intent has been to produce a next step book for those saying:
“Okay – let’s ‘Run IT Like A Business.’ Now what?”
I sincerely hope you find it useful.
