Mike Tiemann, now Program Director and Senior Faculty at FEAC Institute, and whom Steve Spewak and I met in 1996 at the Department of Energy, asked if I’d be interested in talking about the evolution of EAP in a keynote address in an upcoming EA conference. The idea intrigued me because it’d give me the opportunity to share the journey that took me from 1992 when Steve published the book and when we did our first project together, all the way to today when I’m discussing with EAP old-timers whether to (still) use at Shell.
So, thank you Mike.
In those days, JM&Co was known for their ISP, Information Strategy Planning, part of their Information Engineering (IE) methodology. You may remember at the time, Information Engineering was the methodology of the day, founded on, I think a belief, that all would be well if we could just put specifications in graphical form. Just like engineers who are able to communicate clearly with each other because they use engineering diagrams.
That same year Steve and I did our first project together for a utility in the Northeast, in Berlin, CT. In the middle of the project, somewhere in between the Business Model and the Data Architecture, Steve gives me this manuscript and says: “Do you mind proof reading this for me? I think I’m close to publishing. What do you think?” It seemed fine to me, I told him. I didn’t study it, you know. I had an Information Engineering project to facilitate. So although I was a believer in IE, I told him: “Seems fine”. “Good,” he says, “We are going to drop ISP and switch to my EAP methodology for the remainder of this project.”
Wait a minute here. First of all I was working for JM&Co, and second I was very comfortable with the logic of Information Engineering. So, for the record, I did put up a fight against the dark forces of EAP taking over the enlightened forces of IE. My friend Bob Palermo once said “You know that people are not really listening to you until they start asking questions, and that they are not really understanding you unless they start arguing with you.” And boy, did we argue, But Steve kept showing up at our doorstep with a bottle of wine -- he kinda invited himself to dinner -- and after dinner we continued the debate on the merits of EAP.
Long story short, in the end it all worked out well. In fact we found that we worked well together, that we made each other successful. Immediately we decided to go into business together and Steve and I founded Enterprise Architects, a few years later.
This started a series of very successful EAP projects. And with success I mean that projects were very well received by management, that they exceeded expectations in deliverables, and that they were conducted on time, and under budget. And each project added refinements to the EAP methodology, and this keynote lists the major breakthroughs of that evolution..
I’m sure you know that Steve passed away in 2004. He was too young. There was so much more that he and I wanted to do. I would very much like to present this keynote as tribute to my friend and mentor Steven Spewak.
“And now for something completely different”:
This drawing is from a 2007 article in the New York Times about free will, and whether free will really exists. But it was the monkey that caught may attention and I remembered how it changed my view on “being in control”.
What stuck with me was the monkey on the back of a tiger going backwards believing he’s in control just because he’s got a steering wheel in his hands. So, I’m bringing this up to make two points.
In this keynote, I don’t want to give the impression that I was in control of the EAP evolution, or that the evolution of EAP was a controlled process. Those of you who knew Steve, also know he wanted to keep EAP pure. And I, just like the monkey, wanted to react to the tiger shifting underneath me. Our clients pushed the evolution in EAP. Only in 2010 did I get off the tiger. I think.
But also, don’t forget this is a story. Don’t parse the story for facts. Just like the monkey, l too am looking back, at the facts not as they happened but as I choose to remember them, and as I choose to recast them to better illustrate the aspects of the evolution that are important to me..
So in this story, if they were listening in on this keynote, our clients might very well say “Did we do that?” “I didn’t know we did that!.” So bear with me and let the story unfold.
This blog version of my of 8 November 2011 keynote address is the second article on EAP 2.0. The first is the August entry:
EAP 2.0 - Twenty Years of Dr. Steven Spewak's Enterprise Architecture Planning.
CLASSIC EAP
I’m calling Steve’s EAP Classic EAP. and not EAP 1.0 because, as with software, you may come to expect that the older version is obsolete and will no longer be supported. Instead, I want to emphasize that, as with literature where the classics remain forever relevant, so is Classic EAP still relevant in terms of the problems it set out to solve.
What was the problem that Classic EAP addressed at that time, in 1992? In those days each business unit in a company or bureau in a government agency had its own budget. They each had the freedom to solve their own technology problems, and this freedom led to duplicative business systems being installed on multiple infrastructures. It would not be unheard of for each of the business units or each of the bureaus to request their own networks, and each their own accounting systems. Connecting them and converting them led to ever increasing numbers of interfaces and systems that had no business purpose, and this increasing complexity drained money, time and resources.
Steve identified the absence of a single blueprint for IT as the root cause of this complexity. And as applications and infrastructure were being built redundantly, with poor coordination, by each of the divisions of the enterprise, over time this gave rise to a “Winchester Mystery House” of systems. Evidently, what was meant to work together could no longer be made to work together. Managers would say “our systems don’t talk to each other”.
The solution Classic EAP proposes for this problem is developing a single blueprint for data, applications, and technology and developing a migration strategy to bridge the gap between the legacy infrastructure and an architected infrastructure. To execute the strategy, Classic EAP
Classic EAP is thus about defining a solution for a known technology problem and planning the implementation of that solution through a series of well sequenced technology projects.
Those of us who are in the EA profession have been developing and refining EA for 20 years. In the federal government we have the Federal EA, we have the processes to define, build, maintain and use the EA, and we have a planning process like CPIC to select projects, and we have portfolio management tools to plan and manage their implementation. On the commercial side, we have established companies like Oracle and SAP with proven ERP suites, with well defined architectures and totally integrated applications.
Why then, are we so bad at implementing these architectures? Why do we see such poor results in producing business benefit? Why do projects that deliver capability on-spec, on-time and on-budget, still fail to deliver business benefit? “By some accounts, up to 30 percent of all SAP implementations fail to meet the buyer's expectations.”
A Google search yields many explanations:
The percentage I mention in the graph is not meant to be factual in that I have no source for this nice round 20 percent number. It is meant to be indicative. But any one-minute search on Google will turn up studies that confirm this with varying definitions of benefit and varying degrees of failure.
Notice also that I’m introducing a paperweight at the bottom right of the graph. It’s the symbol I will use throughout this presentation to indicate waste, to indicate that technology was delivered on-time and on-spec, but didn’t generate business benefit.
So what’s going on?
What was the problem that Classic EAP addressed at that time, in 1992? In those days each business unit in a company or bureau in a government agency had its own budget. They each had the freedom to solve their own technology problems, and this freedom led to duplicative business systems being installed on multiple infrastructures. It would not be unheard of for each of the business units or each of the bureaus to request their own networks, and each their own accounting systems. Connecting them and converting them led to ever increasing numbers of interfaces and systems that had no business purpose, and this increasing complexity drained money, time and resources.
Steve identified the absence of a single blueprint for IT as the root cause of this complexity. And as applications and infrastructure were being built redundantly, with poor coordination, by each of the divisions of the enterprise, over time this gave rise to a “Winchester Mystery House” of systems. Evidently, what was meant to work together could no longer be made to work together. Managers would say “our systems don’t talk to each other”.
The solution Classic EAP proposes for this problem is developing a single blueprint for data, applications, and technology and developing a migration strategy to bridge the gap between the legacy infrastructure and an architected infrastructure. To execute the strategy, Classic EAP
a) defines a comprehensive set of applications necessary to support the functions of the enterprise,
b) sequences the implementation of those applications for optimal benefit, and
c) uses that sequence to develop an infrastructure migration plan and an application implementation plan, over a period of five or six years. We would now call that an application consolidation plan, like we might do a data center consolidation plan.
Classic EAP is thus about defining a solution for a known technology problem and planning the implementation of that solution through a series of well sequenced technology projects.
Those of us who are in the EA profession have been developing and refining EA for 20 years. In the federal government we have the Federal EA, we have the processes to define, build, maintain and use the EA, and we have a planning process like CPIC to select projects, and we have portfolio management tools to plan and manage their implementation. On the commercial side, we have established companies like Oracle and SAP with proven ERP suites, with well defined architectures and totally integrated applications.
Why then, are we so bad at implementing these architectures? Why do we see such poor results in producing business benefit? Why do projects that deliver capability on-spec, on-time and on-budget, still fail to deliver business benefit? “By some accounts, up to 30 percent of all SAP implementations fail to meet the buyer's expectations.”
A Google search yields many explanations:
- Failed to adopt, adhere to, and support standard work processes
- Lack of visible, vocal, and effective executive sponsorship
- Lack of formal and disciplined project management
- Turn-over of key staff
- Inability to identify and mitigate risks
- Insufficient training
- Troubled user adoption
- Too much software customization
- Project viewed as an “IT” project
- Dirty data or insufficient time for data cleaning
The percentage I mention in the graph is not meant to be factual in that I have no source for this nice round 20 percent number. It is meant to be indicative. But any one-minute search on Google will turn up studies that confirm this with varying definitions of benefit and varying degrees of failure.
Notice also that I’m introducing a paperweight at the bottom right of the graph. It’s the symbol I will use throughout this presentation to indicate waste, to indicate that technology was delivered on-time and on-spec, but didn’t generate business benefit.
So what’s going on?
It’s more complex than technology. With the benefit of hindsight, I realize now I was solving the wrong problem. The problem that I can see is often the only problem that exists for me and it obscures from my view the more complex problem that lies behind it. I could not see past my hammer, you know, that hammer that makes every problem look like a nail.
So it’s more complex than building tools, it is also more complex than learning to use the tools.
A technology approach is analogous to hoping to loose weight by buying a new blender and learning how to operate the new blender.
It was however a speech by Mr. Durkin, that made me drop my proverbial hammer entirely. In his speech, Mr. Simon Durkin, CEO of Salym Petroleum Development (an oil operator in Western Siberia, Russia 50/50 owned by SHELL/Gazpromneft) explained that to avoid a premature abandonment of the oil reservoir, productivity would need to go up, and for productivity to improve, he said, “We need to change the way we work.” This phrase struck me as profound – I don’t know about you – but for me it meant that Mr. Yonke was right. If you don’t want to change the way you work, what do you keep buying new blenders for?
But what will it take to change the way we work? I believe that we are now stepping outside the realm of IT projects; a change of the way we work is in fact a transformation of the business. Such transformational programs don’t lend themselves to the usual process of defining the problem, envisioning a solution, creating a business case, then launching the project. Getting to the root of big, long-standing, intractable problems, requires a willingness to engage senior and junior people to define the problem from all sides, to understand why previous efforts failed to solve it, and ultimately have the breakthrough that re-frames the problem at the level of root causes. My own understanding of a problem in full context, was shaped by Jeffey Liker’s “The Toyota Way” The subtitle of the book is “14 Management Principles from the World’s Greatest Manufacturer” and I’m referring specifically to Principle 13: Make Decisions Slowly by Consensus, Thoroughly Considering All Options. Implement Decisions Rapidly.
To depict breakthrough in this presentation, I will combine two concepts that you are already familiar with. I will use the Ishikawa or fish-bone diagram to depict the research, the “understanding a problem in full context” component of breakthrough. And I will use a diagram containing dots, as in the connect the dots game, to depict the solution component of breakthrough: “solving a problem in full context”.
Our first responsibility then, when conducting an EAP 2.0 project, is to facilitate and “Achieve Breakthrough.”
There are two more fundamental responsibilities that we facilitate in EAP 2.0 that I want to just briefly mention already. They are: Seeking Accountability and IT Delivery Process Modernization. EAP 2.0 uses all three to indeed change the way we work. I’ll explain later.
But let’s get back to the journey that led to EAP 2.0. Let’s visit some of the companies that were successful in defining and implementing architectures.
The Journey
One company we worked with stands out as being successful with EAP.
And spectacularly so.
To be continued
No comments:
Post a Comment