Practicing for twenty years Dr. Spewak’s “Enterprise Architecture Planning” methodology, published in 1992, we got ample experience of what worked well and didn’t work so well. Nonetheless, with each project we learned, with each project the method evolved. This article provides a brief description of the current state in this evolution; the story of the journey up to this state is a much longer one. One day, I hope to find the time to write that story, the long-awaited sequel to EAP perhaps. Yes, this evolution was shaped by project experiences, but even more so by the people with whom I shared these experiences, who’ve given me feedback and have let me benefit from their insights. I’d like to mention them and credit them for their particular contributions.
First among them, of course, is the late Dr.Steven Spewak himself, a dear friend and mentor for so many years. It is said that you haven’t really listened to an idea or haven’t understood an idea until you’ve fought it. I can say, with fond memories of our many night-long discussions in which I did the fighting, and in which I (almost) always lost, that I’ve mastered Steve’s EAP. Thoroughly. I will call his seminal work “Classic EAP.”
There is Richard Yockman, then CIO of DOE’s Office of Science, who taught me that the purpose of conducting EAP projects is not to give the Client a plan but to fix the client’s IT’ planning process. There is some significance here, because it was the first time that I concluded that as consultants we are there at the Client’s to deliver a product. We’re there to change a process. Nothing wrong with being a hired hand and helping out in an FTE shortage. Just don’t confuse the two.
There is David Walker, then CIO at Aera Energy in Bakersfield, CA, who engineered probably the most successful EAP implementation project ever.
At the end of an EAP project, people often asked us “Will this plan work?” to which Dr. Spewak just as often repeated the blunt warning he gave management at the start of any EAP: “The majority of EAPs fail.” Yet, Aera’s EAP (1999) succeeded in a spectacular way. I thus spent numerous hours with Mr. Walker and his staff, in Bakersfield, in Moscow and The Hague to discover the secret sauce of Aera’s success. I have to credit Mr. Walker for the guidance and insights about the Aera business transformation, which enabled me to put the two main concepts of EAP 2.0 on the map: Breakthrough and Accountability. (more below)
Finally there is my friend Stuart Scott, with whom I worked on Information Engineering projects in the early 90ies, and who later specialized in BPR projects. Independently from each other we arrived at “accountability” as key ingredient for the secret sauce of success. Projects fail when they are underfunded in the dollar sense, but just as often they fail when not enough political capital is brought to bear on the project. Mr. Scott provided the “key stone” for making the secret sauce, what I now call Seeking Accountability. His techniques enable EAP 2.0 to generate that capital.
Classic EAP and EAP 2.0
The fundamental difference between Classic EAP and EAP 2.0 is that Classic EAP is about defining a solution for a known technology problem and planning the implementation of that solution through a series of well sequenced technology projects, whereas EAP 2.0 is about understanding a business problem, amassing the political capital to transform the business, and ensuring that business transformation projects indeed deliver business benefit.
In EAP 2.0 we shifted our emphasis from assisting the CIO with, “What capability are they missing?” to assisting the CEO with, “How should we be doing this differently?”
Classic EAP
Classic EAP is a culmination of Dr. Spewak’s analysis of failed IT projects. In 1992 he published his seminal work Enterprise Architecture Planning in which he provided a better methodology for planning IT projects. He improved on the budget-based methods of those days in which projects that were independently approved and business-case justified competed to stay above “the cut-off line”. In addition, he identified a more fundamental problem: the complexity of the IT infrastructure. As the existing infrastructure had grown more complex over time, the IT organization was no longer capable of providing quality information to the people who needed it in a timely fashion. As a result, the potential of new technology could no longer be exploited.
Dr. Spewak 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 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 those applications for optimal benefit, and c) schedules their roll-out in a long-term application implementation plan, over a period of five or six years.
It should be noted that the scope of an EAP strategy is massive. In one program, functional area by functional area, application by application, redundant functional applications are consolidated, technology is homogenized across the enterprise, and data can be shared among people who need it. To quote from Salym Petroleum’s internal corporate magazine, “…when business needed additional systems support for a certain function, Aera’s IT department did not build or install another computer system. Instead it removed two or three of the existing ones. In fact, since Aera started EAP in 2000, they had removed 50,000 spreadsheets, 4,000 Access databases and replaced 500 other systems with just a few data capture systems and a single Enterprise Reporting Warehouse…”
In summary, Classic EAP defines technology and automation we don’t have (the gap) and schedules projects to acquire it.
EAP 2.0
EAP 2.0 starts from a different position on the nature of the problem, perhaps best said in the words of Simon Durkin, CEO of Salym Petroleum in Moscow, Russia:
“… in the face of increasing complexity and costs, and decreasing yields, we need to change the way we work. …” If we are to improve our business we need to transform its processes.
Process change then – in contrast to technology acquisition – is what the EAP 2.0 methodology defines and schedules. That is, the meaningful unit of work scheduled in an EAP 2.0 plan is a process modernization or business transformation project. The key outcome of a business transformation project is delivering a predetermined business benefit, and integral to doing this is modifying traditional project controls so that we manage for process outcome -- as opposed to managing for project deliverables.
Of course, we are not the first ones to address process improvement. Toyota has turned relentless focus on driving out process waste into a culture, very well described in Jeffrey Liker’s The Toyota Way, 14 Management Principles. But driving out waste is only part of it; the commitment to discuss process problems and solutions, not just with the process owner but with all those who are affected, is just as much part of their culture. This discussion of the wider context is what we spend significant time on in EAP 2.0 (the 55 minutes of Einstein’s hour) as we build up an extensive body of knowledge concerning the subject process. We’ll call this Process in Context.
In Classic EAP, this body of knowledge is the enterprise architecture. It is a knowledge base of the solution objects in the form of data, applications, and technology. It describes dependencies between the objects of the solution, provides context for the analysis of alternate solutions, and enables project definition and project prioritization. Given a certain benefit, in Classic EAP solutions compete with each other on cost.
In contrast, EAP 2.0 builds the knowledge base of (all) the processes that make up the relevant context of the subject process. It helps understanding Processes in Context better if at first we allow two types of processes. Ultimately though, 5 years from now, we recommend treating processes uniformly.
The first type are Value (or Value Stream) processes. They are the upstream and downstream processes that figure in the subject process’ value stream. They may also include what Michael Porter’s Value Chain labels as support process: Purchasing, HR, IT Delivery, etc …
The second type are “alignment” processes. These processes have to do with the root cause of the subject process’ inefficiency. By seeking answers, five "why"s-deep into a root cause, we observe facts about the history and culture that gave rise to the process' current performance. Except, each such fact is expressed as an outcome of a process. Once we are able to express the "bad" outcome, we can also express the desired outcome, identify the process that produces that and find the process owner. We call them alignment processes, because our position is that the root cause of inefficiency is poor alignment.
EAP 2.0 thus expresses the results of its research as Processes in Context of the subject process. There’s always three questions to ask: what is the desired outcome, what process produces that outcome, who owns that process. To modernize the subject process, most processes in context are going to be affected, and the issue the process owner needs to deal with is whether he has the tools to change the process. The answer is almost always no. This is fundamentally different from answering the question whether we have the tools to acquire/build the technology. The answer to that question is almost always yes.
Examples of context processes,
This process context analysis will lay bare any business transformation problems and it is this clear definition of the problem that holds within it the description of the solution. The majority of our effort is thus spent in building this knowledge base, (In full agreement with Einstein “spend fifty-five minutes defining the problem and only five minutes finding the solution.”)
This simultaneous understanding of the problem, in context, and of the solution, in context, is the EAP 2.0 Breakthrough.
How is this done practically?
The first step towards breakthrough insight is developing the enterprise’s Concept of Operations (ConOps). The ConOps is a comprehensive and detailed (50+ pages) vision of how future enterprise processes are conducted and how they interact, with particular emphasis on those processes that either are the biggest constraint to 100% efficiency or hold the greatest opportunity for improvement. The ConOps also estimates a quantitative change, expressed in dollars over time, in outcomes of the envisioned process compared to the current process. That is, constraints and opportunities are translated in hard quantifiable benefits, which later on will figure in prioritizing business transformation projects.
Notice how the Classic EAP “Business Model” is different in content and purpose from the EAP 2.0 “ConOps”. The Business Model describes what “activities” take place now -- remember, in Classic EAP processes are verboten -- and serves to establish consensus on which business activities need automation support. The ConOps expounds the company’s vision and builds consensus on how the business will operate differently in the near future, say five years from now, and thus on processes that need modernizing.
The second step towards Breakthrough is the analysis of the Alignment type processes.
“Projectizing” the Solution. EAP 2.0 adds Benefit Realization tasks to a process transformation project’s work breakdown structure (WBS). In essence, Benefits Realization’s main concern is ensuring that anticipated benefits are indeed realized. To that end, it does three things. - It adds tasks to the project, like define and measure benefits (for a complete task list, read here), so that a clear path towards reaching process outcome is defined. - It modifies project controls to manage for business outcome rather than for project milestones. - It assigns accountability for each of the outcomes. Clarity on accountability and assigning the “correct” accountability avoids instances of “doing someone else’s work”. Benefits Realization seeks to tie the accountability for benefits delivery back to the various owner of the processes in context.
Benefits Realization thus connects the dots between the full understanding of the solution and “projectizing” an implementation of the solution which ensures achieving the desired outcome.
We are not there yet!
Breakthrough is not enough. Having a clear understanding how each of the processes in context need to be modernized themselves AND having a clear agreement on who their process owners are, does not yet guarantee that these same process owners will spend political capital and deliver. Understanding the task at hand does not yet commit the capital to see the project through. And without agreement to spend capital, political or other, the project has little chance of succeeding and should not be started.
Sometimes this hard-to-come-by capital is simply a manager’s time. The time necessary to keep the business going at full speed while at the same time changing the way the they work. Lke changing a flat tire while driving at sixty miles an hour.
We believe that one factor, above all, lies at the root of successful business transformation. In the successes we’ve seen, the people accountable for running the business were also accountable for the transformation. They did not create a separation between doing business and improving how they did business. The person “driving the car” was also in charge of “changing the tire.”
In the Seeking Accountability phase of EAP 2.0 we facilitate the conversations that need to happen to ensure that accountability rests where it belongs. Part of our challenge is that most companies have a seemingly logical division of labor:.Accountability for transformation lies with the PMO and not with the manager who’s accountable for running the business. That is, the business “driver” supposes his job is merely to drive the “car,” and leave the “repair job” to the “transformation mechanics.”
The first visible result of Seeking Accountability is a manager who takes accountability both for the daily operations of a business process and for its continual improvement. The second visible result is a cross-functional transformation team that functions as a collective “we.”
Conclusion
As laid out above, there is a meaningful difference between Classic EAP and EAP 2.0. I have sketched that difference perhaps in terms that were too black and white such that it will lead to a polemic. I hope not. Classic EAP was loved, it is tried and proven, and I enjoyed conducting them. Steve Spewak’s EAP will forever stand alone.
In the end I feel EAP 2.0 is not so much an evolution of Dr. Spewak’s EAP. EAP 2.0 is not an accumulation of evolutionary steps on top of Classic EAP. I think it was I who accumulated small insights that made me make a clear, clarifying, exhilarating 180 degree change. With apologies to Mr. Carville “It’s about the process, stupid”
.
The power of EAP 2.0 lies not in erecting architectures or planning technology acquisitions, but in helping transform business by Achieving Breakthrough with Accountability.
First among them, of course, is the late Dr.Steven Spewak himself, a dear friend and mentor for so many years. It is said that you haven’t really listened to an idea or haven’t understood an idea until you’ve fought it. I can say, with fond memories of our many night-long discussions in which I did the fighting, and in which I (almost) always lost, that I’ve mastered Steve’s EAP. Thoroughly. I will call his seminal work “Classic EAP.”
There is Richard Yockman, then CIO of DOE’s Office of Science, who taught me that the purpose of conducting EAP projects is not to give the Client a plan but to fix the client’s IT’ planning process. There is some significance here, because it was the first time that I concluded that as consultants we are there at the Client’s to deliver a product. We’re there to change a process. Nothing wrong with being a hired hand and helping out in an FTE shortage. Just don’t confuse the two.
There is David Walker, then CIO at Aera Energy in Bakersfield, CA, who engineered probably the most successful EAP implementation project ever.
At the end of an EAP project, people often asked us “Will this plan work?” to which Dr. Spewak just as often repeated the blunt warning he gave management at the start of any EAP: “The majority of EAPs fail.” Yet, Aera’s EAP (1999) succeeded in a spectacular way. I thus spent numerous hours with Mr. Walker and his staff, in Bakersfield, in Moscow and The Hague to discover the secret sauce of Aera’s success. I have to credit Mr. Walker for the guidance and insights about the Aera business transformation, which enabled me to put the two main concepts of EAP 2.0 on the map: Breakthrough and Accountability. (more below)
Finally there is my friend Stuart Scott, with whom I worked on Information Engineering projects in the early 90ies, and who later specialized in BPR projects. Independently from each other we arrived at “accountability” as key ingredient for the secret sauce of success. Projects fail when they are underfunded in the dollar sense, but just as often they fail when not enough political capital is brought to bear on the project. Mr. Scott provided the “key stone” for making the secret sauce, what I now call Seeking Accountability. His techniques enable EAP 2.0 to generate that capital.
Classic EAP and EAP 2.0
The fundamental difference between Classic EAP and EAP 2.0 is that Classic EAP is about defining a solution for a known technology problem and planning the implementation of that solution through a series of well sequenced technology projects, whereas EAP 2.0 is about understanding a business problem, amassing the political capital to transform the business, and ensuring that business transformation projects indeed deliver business benefit.
In EAP 2.0 we shifted our emphasis from assisting the CIO with, “What capability are they missing?” to assisting the CEO with, “How should we be doing this differently?”
Classic EAP
Classic EAP is a culmination of Dr. Spewak’s analysis of failed IT projects. In 1992 he published his seminal work Enterprise Architecture Planning in which he provided a better methodology for planning IT projects. He improved on the budget-based methods of those days in which projects that were independently approved and business-case justified competed to stay above “the cut-off line”. In addition, he identified a more fundamental problem: the complexity of the IT infrastructure. As the existing infrastructure had grown more complex over time, the IT organization was no longer capable of providing quality information to the people who needed it in a timely fashion. As a result, the potential of new technology could no longer be exploited.
Dr. Spewak 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 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 those applications for optimal benefit, and c) schedules their roll-out in a long-term application implementation plan, over a period of five or six years.
It should be noted that the scope of an EAP strategy is massive. In one program, functional area by functional area, application by application, redundant functional applications are consolidated, technology is homogenized across the enterprise, and data can be shared among people who need it. To quote from Salym Petroleum’s internal corporate magazine, “…when business needed additional systems support for a certain function, Aera’s IT department did not build or install another computer system. Instead it removed two or three of the existing ones. In fact, since Aera started EAP in 2000, they had removed 50,000 spreadsheets, 4,000 Access databases and replaced 500 other systems with just a few data capture systems and a single Enterprise Reporting Warehouse…”
In summary, Classic EAP defines technology and automation we don’t have (the gap) and schedules projects to acquire it.
EAP 2.0
EAP 2.0 starts from a different position on the nature of the problem, perhaps best said in the words of Simon Durkin, CEO of Salym Petroleum in Moscow, Russia:
“… in the face of increasing complexity and costs, and decreasing yields, we need to change the way we work. …” If we are to improve our business we need to transform its processes.
Process change then – in contrast to technology acquisition – is what the EAP 2.0 methodology defines and schedules. That is, the meaningful unit of work scheduled in an EAP 2.0 plan is a process modernization or business transformation project. The key outcome of a business transformation project is delivering a predetermined business benefit, and integral to doing this is modifying traditional project controls so that we manage for process outcome -- as opposed to managing for project deliverables.
Of course, we are not the first ones to address process improvement. Toyota has turned relentless focus on driving out process waste into a culture, very well described in Jeffrey Liker’s The Toyota Way, 14 Management Principles. But driving out waste is only part of it; the commitment to discuss process problems and solutions, not just with the process owner but with all those who are affected, is just as much part of their culture. This discussion of the wider context is what we spend significant time on in EAP 2.0 (the 55 minutes of Einstein’s hour) as we build up an extensive body of knowledge concerning the subject process. We’ll call this Process in Context.
In Classic EAP, this body of knowledge is the enterprise architecture. It is a knowledge base of the solution objects in the form of data, applications, and technology. It describes dependencies between the objects of the solution, provides context for the analysis of alternate solutions, and enables project definition and project prioritization. Given a certain benefit, in Classic EAP solutions compete with each other on cost.
In contrast, EAP 2.0 builds the knowledge base of (all) the processes that make up the relevant context of the subject process. It helps understanding Processes in Context better if at first we allow two types of processes. Ultimately though, 5 years from now, we recommend treating processes uniformly.
The first type are Value (or Value Stream) processes. They are the upstream and downstream processes that figure in the subject process’ value stream. They may also include what Michael Porter’s Value Chain labels as support process: Purchasing, HR, IT Delivery, etc …
The second type are “alignment” processes. These processes have to do with the root cause of the subject process’ inefficiency. By seeking answers, five "why"s-deep into a root cause, we observe facts about the history and culture that gave rise to the process' current performance. Except, each such fact is expressed as an outcome of a process. Once we are able to express the "bad" outcome, we can also express the desired outcome, identify the process that produces that and find the process owner. We call them alignment processes, because our position is that the root cause of inefficiency is poor alignment.
EAP 2.0 thus expresses the results of its research as Processes in Context of the subject process. There’s always three questions to ask: what is the desired outcome, what process produces that outcome, who owns that process. To modernize the subject process, most processes in context are going to be affected, and the issue the process owner needs to deal with is whether he has the tools to change the process. The answer is almost always no. This is fundamentally different from answering the question whether we have the tools to acquire/build the technology. The answer to that question is almost always yes.
Examples of context processes,
- If the company is transforming a sales process with a goal of greater market share but the VP of sales, the process owner, is incentivized for increasing profitability instead, -- basically, we want a certain outcome but pay for another --it is clear that the compensation process needs fixing and thus belongs in the context of the sales modernization project. The Compensation process is of the Alignment type.
- If the VP of sales is modernizing the sales process and his bonus depends on increasing sales, but the project manager gets a bonus for on-time delivery of the project, then goals are not aligned, i.e. the project manager is not incentivized for increasing sales. In this case the Project Management Process or the PMO process belong in the context of the sales modernization project.
- If the project requires certain technology or automation delivered better, faster and cheaper than the IT department has been able to so far, then the IT Delivery Process itself may have to be modernized. In this case, the IT Deliver Process belongs in the context of the sales modernization project. The IT Delivery Process is of the Valuetype.
This process context analysis will lay bare any business transformation problems and it is this clear definition of the problem that holds within it the description of the solution. The majority of our effort is thus spent in building this knowledge base, (In full agreement with Einstein “spend fifty-five minutes defining the problem and only five minutes finding the solution.”)
This simultaneous understanding of the problem, in context, and of the solution, in context, is the EAP 2.0 Breakthrough.
How is this done practically?
The first step towards breakthrough insight is developing the enterprise’s Concept of Operations (ConOps). The ConOps is a comprehensive and detailed (50+ pages) vision of how future enterprise processes are conducted and how they interact, with particular emphasis on those processes that either are the biggest constraint to 100% efficiency or hold the greatest opportunity for improvement. The ConOps also estimates a quantitative change, expressed in dollars over time, in outcomes of the envisioned process compared to the current process. That is, constraints and opportunities are translated in hard quantifiable benefits, which later on will figure in prioritizing business transformation projects.
Notice how the Classic EAP “Business Model” is different in content and purpose from the EAP 2.0 “ConOps”. The Business Model describes what “activities” take place now -- remember, in Classic EAP processes are verboten -- and serves to establish consensus on which business activities need automation support. The ConOps expounds the company’s vision and builds consensus on how the business will operate differently in the near future, say five years from now, and thus on processes that need modernizing.
The second step towards Breakthrough is the analysis of the Alignment type processes.
“Projectizing” the Solution. EAP 2.0 adds Benefit Realization tasks to a process transformation project’s work breakdown structure (WBS). In essence, Benefits Realization’s main concern is ensuring that anticipated benefits are indeed realized. To that end, it does three things. - It adds tasks to the project, like define and measure benefits (for a complete task list, read here), so that a clear path towards reaching process outcome is defined. - It modifies project controls to manage for business outcome rather than for project milestones. - It assigns accountability for each of the outcomes. Clarity on accountability and assigning the “correct” accountability avoids instances of “doing someone else’s work”. Benefits Realization seeks to tie the accountability for benefits delivery back to the various owner of the processes in context.
Benefits Realization thus connects the dots between the full understanding of the solution and “projectizing” an implementation of the solution which ensures achieving the desired outcome.
We are not there yet!
Breakthrough is not enough. Having a clear understanding how each of the processes in context need to be modernized themselves AND having a clear agreement on who their process owners are, does not yet guarantee that these same process owners will spend political capital and deliver. Understanding the task at hand does not yet commit the capital to see the project through. And without agreement to spend capital, political or other, the project has little chance of succeeding and should not be started.
Sometimes this hard-to-come-by capital is simply a manager’s time. The time necessary to keep the business going at full speed while at the same time changing the way the they work. Lke changing a flat tire while driving at sixty miles an hour.
We believe that one factor, above all, lies at the root of successful business transformation. In the successes we’ve seen, the people accountable for running the business were also accountable for the transformation. They did not create a separation between doing business and improving how they did business. The person “driving the car” was also in charge of “changing the tire.”
In the Seeking Accountability phase of EAP 2.0 we facilitate the conversations that need to happen to ensure that accountability rests where it belongs. Part of our challenge is that most companies have a seemingly logical division of labor:.Accountability for transformation lies with the PMO and not with the manager who’s accountable for running the business. That is, the business “driver” supposes his job is merely to drive the “car,” and leave the “repair job” to the “transformation mechanics.”
The first visible result of Seeking Accountability is a manager who takes accountability both for the daily operations of a business process and for its continual improvement. The second visible result is a cross-functional transformation team that functions as a collective “we.”
Conclusion
As laid out above, there is a meaningful difference between Classic EAP and EAP 2.0. I have sketched that difference perhaps in terms that were too black and white such that it will lead to a polemic. I hope not. Classic EAP was loved, it is tried and proven, and I enjoyed conducting them. Steve Spewak’s EAP will forever stand alone.
In the end I feel EAP 2.0 is not so much an evolution of Dr. Spewak’s EAP. EAP 2.0 is not an accumulation of evolutionary steps on top of Classic EAP. I think it was I who accumulated small insights that made me make a clear, clarifying, exhilarating 180 degree change. With apologies to Mr. Carville “It’s about the process, stupid”
.
The power of EAP 2.0 lies not in erecting architectures or planning technology acquisitions, but in helping transform business by Achieving Breakthrough with Accountability.
Stephan - I believe you are exactly correct and in tune with the real value of EA. Have you spoken to Gary lately as I think he said something about re starting the EA Institute. EAP 2.0 is in fact what is needed. Its just a shame we don't have Steve here to argue us thru it. Best of luck. Mike T
ReplyDelete