I review a lot of books about process and architecture, and I have fallen into making some assumptions. First, people who write about “Enterprise Architecture,” usually assume that it is an IT discipline. Most will make a bow to the importance of trying to understand what the business is about, but, ultimately, they will focus on trying to define the IT resources needed by the organization. Second, presenting technology in a novel format is not a good idea. It usually just means having a character in a story give lectures to someone else about technology, and it is not an efficient way to present information. Relying on these assumptions, when I got RecrEAtion: Realizing the Extraordinary Contribution of Your Enterprise Architects by Chris Potts in the mail I didn’t expect to spend much time with it. To be honest, I planned to skim it in the course of an hour on a Tuesday morning and then move on to more pressing matters. As a matter of fact, I started reading RecrEAtion at 9 in the morning and proceeded to spend the rest of the day reading it, taking notes, and grabbing other books to follow up on tangents. I haven’t thought this hard about a book, or been as stimulated by one, in several years.
The book is well written and the author actually manages to communicate information in rather dramatic conversations that carry the reader forward quickly, as a novel is expected to do. As I started into the first chapter, the protagonist, Simon, a British enterprise architect, newly hired by a US company, arrived at the New York headquarters of the firm for his first day of work. His new boss, the Chief Technology Officer of the firm, took him to meet the CEO. Simon’s initial conversation with the CTO and then the CEO convinced me that at least my first assumption was correct. Simon believed he was there to figure out how he could develop a good technology map of the new firm. He told the CTO about his disappointment with his last firm that had moved Enterprise Architecture to the Strategy group, and wondered aloud about business executives who think they understand IT well enough to really make Enterprise Architecture decisions.
This went on just long enough, and was believable enough, that I was about to put the novel down, when, during the second CEO interview, his boss explained that he was the Enterprise Architect of the company, but he would be glad to have Simon’s assistance. The CEO could have been a former IT executive, but in fact he wasn’t. He simply meant what he said: The CEO is responsible for structuring the organization, determining goals, and deciding what kinds of investment to make. To deliver on his promise, a week later the CEO asked Simon to accompany him on a trip to visit the Tokyo subsidiary with him. And, once on the plane, he gave Simon the financials of the subsidiary and asked him what he thought their problems were. This would be an interesting test for any Enterprise Architect – give the architect the operating results shown on page 48 of RecrEAtion and see what he or she would make of them. Simon probably showed more knowledge than most would when and reformatted the various numbers into two ratios: Revenue/Dollar of Operating Cost, and Profit/Completed Transaction. Without looking at these ratios, since the gross numbers kept going up, one probably wouldn’t have noticed that both had peeked and were beginning to slowly decline. The productivity and profitability of the Tokyo subsidiary was going down, even as their gross income continued to grow. This is the point where I grabbed my Financial Management textbook and started doing some subsidiary reading.
The analysis of ratios is, of course, something that is taught in every MBA program and it is the heart and soul of what bankers do when they think about leading money to a business entity. Rarely, however, do financial analysts follow through from specific ratios to an analysis of business performance problems and then to specific suggestions about how to improve business processes.1 That’s exactly what Simon’s CEO proceeded to do. Simon became so flustered that his CEO stopped their discussion, and told Simon that the choice was his: Did Simon want to come with the CEO to meet the Japanese CEO and talk about the performance of the subsidiary and its “architectural problems,” or would Simon prefer to meet with the Japanese firm’s IT head and discuss their IT systems? After a bit of hesitation, Simon elected to meet with the CEOs and thus begin his real career as an Enterprise Architect.
At another point, when Simon was trying to explain to his CEO what he did, he mentioned that he put quite a bit of emphasis on business processes. The CEO said that he did too – but primarily on the customer’s process. This threw Simon, who explained that this was the inverse of the way he was used to thinking about process. As someone who focuses primarily on process, I was impressed. Focusing on customer processes is cutting edge thinking among process specialists. Many of the process professionals I know wouldn’t have known exactly what the CEO was talking about, even though the ideas have been getting more and more attention in process circles since at least 2005.2
RecrEAtion is full of interesting ideas like the ones I have mentioned. I found myself making notes and pulling other books off the shelf in an effort to understand the implications of the ideas being presented. Simon ends up going to several different subsidiaries, discovering new performance measures, and gradually developing a methodology that relies on a high-level performance analysis as a way to diagnose problems and suggest solutions. RecrEAtion describes Enterprise Architecture as it ought to be practiced. Enterprise Architecture should be grounded in an analysis of the business, its current performance, and the relationship between its business processes and its performance. One ought to proceed to technology only in order to better understand or to improve those business processes. Unfortunately this isn’t what typically happens, although to be fair, few Enterprise Architects have a CEO as bright and flexible as Simon’s fictional bass. (Certainly one good way to use this book is to give copies to the business executives you work with.)
Over the years I have largely given up on the term “Enterprise Architecture,” believing that it has become so strongly associated with IT architecture that it has little to offer non-IT managers. In the past few years I have tended to refer to my own concerns as either “Business Process Architecture” or simply “Business Architecture.”3 Chris Potts has given me hope, however, and I think I am ready to see if I can get used to using the term “Enterprise Architecture” again. This year IRMUK is holding a conference that will be, in effect, a co-meeting of its annual EA conference and its annual BPM conference. I noticed that Chris Potts is giving a day long tutorial, Driving Business Performance with Enterprise Architecture, and I plan to be in attendance.4 Maybe business process practitioners and enterprise architects are ready to initiate a new dialogue.
Meanwhile, this is an important book. Although I’d hardly recommend it as a novel, it is a fast and dramatic way to present some important ideas, it works quite well. But what I really like, however, is the way it introduces and supports the idea that Enterprise Architects should be primarily focused on the performance of the firm. They should be positioned to help the CEO organize and then improve the company. The technical details, like the ratios used to analyze process performance, are interesting, as is the methodology that is developed in this book – but more than anything else, this book represents an inspired effort to define the role of the Enterprise Architect. If you are an Enterprise Architect, or someone who has to manage one, and can only read one book about Enterprise Architecture this year, make it Chris Potts RecrEAtion. It will certainly make you think, and it just might change your idea of what Enterprise Architecture is all about.
Republished with permission from the “Journal of Enterprise Architecture.”
References
- A good exception is the work of the Supply Chain Council – a consortium of supply chain executives — and their SCOR architecture. The SCOR methodology provides a way of mapping multi-company supply chains, and a scorecard for tracking performance. Moreover, SCOR provides a set of specific ratios that member organizations can apply to evaluate the performance of a supply chain. For more information on the SCC, visit www.supply-chain.org. For a description of the SCOR methodology, see Peter Bolstorff and Robert Rosenbaum’s Supply Chain Excellence (AMACOM, 2007).
- For an excellent introduction to the idea of starting an analysis with the customer process, see James Womack and Danie Jones Lean Solutions: How Companies and Customers Can Create Value and Wealth Together. (Free Press, 2005) An overview of this approach is available at www.bptrends.com if you will search for “Model the Customer Process.”
- For a recent article I wrote from this perspective, go to www.bptrends.com and search for “What is a business architecture.”
- For more information on the June 8-10, 2011 IRMUK EA-BPM joint conference, go to www.irmuk.co.uk/bpm2011/ or to www.irmuk.co.uk/eac2010/index.cfm.