Through a discussion on LinkedIn, I ran across a rather goofy blog post titled (“EA does not matter”), an obvious riff on Nick Carr’s famous HBR article. Unfortunately, while Nick Carr is a well established business and IT contributor, the author of the blog post, Martin Palmgren, seems to have been writing articles for an astounding two weeks before levying a false attack on Enterprise Architecture.
Masked below his obvious contempt for “things he does not understand” is a fatal flaw: he is asking for a result that EA can provide! Mr. Palmgren is clearly of the ITIL mindset: that well defined and delivered IT services can provide a solid mechanism for both governance and alignment. As an Enterprise Architect, I agree. Perhaps Mr. Palmgren thinks that EA is opposed to that idea? I don’t know.
Regardless, he shows a remarkable lack of understanding of what Enterprise Architecture is and does. With EA fully engaged, the business would be able to see the linkage between their business goals and the IT services that Mr. Palmgren obviously desires, and therefore would be free of the need to demonstrate the ROI of infrastructure. (ever tried to prove the ROI of good plumbing systems in a restaurant? IT service providers have the same problem. EA can help).
To Mr. Palmgren and the others who radically misunderstand EA, I encourage you to reach out to actual practitioners to find out what this profession is about before you launch ill-informed attacks. It’s a good way to avoid shooting at your allies.
I was speaking with a software architect, yesterday, after Martin Sykes, Mark West, and myself presented our ideas around Visual Stories to about 150 consultants. He asked me about my role and when I explained that I am an Enterprise Architect, he asked what that is. I got my chance to use my new three word definition of Enterprise Architecture: Reduce Unnecessary Effort.
This is the goal of alignment: to reduce unnecessary effort. We find the things that could be done, and the things that should be done, but also the things that should not be done, and we use that information to influence the governance decisions in the business. When the business “announces” a solution to a problem, we are there to vet that solution to insure that we do LESS unnecessary effort. We may end up doing less work overall, or perhaps not, but a greater fraction of our project portfolio will be necessary (strategic) work.
The difficulty in rolling this out is often the need to change IT governance practices that may be heavily entrenched. As I’ve pointed out in the past, the aims of “demand management” in IT often run counter to the aims of Enterprise Architecture. The goal of demand management is to “take on as much work as possible, doing the most important stuff first.” As long as “alignment” is a factor in prioritizing projects, then there is no problem. Unfortunately, that is rarely the case.
Most of the demand management programs I’ve seen, both in Microsoft and in other companies, are based heavily (or entirely) on ROI (Return on Investment). As I discussed in my last post, ROI often prioritizes poorly aligned programs. If Enterprise Architecture is to have any value at all in an organization, it is to help counteract this effect by prioritizing projects that produce a lower ROI, but do a better job of insuring that the organization meets their strategic goals.
In Microsoft IT, there is a move to use a “balanced scorecard” governance mechanism that can balance strategic alignment as well as ROI in a single formula. As a result, I have renewed hope that our internal governance mechanism will set up the correct priorities. Tremendous credit for this work goes to my esteemed colleagues Munir Bhimani and Gabriel Morgan. Perhaps, with the mechanisms they are setting up, we can finally begin to take the input from the “architects in the trenches” and include their insight in the process of deciding which programs should be funded, their scope, and elements of their solution.
And then, in our large, noisy, headstrong environment, Enterprise Architecture will be better positioned to “Reduce Unnecessary Effort.”
In order to solve a problem, you have to know the problem you are solving. In a growing number of organizations, Enterprise Architecture is responsible for insuring the alignment of business change programs (including but not limited to programs that impact computing systems). But what does a misaligned program look like? How would you know one when you saw it, and what would you do when you do recognize one?
Until you can answer these questions, your EA program may be “a dog chasing a car.” What will you do when you catch it?
Alignment is the condition where your vision, your goals, and your actions are oriented produce the same effect. Alternatively, alignment means that you do what you say you will do. It means you are moving with intent. How do you know if you are aligned? When a company is aligned, the investments that the company is making in the future serve to fulfill their strategies, and the strategies move the company towards their goals, and their goals are likely to help deliver their vision. Alignment means that you stop doing the things that delay the delivery of your strategies. It means you remove focus from actions that distract, and add focus to actions that enhance. It means you cut the funding from things that don’t matter.
Alignment is a personal goal as well as a corporate goal. If you are personally aligned, it means that your vision guides your actions and that you are true to that vision. It means you do the things necessary to bring that vision about, in accordance with your values. Great men and women, whose accomplishments live on in history, are the most aligned people.
Alignment, in the corporate sense, is difficult. It is not possible to be an aligned company if the people in the company do not understand the vision, embrace the goals, support the strategies, and act in a manner that delivers on them. Alignment is end-to-end. It is not a training program with posters extolling the virtues of the company’s core values. It is made up of a thousand business decisions, each independent, made by different people, in which the SUM of the decisions produces the effect of moving the company, its people, and its resources in the direction dictated by the company’s vision. Alignment occurs only when the culture, the values, the executive staff, and the entire workforce support alignment.
Alignment is a distributed idea. It takes an army to change the course of a company. Individual people need to be encouraged and reminded of what the strategies of the company are. The existence of a misaligned program does not indicate bad people or even bad performance. It indicates that a good people came up with a good idea that the company simply should not follow up with, because the company needs the resources to move in a different direction.
First off, alignment is the art of taking “words” and insuring that “actions” actually match them. The motto is “do what you say you will do.” First thing: know what you said. Second thing, do what you said. First say, then do.
Unfortunately, this order is very often reversed. We like the idea of incremental improvement. A team will decide to improve something, create a program that will change processes and systems in order to have that effect, (the “do” part), and then we look at the strategies of the company and we justify the program by associating it to one of the company strategies (the “say” part). That is not how to get alignment.
Let’s be clear about what an aligned program gives us. An aligned program gives us movement in the right direction. Not just any movement. Specific movement. Other movement can exist.
A misaligned program may produce business value. In fact, it might produce immediate, tangible, and important business value. That’s what it might do. Here’s what it will do: A misaligned program will consume resources (people, money, time, bandwidth). There is a limit on the amount of change that an organization can accept in a year.
The challenge of misalignment is that you have to say “no” to valuable programs! On a strict ROI basis, alignment is insane.
For example, let’s look at a strategy and, skipping a few steps for the sake of discussion, two programs that have been suggested.
Situation: Fabrikam is a $200M manufacturing company that makes orthopedic items that doctors offices fit onto patients. The patients arrive in pain, leave with the item and pay the doctor for it. They don’t really go “shopping.” It’s a confined market. Fabrikam has built their business on excellent relationships with doctors offices, selling the medical benefits of their orthopedic devices directly to practitioners. This has been done through a dedicated sales force that negotiates agreements with large hospitals and physician groups. Fabrikam’s web site is primarily used to allow existing customers to replenish their inventory at the prices negotiated in that agreement.
Their competition, Orthomarket, traditionally sends out a catalog to smaller practitioners. They moved to eCommerce about five years ago. Their business model yields a lower margin but reasonable sales. Their products are less expensive and lower quality. They have no complex large-volume purchase agreements. It’s a fairly simple retail operation.
External Influence: Orthomarket has made headway into Fabrikam’s market share through their e-Commerce web site. The competition added features to their site allowing large hospitals to pre-select specific products for their doctors to buy. As a result, Orthomarket has been chipping away at some large accounts and have expanded their reach by creating special purchase relationships. If they are successful, Fabrikam’s sales will suffer.
Strategy: strike back. Go after Orthomarket’s base through an aggressive new, low cost line of products marketed through direct mail advertising and ordered from a new web site. Goal: put the business together this year. Hit 2M in sales by year end. Target 20M in sales in two years, with a ramp to 100M in sales in four years.
You are an Enterprise Architect working for Fabrikam. You see the following two programs come up for funding review. The company will only fund one of them. Which one should they choose?
If you look at ROI alone, you should pick the first on. If you look at alignment, you should pick the second. Yet, in our scenario, if the company does not fund the second of these two programs, then the strategy will fail. Using ROI to decide on funding decisions will produce misalignment.
My prior example was unfair, at best. The choice is not frequently clear cut. What if Fabrikam has two strategies: increase sales from the existing channel while building the new eCommerce channel. Sounds typical. But the devil is in the details.
If there is only enough money to deliver one of those strategies at a time, then the decision is difficult but fairly clear. But what if there is enough money for one initiative to be successful, and the other to limp along? Then what? Which one will be fully funded and which one will limp along? Typical answer: the HiPPo decides! Who is the HiPPo? The Highest Paid Person of course. The most senior person in the room, when a decision is made, will make the decision. That is not a rational method, but it is a typical one.
Back to our example: Who will be the highest paid person: the sales executive whose business unit brings in $200M in sales every year, or the eCommerce guy who (presently) runs a cost-recovery operation? I bet I can guess. Given that approach, which of these two initiatives will limp along? Will the strategy ever be delivered?
Enterprises pay a price for success. Successful programs will bring in revenue. Therefore, in the battle for internal enterprise resources, successful (existing) programs will frequently win over innovative new programs, regardless of their relative strategic importance to the enterprise. One reason is that decisions are often made by the HiPPo, and the Highest Paid Person is nearly always tied to the most successful programs.
Someone has to come down on the side of innovation and business strategy. That is the job for Enterprise Architecture. When resource distribution decisions are made, EA must be there to help insure that the most strategic program is given proper support. Enterprise Architect insures that the company will “do what they say they will do?”
I’ve seen countless attempts to create “traceability” as a mechanism to illustrate alignment. Most of these attempts fail to deliver on the promise of alignment. The most obvious reason: it is easy to create bogus traceability. In other words, it is fairly easy for a person seeking funding for a really good idea to claim that the idea is aligned to a corporate strategy.
Why is it so easy to create bogus traceability? Because alignment is found after a chain of steps: strategy development, prioritization, initiative generation, and then funding. A mistake anywhere along the way can appear as misalignment. Conversely, an intentional bit of misdirection anywhere along the way can mimic alignment. (For example, if a business wants a program to be put into play, then a business leader can create a “subgoal” specifically for the purpose of justifying that program, even if the subgoal is a poor fit to any of the organizational goals above it. Business architects rarely wander up the entire tree.)
To know if a funding request is aligned, use the acronym INStEP: Impactful, Necessary, Sufficient, Explicit, and Prioritized. A funding request should meet all five criteria in order to be considered to be aligned.
On the surface, the principle looks easy: “Don’t fund it unless it is aligned to a strategy.”
In practice, handling a misaligned program is not so simple. There are some key aspects to consider.
One at a time, let’s look at these aspects:
Decision makers have to care about alignment: As I demonstrated above, it is possible for a funding request to have a “high” return on investment, and yet not be aligned to business strategies. In that case, the question is simple: will the fact of poor alignment actually be considered as a criteria for decision making?
Quantifiable alignment score: Alignment is not boolean (True/ False). Alignment is a spectrum. A funding request may be well aligned to one strategy while being partly aligned to another. Another request may only be poorly aligned to any strategy at all. I encourage you to create a formula of some kind that helps your enterprise architects or business analysts come up with a number (between 1 and 100, perhaps) that represents “how far” the funding request goes toward being “very well aligned” to enterprise strategy
Altering funding requests: if there is a way to create a “score” for alignment, then the folks who create these funding requests will quickly learn how to create funding requests that produce high values on that scale. This is the healthy and correct behavior. Encourage it. The net effect will be that the scope of specific funding requests will be modified to order to produce a better number, and, in doing so, we will have produced the intended effect of insuring that funded programs will do the work that Enterprise Architecture wants to see get done.
Limits on budget for misaligned programs: We want to rig the system so that funding requests that are well aligned are going to be more likely to get funding than funding requests that are poorly aligned. This has the healthy effect of producing a focus on alignment when these ideas are hatched. On the other hand, a strategy usually describes a change to the enterprise. In most cases, there are metrics that just as important, but don’t show up in a strategy. Those metrics may have a lot to do with maintaining the status quo or making minor improvements. For example, let’s say that Fabrikam has an excellent reputation with its customers. Survey after survey comes back with a 90% customer satisfaction. It is possible that there is no strategy, this year, for improving customer satisfaction. That doesn’t mean that the business would be happy if customer satisfaction starts to drop.
Demonstrable use of alignment score: This aspect is related to the first aspect above: caring. Do the decision makers care about the effort needed to produce that application score? The proof is in the pudding. After all the dust is settled, and a final list of funded programs can be produced, it would be important to show that the alignment score was actually considered and found useful in negotiating the scope, timing, and level of funding for a particular program.
The following section discusses some ideas for addressing the misalignment problem that I’ve outlined above. There are a couple of steps needed to address misalignment. They are not in specific order, but all have to be done.
Now we get to the core of the issue. We can understand what misalignment is, and how misaligned programs get funded. It is time to discuss mechanisms to address the issue.
The first thing to realize is that misalignment is caused by a lack of clarity. When a business leader creates a business goal, the best advice we give is to be SMART (Specific, Measurable, Achievable, Realistic, and Time-Based). We ask for five things, yet we don’t ask for the most important thing: prioritized! If there is only one business goal, that makes sense, but I’ve NEVER seen a business create a strategy that can be expressed in only one business goal. I’ve never seen an organization (of more than 30 people) with only one business strategy.
In order for alignment to be executed, a model must be created to allow for resources to be allocated to enterprise strategies according to their relative priority. But this is difficult because, especially in very large organizations, there can be an entire “tree” of strategies and goals. To be accurate, it isn’t a tree, but rather a “directed acyclic graph” because each of the lowest level goals can be aligned to many goals at the next higher level. I didn’t draw the alignment links on the diagram, as a result.
There are two approaches to insuring that priority is understood. One is to remove emotion by examining the goals using mathematical models, and the other is to include the leaders directly in the decision making.
I believe that Method 2 (direct involvement) is far superior.
At Microsoft, we put together a project, as an experiment, to gather all of the goals for a single line of business and create that hierarchy. We collected one year’s worth of goals, and then spent 15 months analyzing the list before they could be presented to leadership. By then, the goals were obsolete. Clearly, there were no useful results from that exercise. Why didn’t the idea work? Because we tried to solve a “human” problem with “mathematics.” It’s a bit like writing an algorithm to decide who you should marry. Lesson learned: comprehensive goal mapping can be too slow of a process to be useful.
In the section above, I discussed “how priority is created.” In this section, I will discuss “who makes the decision.”
In the war to combat HiPPo, there are a couple of different approaches that an enterprise can use, each with their own advantages and disadvantages. (In the list below, I’ve included a few high level alternatives. If, dear reader, you’d like me to include more options, send that option to me, along with perceived pros and cons, and I’ll update this table.)
Which accountability mechanism SHOULD you use? The jury is out. Each is good and bad.
I’ve seen both mechanism 1 (strategy owners) and mechanism 2 (single executive) at play. My current employer, Microsoft, has a strong preference for the second mechanism, with the “senior executive” being nowhere near senior enough to produce anything other than a silo in processes, information, and systems. In some cases, we use Mechanism 3 (committee of executives) but the resulting funding processes are non-agile.
Mechanism 4 (empowered team) is fact-based and thorough, but also risky and potentially bureaucratic. I’ve only heard rumors of it being attempted. If you have first hand knowledge of this mechanism, any other ones I didn’t mention, please let me know.
Leadership is a challenge in any organization. It is not easy to get a wide array of different people to come together to achieve a goal. Books, seminars, training classes, and mentorships all focus on the issues surrounding leadership: recognizing, becoming, and encouraging leadership.
One key facet to leadership is that the people cannot follow a leader whom they do not trust. Yet, in corporate America (and I imagine in other parts of the world as well), companies frequently suffer from managers who make decisions and then simply assume that everyone below them will buy in “because they say so.” That is not leadership. That is dictatorship.
To build a trusting relationship is important, and each enterprise will address this issue in different ways, depending on their own culture. Most will include some or all of the elements illustrated by Stephen M. R. Covey in his book “The Speed of Trust” (see this excellent article). Taking this advice to heart, in an organization, means building trust into the decision making process itself.
Specifically, I would encourage organizations to focus on Honesty, Transparency, and Continuous Improvement in their decision making process. These elements are key to building a process that allows decisions to be made, especially difficult decisions, in a way that encourages every stakeholder to execute on them.
Honesty – The funding process cannot make decisions without honest information applied in a fair and balanced way. If the process requires that every project declare the goals that it supports, it is not honest to indicate a goal when the project will not actually deliver value in that way. It is not honest to indicate a greater return on investment than would likely occur. And it is not honest to indicate that value will be achieved more quickly than reality. For example: if a project is designed to address some problem in determining sales force commissions, it is not honest to tie that project to a goal of “increasing sales.” It is important to address that problem, but addressing the problem doesn’t increase sales… it lets you pay them fairly. Different problem.
Transparency – The funding process cannot make decisions in secret. To be effective, alignment decisions will not always be easy. Sometimes, good efforts must be halted, and sometimes good systems must be retired. To people who see the value in an effort, the decision to halt it is counter-intuitive and suspect. Team members will ask, “What were they thinking?” It is absurd to expect that employees are not aware of company politics, and it is absurd to expect them to feel comfortable with counterintuitive decisions if they believe that politics may have played a role in making those decisions. If you want a decision to be made, and then followed, it must be made in a transparent and fair manner. Honest concerns must be given the opportunity to be aired, and fair representation and judging must be applied. This is an important part of building trust, and when employees trust the decision process, they are far more likely to follow the results.
Continuous Improvement – The people involved in decision making are people. They make decisions that won’t always be correct. In order to build trust, you have to be willing to listen to people who tell you what went wrong, and then act to right the wrongs. The process has to flex in a visible manner to address issues that have been raised and are widely held. All processes, when created, are immature. Only through self-improvement can those processes become mature. Once a process is mature, it is difficult to find a flaw. Mature processes build confidence and trust.
Every decision creates winners and losers. One of the goals of alignment is to make sure that “explicitly prioritized business strategies” are the winners in those decisions. Of course, there are folks who don’t like to lose, even if their loss is the company’s gain. To win these people over, apply logic to real data. Don’t just assume that everyone will “just trust” you. Collect data and present it.
Data collection, in support of difficult decision making, is our fourth area of focus. When making decisions, you frequently have to collect information from other parts of the company, from the marketplace, from partners, and even from competitors. That requires impartial and trustworthy people who are responsible for collecting that data, using a simple, open, clear, and repeatable mechanism.
I’ll list two examples of data collection, but I can think of many more.
In these examples, your enterprise has two (or more) IT groups. Both need to send e-mail to customers (one for marketing purposes, and the other for transaction and incident support purposes):
I’ve seen many situations where the collection of data is simply left up to an engineer or program manager. This is ad-hoc and sloppy. In order to address misalignment, there has to be a managed mechanism for people to store and retrieve information about their systems, as well as a person or team of people accountable for collecting information in a consistent, rapid, and trustworthy manner.
It is difficult to base decisions on data, if the data cannot be trusted to be accurate and complete.
“Fool me once, shame on you. Fool me twice, shame on me.”
It should be abundantly clear by now that alignment is going to require difficult decisions. If your budget is shrinking while new strategies have to be funded, an existing program (or even a line of business) may need to be closed down. That takes time and money. Feelings can be hurt. There can be a great deal of stress involved.
Let’s say that I’m a stakeholder who ends up on the “losing” side of a governance decision. I’ve heard the reasons for the tough decision, and while I may agree to do what is necessary for the good of the enterprise, I may not be happy about it. In fact, I probably won’t be happy about it. I may view alignment as “outside meddling” or worse.
As an Enterprise Architect, you have to care about all of the stakeholders, especially the burned ones. If you are to look at the list of stakeholders, and follow good old-fashioned stakeholder management principles, you will track whether your stakeholders have sufficient understanding, commitment, and support. However, a stakeholder who ends up on the “losing” side of one alignment decision may become an opponent to alignment altogether unless you give him or her a reason not to regret their previous support.
That is where demonstrable results come to play. It is difficult to get alignment on a single area of the business. It is nearly impossible to get alignment across the breadth of a large and complex enterprise unless you can tout demonstrable results. Each time you discuss alignment decisions, especially with the next stakeholder who may end up on the losing side, it is immeasurably helpful to cite a case study, from within your own organization, that illustrates how alignment provided benefits in the past.
This is critical. Your alignment program can get started without stakeholder management, but it will not sustain unless you can collect “Stories of Value” that are meaningful to both past and future stakeholders. The stories have to be consistently collected, clearly described, and measurably accurate. They have to be kept up to date. You are only as good as your last success, and if your last success story is three years old, future stakeholders will start to doubt your ability to deliver.
Alignment is one of the key accountabilities of Enterprise Architecture. To be able to deliver on the promise of alignment, it is imperative to understand what misalignment is, what to do when you find it, and what improvements to make in your EA program in order to be able to drive out misaligned program requests in an open, trustworthy, and repeatable fashion.