Chapter 9
The Next Steps
Taking Collaborative EA Forward
Content
A summary
In the wake of the rise of IT in our globalized business world, enterprise architecture has reached the mainstream. There is hardly any large company in the world that does not have an EA team, whatever it is called in the respective organization. The primary task of EA is to align the IT landscape to the business needs while at the same time keeping its ever-growing complexity under control. The enterprise architect is like the driver of a cart drawn by a wild horse: She needs to keep the cart on track and tame the horse at the same time.
This can be a Herculean assignment at times. In Chapter 3, we categorized the manifold tasks of an enterprise architect into eight main activities. They range from contributing to the high-level IT strategy over designing the large-scale IT landscapes down to supervising the concrete implementation projects. In addition, the EA organization is responsible for defining the “how-to” of IT implementation and architecture by providing guidelines and standards.
There is no doubt that EA is a useful, even necessary, function in today’s enterprise. Yet in many organizations its impact is not living up to the sustainable and sweeping effect that it promises. Our caricatures way back in Chapter 1 outlined to what extremes EA can deteriorate in practice. As matters stand, EA is too often not realizing the full potential of its core concept.
Why is that so? EA is still a maturing discipline. In some areas its development has come a long way already if you consider, for instance, the rich offering of formal EA frameworks and maturity models that we described in Chapters 4 and 5. But the spirit of EA, as practiced today, is often still marked by a top-down, elitist approach that was characteristic of the IT management style of the 1960s to 1980s. In EA frameworks and literature, enterprise architects ever so slightly resemble a group of enlightened high priests. They receive their wisdom from above in the shape of the strategic maxims decided by the board. Then they hand it down, neatly packaged, to the common IT folks on the ground.
This is not always true, of course. And not that this approach is entirely wrong; it just ignores two major trends that have made the IT industry and user community a more effective and creative place. We have summed them up under the label Collaborative:
• Lean and agile development methods have made IT projects more flexible, given more responsibility to individuals, and made processes more lightweight.
• Web 2.0 and Enterprise 2.0 participation concepts have given more influence to IT users, boosted the creation of a true IT ecosystem, and added the wisdom of the many to the findings of the few.
The two concepts have not replaced the traditional way of doing things. Waterfall projects, release dates, and milestones are still in use, and editorially managed content without user participation still has its place. Sometimes the new style and the traditional style compete, sometimes they exist side by side. In any case, lean, agile, and participation concepts have proven to be an enrichment for IT and software development. They have rendered this area more flexible and effective. Why not try that for EA, too?
In this book, we have applied lean, agile, and participation concepts to EA and called it collaborative EA. These ideas refresh EA in much the same way they did for IT and software development in general. Our guidelines for collaborative EA sum up how this works in practice:
• Establish a lean set of processes and rules instead of overloading the stakeholders with bureaucratic processes and unsolicited artifacts.
• Adopt evolutionary problem solving instead of blueprinting the whole future rigidly on a drawing board.
• Foster and moderate open participation instead of relying only on experts and top-down wisdom.
Each EA organization can profit from collaborative EA. In Chapter 6, we outlined the nature of complexity that an EA group faces within the enterprise. Based on findings from management theory and cybernetics, we have drawn conclusions about what strategy is most effective in dealing with it. In essence, it boils down to accepting the limits of management in these kinds of ultra-complex systems. Management on a detail level is bound to fail. Instead it is better to steer by simple but clear rules and strengthen the organization’s ability to change by introducing flexible process frameworks.
As a consequence, we introduced the term edge of chaos, with the underlying finding that a system works in the most effective way when kept in the narrow ridge between too much and too little structure. The EA Dashboard, introduced in Chapter 6, takes up the concept and visualizes it by four gauges. You can use this tool to assess the state of your own EA as well as taking it as a yardstick to gauge the effectiveness of changes to the EA processes.
We have enhanced the edge-of-chaos idea with the notion of the edge of time to assess the pacing of change processes. In all, there are four dimensions: Perspective, Governance, Strategy, and Transformation. In each of these dimensions, an effective EA should aim at a good balance. It is at its optimal point (the edge of chaos and time) when it is poised between anarchy and overstructuring, short-sightedness and tunnel vision, standstill and revolution.
Lean, agile, and participation concepts provide tools that can help achieve this balance. In Chapters 7 and 8 we outlined a set of six building blocks that transfer these ideas to the EA domain. Table 9-1 sums them up again.
Table 9-1 The Six Building Blocks of Collaborative EA
In mapping out the impact of each building block on EA effectiveness, you get a summarized EA Dashboard, as shown in Figure 9-1. This tool allows you to focus on those building blocks that specifically tackle the issues you found in your own organization.
Figure 9-1 EA Dashboard summary of the potential impacts of our six building blocks.
In addition, Table 9-2 sums up which building block has a potential effect on which of the main EA activities, EA-1 to EA-8, that we outlined in Chapter 3.
Table 9-2 Mapping Activities EA-1 to EA-8 to the Six Building Blocks of Collaborative EA
You can judge for yourself what building blocks might fit your particular way of practicing EA. Figure 9-1 and Table 9-2 can help in this assessment. You are invited to treat collaborative EA as a toolbox. You can select and pick from it what you find useful in your daily work.
Getting started with collaborative EA
I don’t know what I’ll be working on. I expect it’ll be a bit of everything, seasoned with a large dose of grumpy curmudgeon.
—James Gosling1
Let’s assume that we convinced you to take up some ideas from this book in your own architecture practice. If we did, you will have to change something. (If everything is brilliant already and there is no need for change, why did you read this book?) You might have to influence the attitude of business and IT management toward EA. You might want to correct the positioning of the enterprise architects within your organization. And almost certainly you will have to change something in the way you, yourself, and your stakeholders, peers, and managers, work and collaborate.
No one ever implements change by simply giving an order. Not even the CEO or the CIO can do that. Backing from the authorities is a necessary but not sufficient precondition for change. You need to win over the people who have to adhere to a different process in the future. In other words, you need to start thinking about change management.
Change management, as meant in this section, is a systematic approach to bringing persons, organizations, and processes from the current to a targeted future state.2 In our case, the current state is the traditional way of running the EA practice, and the target state is collaborative EA. We would like to provide some cues as to how you can use concepts and tools from change management in your own journey toward collaborative EA. Take this section as a first rough set of directions. From here onward, you must draw your own map.
Interpreting the organizational attitude toward change
Chip and Dan Heath, in their highly recommendable book Switch: How to Change Things When Change Is Hard (2010), sum up three surprising insights about people’s attitude toward change.3 We will use them as a guiding theme in this section. They are not meant to be generally applicable theorems about human behavior; rather, they are fresh, unconventional ways to look at human behavior in the face of organizational transformation.
Insight #1: What looks like a people problem is often a situation problem.
“People” factors (personality, culture, and so forth) and situational constraints both influence human behavior. Their respective impact is as difficult to tell apart as, for instance, the influence of genes and upbringing on character development.
However, a key learning from numerous experiments in behavioral psychology is that we tend to overestimate the influence of personality on other people’s behavior and we underestimate situational factors. This phenomenon is called fundamental attribution error, a term coined by Lee Ross (1977). We intuitively tend to file someone’s negative attitude as hostile or rude—and leave it at that instead of reflecting on what situational factors may have contributed to it.
This does not mean that there is no such thing as a people problem. It only means that if you want to implement change and meet resistance, there might be hope. People may react reluctantly not because they hate you, despise your ideas, or are in general a bunch of stubborn imbeciles. If you manage to change the circumstances for launching your ideas, people might be more open to them.
When you speak to a group and feel resistance, it might indeed be that some members of the group do not understand what you expect from them—however clear the message might sound to yourself. Interpreting this lack of clarity as a sign of resistance would be, again, a symptom of fundamental attribution error. It is better to give people the benefit of the doubt if you cannot tell confusion and resistance apart. This brings us to the second insight:
Insight #2: What looks like resistance is often lack of clarity.
Probably all of us would subscribe to the opposite wording of this statement: “What looks like lack of clarity is often resistance.” Indeed, claiming not to understand a speaker’s message is a well-proven path of resistance. But this is not the point of this insight.
Maybe you have tried to convey this clarity already many times, in earlier situations, but to no avail. Perhaps you lack the authority to give direct orders to people—or, if you do have that authority, people still find ways to dodge your requests. Well, it might be that you simply did not use the right means to motivate people. This brings us to insight number three.
Insight #3: What looks like laziness is often exhaustion.
We probably all know this: Even if everyone agrees that your ideas make sense, change still might not happen. You can talk until you are blue in the face, but people pay only lip service to change; instead, they quickly abandon the new approach and return to the old habits. In moments of gloom, it seems to you that most people are just too lazy to really care. A colleague of ours, an IT consultant who often works for in-house IT departments, told us:
You often meet people whose brain fell asleep some years ago. They don’t want to change, and they have “oh so many things to do.” But they are just lazy. Or exhausted. Or both. Who can tell? Who cares?
Yet there is a difference between laziness and exhaustion. Both hinder change, but they require a different approach from you as a person trying to instigate change. In brief: Ignore the lazy ones (for the time being) and focus on the exhausted ones. If you cannot tell who is what, assume that people are exhausted, not lazy.
The truth is that change is tiring. It requires a lot of self-control to do things differently. Just think of the last time you tried to cut down on coffee, went on a diet, or resolved on more frequent visits to the gym. Habits are the well-trodden paths of life, broad and easy to walk on; new ways have to be cut out of the jungle with a mental machete. So, people are not lazy by nature; often they are simply worn out.
The elephant and rider metaphor
Jonathan Haidt (2006) has coined the elephant and rider metaphor for the human mind. It has been taken up by many other authors on change management. According to Haidt, the emotional, habitual side of a person is like an elephant, and the rational, willful side is its rider.4 The rider plots the path ahead and tries to make the elephant walk it. The elephant, however, is a strong and stubborn animal. It does not like unfamiliar situations, it hates being bossed around, and it needs an immediate reward to get going. The rider is our self-control, trying to steer an animal 20 times heavier and stronger than himself. No wonder the rider is exhausted at times.
So, to commit the whole person to change—the odd pairing of rider and elephant—it is necessary to address the elephant, too. In other words, if you appeal only to the intellect in your plea for change, you are only appealing to the rider and hence are bound to fail. One long and comprehensive PowerPoint presentation listing all the benefits of your ideas will get people nodding, but it is their riders who do the nodding. You need to make people feel the need for change. You have to motivate the elephant, too. We will explore in the next section how you can do that.
But of course we do need to address the rider, the rational and planning minds of our audience. More specifically, helping the rider steer the elephant is essential in implementing change. It is not only the elephant that has problems with unfamiliar situations (which change brings by definition). The rider is in acute danger of losing overview. Our rational side is used to analyze situations, draw conclusions, and implement them. In circumstances not encountered before, there is not enough data to do that.
When you propose a new process to your team members or stakeholders, your own rider perhaps has a vision of the path ahead, because you have thought about it for months. The riders—the people you address—lack that clarity. For them, the situation is unfamiliar and new. They are prone to fall into analysis paralysis. This is why you have to direct the rider, and give him crystal-clear instructions where to go. We will discuss means to do that, too.
The whole change process can be condensed into three simple maxims5 that Chip and Dan Heath have compiled, based on a lot of psychological research. We will use their framework as a blueprint for the implementation of collaborative EA in your organization.
1. Motivate the elephant. You need to address the emotions, imagination, and creativity of your colleagues or employees, not only their rational minds. It is vital to create identification with your ideas; people should accept them as something they feel is necessary. In that way, you have to overcome the elephant’s despondence by shrinking the size of the change.
2. Direct the rider. Draw a mental map for the rider and spell out crystal-clear instructions. In addition, you should provide a long-term vision as a beacon for the rider to follow.
3. Shape the path. It is not enough to simply throw your ideas on the ground and assume that they will bear fruit. You need to transform them into habits for people. On that path, make sure to build political alliances.
We will now analyze each of these steps in detail and make proposals as to how to cover the particular aspect on the path to collaborative EA.
Motivate the elephant
Are you one of the people in your organization who have some influence on decision making but no (or little) direct authority? If you are a project manager, software architect, middle-level manager, or subject-matter expert, you will probably find the following situation familiar.
You have analyzed a certain issue—technical, architectural, procedural, or organizational— in depth and you are deeply convinced that things are not the way they should be. You even have an idea how it could be done better. Many of your peers with whom you discussed the matter agree with you. You have made several proposals about the issue to the powers that be. And what has happened as a result? Nothing.
Yet in some cases, all of a sudden something does happen. Perhaps the issue has caught top-level management’s attention and the whole organization springs into action. Or for whatever reason, people start behaving differently and things are changing—not necessarily in the way you envisioned, and not always for the better. You feel a little bypassed, maybe even left open to ridicule.
What we see here is a classical misconception by people with an analytical mindset. You would assume that a decision-making process works in the sequence Analyze, Think, Change. You provide a thorough analysis, the management thinks about it, and change is triggered. Indeed, this is the kind of rational reasoning incorporated in numerous engineering disciplines and process frameworks.
The catch is, as Kotter and Cohen (2002) point out, things do not work exactly that way. Change processes follow the pattern See, Feel, Change. The issue needs to raise people’s attention (see). If they develop a sense of urgency and importance about the topic (feel), they are likely to trigger action (change).
If you follow the Analyze, Think, Change pattern, you will appeal to the rider only by rational arguments. But if you neglect the elephant, the rider alone will not move anywhere. You will earn many understanding and sympathetic nods with your analytic research, but these are not sufficient to get people moving. You need to make them feel the need for change.
Kotter and Cohen recount one impressive example of appealing to the elephant.6 Jon Stegner worked for a large manufacturing company. He had the notion that procurement processes were suboptimal since every plant handled its own purchasing. To prove this, he selected a single work item—protective gloves for the workers—and compiled a detailed list how many different gloves his company bought and for what price. He ended up with the incredible number of 424 kinds of gloves, with pricing ranging between $5 and $17 for the same glove type in two plants.
When presenting his research to the decision makers and asking for a change in the purchasing procedures, Stegner could simply have created and shown an Excel sheet. The numbers were indeed impressive enough. However, the independence of the business lines was deeply ingrained in the organizational structure. Stegner was asking for deep shift in the organization’s mindset. The risk of the plain Excel method was that the managers would simply think, “Well, gloves … who cares?”
Instead Stegner chose a different approach. He asked an intern to purchase one pair of each of the 424 gloves, put a price tag on it, and pile the gloves on the conference room table before calling in the managers. The managers, seeing a huge heap of gloves instead of the usual strategy proposals on the shiny table, were taken aback. Stegner led them around and showed them the vastly different price tags on the same kinds of gloves. The managers were stunned. Stegner immediately received the mandate for change that he had hoped for.
Convincing people of a need for change in EA
What can be your pile of gloves? When you organize a workshop with enterprise architects, IT people, and business stakeholders, you could replicate the previous example. You could print out all the specifications that were written during the past year and pile them up on the conference table. Maybe you can stack those specifications that actually ended up in running software systems into a second pile and compare the sizes of the two piles.
You can also use tools from this book to have the people feel the need for change. For instance, create cardboard badges with large icons of the eight EA caricatures from Chapter 1 printed on them. Each workshop participant can pick a badge and wear it, denoting which particular floor of the madhouse he or she inhabits. This might help the participants identify with the need for change; at the very least, it creates a good visual impression of the majority opinion in the room.
In a similar fashion, you could create a cardboard edition of the EA Dashboard from Chapter 6 with moveable scales. Each workshop participant can come to the front of the room, adjust the scales according to his or her own judgment, and give reasons for that choice.
The EA value stream analysis tools, described in Building Block 1 in Chapter 7, also provide a good impression of ineffectiveness and waste within the EA processes. Especially the EA waste matrix (see Table 7-10) and the process activity map (see Figure 7-2) are a powerful visualization of the damage done to an organization by suboptimal processes.
Another way of stimulating the readiness for change is the creation of empathy. If you have the impression that your EA organization matches the Living in Cloud Cuckoo Land or the Guardians of Wisdom caricature, invite the EA team and management to an experience-sharing session with people from selected IT projects. This can take the form of a joint “lessons learned” workshop. You can also use the participation concepts from Building Block 6: Participation in transformation in Chapter 8. If you do not have any Enterprise 2.0 tools available, you can at least emulate the concepts as a preparation for this workshop—for instance, by conducting an online survey.7
Lower the bar: Create an entry level
Let’s assume that you gained a mandate for your mission from management and an initial buy-in from peers and stakeholders. Next you need to create an appropriate first step—an entry level to collaborative EA.
Changing existing habits is like embarking on a journey into uncharted land. This confuses the rider and scares the elephant. The elephant does not care about long-term visions; it needs immediate rewards for each little step it takes. Therefore, opposed to the old management cliché of “raising the bar,” you need to lower the bar for the elephant. It must be capable of stepping over the bar without much ado; otherwise it will shy at the challenge.
The entry level to collaborative EA needs to be an achievable goal in order to satisfy the elephant. “You want to select small wins that have two traits: (1) They’re meaningful. (2) They’re in immediate reach,” write Heath and Heath (p. 145). “And if you can’t achieve both traits, choose the latter!” With such a quick win identified, you have a good chance that the ponderous machinery of change can start rolling. Success creates hope, and hope fuels progress.
A good tool for identifying that small win is the so-called miracle question (Shazer, Dolan, and Korman, 2007). It is a question-and-answer technique usually used in therapy to find starting points for long and hard personal transformations, such as fighting a drinking problem or saving a failing marriage. The starting point is the assumption that a miracle has happened and the problem has disappeared overnight. How would we notice? What is the first thing that is different in the morning, now that our problem has gone? The first indicator that comes to mind is often a pointer to a possible small win.
If you have a small group of people in a workshop or you are in a one-on-one situation with a member of the EA team, you can try a dialogue like the following8:
Q: Please let me ask a very weird-sounding question. Let’s assume one night a miracle happens and all the problems we have identified in your EA processes have gone overnight. Now you come to work in the morning. What would be the very first, small sign that something has changed and all problems have gone?
A: Well, I don’t know. Suddenly things would move in a smoother way.
Q: How would you notice?
A: Well, I would have time to work on my project.
Q: What would make you think that?
A: Let me think … No interruptions all morning. No emails about emergencies and board-level escalations that came up overnight and need to be tackled first. Things like that. If that would go on all day, I’d know something is different … And if then the business sponsor of my project would return my call within the hour, I would indeed start believing in miracles.
The miracle question gets people emotionally involved and commits them to the change process. It may not be an all-encompassing analytical tool, but it helps identifying the true pain points—in our example case they are permanent interruptions and reprioritization of tasks and some disconnect with the enterprise architect’s business counterpart. Having a list of these concrete hints will help us select the first concrete change measures.
Direct the rider
In the rider-and-elephant metaphor, the rider’s task is to guide the way (as shown in Figure 9.2). We have seen above, in Insight 2, that what appears to be resistance is often lack of clarity. This means you have to guide the rider to enable him to guide the elephant. The rider needs a set of crystal-clear directions; otherwise he will lose overview, sink into analysis paralysis, and surrender to a hesitant and grumbling elephant.
Figure 9-2 “Guide the rider and motivate the elephant.”10
Find the bright spots
The first step in guiding the rider is to find the bright spots. This means identifying those areas where the EA organization works really well. This may sound like a paradox; is this whole section not about identifying weaknesses and obtaining buy-in for tackling them? Surprisingly, looking at positive (counter-) examples actually helps us understand why something in general does not work well. Why is that so?
We have a natural tendency to focus on the negative side of things. However, in analyzing the root cause of people resisting rules and processes, focusing too much on “why not?” often leads you into the dead end of the aforementioned fundamental attribution error. Frequently, you hear statements like “People are just lazy” or “People do not have enough discipline.” By looking at the positive counter-examples, you are more likely to identify the situational constraints that make it hard for others to change.
Let’s assume that the activity area EA-5: Developing and Enforcing Standards and Guidelines has been identified as generally problematic. Are there standards that are considered reasonable by both IT and business and that are followed without discussions or many exceptions? If so, what was done differently in creating and enforcing these standards?
As a side effect, starting from positive examples promotes identification with your chosen approach. It supports the impression that your approach is built on something people have achieved themselves (before you showed up with your new ideas). If you play this well the perception is that the new practices actually came from within the team or the organization, and you simply help bring them out.
That way, you also avoid the Not Invented Here trap, with its deep-rooted resistance to solutions from outside. For that matter, it might help to downplay the term agile in the collaborative EA definition, if your organization is rather conservative; the iterations and sprint demos can be dubbed iterative milestones and regular revisions, or whatever fits the organization’s terminology. It lowers the risk that the agile concepts are perceived as some fancy outsider concept “that will never work around here.”
Set a collaborative EA vision
Appropriate directions for the rider include a collaborative EA vision—a guiding light, a beacon for the rider. It is a focus point in the (not too distant) future and helps the rider obtain his bearings when he is disoriented. The process to define the vision is essentially the “management by maxim” technique described by Broadbent and Weill (1997), which we introduced at length in the discussion of EA-1 in Chapter 3.
The collaborative EA vision for your organization needs to be aligned with the IT maxims as described in EA-1. You can use the waste analysis techniques from Chapter 7 and the recommendations from this chapter to identify the weak points, then formulate the vision describing a target state. As an inspiration for wording your visions, consider the building block statements in this book.
Collaborative EA Vision
Black-and-White Goals
The most extreme form of a vision is the black-and-white goal. It can be an effective tool for overcoming strong resistance and breaking die-hard habits. A black-and-white goal does not leave room for any kind of interpretation, nor does it allow any rationalization as to why “just this time” we could not follow it. For example, the SOA directive that Jeff Bezos gave out for Amazon, backed by the “Anyone who doesn’t do this will be fired” sideline (see Chapter 3, activity EA-5), is an example of a black-and-white goal.9
A vision of that kind is a double-edged sword. If not properly analyzed or not fiercely implemented, it entails the risk of being ridiculed. Or if enforced in an overly strict manner, it could destroy proactive, creative, and risk-taking behavior. It is an extreme tool that is good to employ in extreme circumstances—for instance, in the case of a very strong resistance to really important change. Still, one should not actually attempt to achieve a 100% implementation. The main goal is to eliminate the cases where people act against better judgment just because “they always did it that way.”
So, let’s assume that, instead of a collaborative EA vision that is just a paraphrasing of Let’s All Be Nice to Each Other, a vision like No Failed EA Initiatives or (even more unthinkable) No Failed IT Projects is chosen. It can be considered a success if projects and initiatives will no longer be pushed through against the better judgment of the ground workers. It will actually force management to take workers’ concerns seriously. The knowledge about project risks often remains unspoken—for instance, when everyone but the decision makers knows that the schedules are overambitious, the technology platforms immature, and the implementation partner incapable of delivering. With such a black-and-white vision in place, no one dares to start an initiative many people are warning against.
Specify concrete directives
Besides vision, you need a set of easy-to-remember and easy-to-follow directives. Again, you can use the maxim technique described in EA-1 in Chapter 3. The directives help plot the next step on the road for the rider. The directives need to be very clear instructions—for instance, in the form of a checklist. Here are some examples (in this case, from Building Block 2):
• Always form an architecture scrum when you as an enterprise architect supervise a large program with multiple project architects.
• If you work on a larger EA initiative, form a scrum team, report your work in a daily standup round, and plan for regular result demos every three weeks.
Again, remember Insight 2: The clearer your instructions, the less room for interpretation they leave, the more you can hope that they will be followed. And note that clearer does not mean more elaborate; collaborative EA is set to reduce bureaucracy in EA, not to add to it.
Shape the path
Any transformation is a journey over a bumpy road. You should plan for a good start and provide a strong vision for the destination. But planning all the steps in between does not help much; too many unforeseeable events can happen. As Heath and Heath put it (p. 144f.):
Any important change is not going to feel like a steady, inevitable march toward victory. […] More typically, you take one step forward and 1.3 steps back and 2.7 forward and then 6 steps to the side, and at that moment, a new CEO will come and declare a new destination.
The crucial issue is to keep going in the difficult middle part. Figure 9-311 sums up the typical development of the mood in any complex undertaking. Let’s assume that you managed to motivate your coworkers’ elephants well; that means that you have started off in hope-fueled good spirit. What follows is a long slump, where insight takes the better of your illusions. The team doubts its capability to implement the change. This may end in a long death march toward failure. But if you are successful, the initiative will end on a positive note with a strong feeling of confidence in the chosen approach.
Figure 9-3 Project mood chart.
Note that this is a statement about mood and confidence in the ability to deliver, not about risks. Normally, you run out of time toward the end in any initiative, which puts the delivery result at risk. But in a successful project you manage this challenge because your confidence in your own capability has grown again.
Once you’re started, you need to deal with skepticism and doubt in the middle part—of those you want to lead to change as well as your own. You, as an enterprise architect, also do not know the exact path, but you will act as the pathfinder. For that matter, you need to continue looking out for a series of quick and small wins, as described in the “Motivate the elephant” section.
Build alliances
It is of equal importance to build and maintain alliances. Broadbent and Kitzis (2005) recommend classifying your surrounding key players into strong and weak supporters as well as strong and weak opponents.12 They recommend the following priorities when dealing with alliances:
1. Convert influential opponents to the cause. Strong opponents are the most likely people to hinder you as you try to reach your change targets. Focus on their arguments and pain points as you look for small wins. If they can gain by using your approach, you have a chance to win them over.
2. Restrict influential opponents you can’t convert. If your efforts to convert your strong opponents fail, you need to restrict their influence. It is advisable to use governance mechanisms of your IT organizations (boards and councils) to distribute opinion formation onto many shoulders.
3. Retain your influential supporters. The best way to keep your supporters motivated regarding your cause is to deal with them directly rather than through the typical group situations offered by meetings or decision boards. Asking for suggestions and regular feedback is a good way to retain bonding and to hear about complaints early on. The regular stakeholder interaction induced by architecture scrums is a natural step in this direction (see the description of Building Block 2 in Chapter 7).
4. Recognize your weak supporters. You should keep track of those stakeholders who sympathize with your approach so that you can use their group influence in decision making and budgeting.
5. Keep track of your weak opponents. Just make sure the weak opponents do not turn into strong ones.
Build habits
In the long run, the best way to ensure that processes are followed is to build habits. Many psychological experiments have shown that humans have a strong tendency to watch their peers out of the corner of their eyes in unfamiliar situations. When you observe the majority around you acting in a certain fashion, you will likely act the same way.
The agile techniques, as described in our Building Blocks 2 and 3 in Chapter 7, are great for creating habits. They are repeated in a strict clock cycle. Each cycle follows the same sequence of kickoff and planning at the beginning, with results demonstrated at the end of an iteration.
Looking ahead
The need for enterprise architecture management will grow because the complexity of IT is growing and because business success in more and more verticals is depending on IT. Good enterprise architecture management will evolve from a basic tool for managing the complexity of an IT landscape to a strategic instrument used to create new business opportunities from technology advancements.
There is a broad range of methods and frameworks for the practicalities of EA in place. It also is widely acknowledged that EA cannot successfully be implemented without top management commitment. But we believe that the core success factor is collaboration—not only with top managers and business sponsors but also with software developers, operational staff, and users; in other words, with those who are directly exposed to IT.
Collaboration basically means making use of the diversity of knowledge and opinions in an organization and responding to changes that are brought in by stakeholders—not because they are evil-minded destroyers of road maps but because they have some concern.
In this book, we have suggested methods and tools for putting collaboration into practice. Some of them are well known and have been proven in several contexts. Others are rather innovative and still need to undergo a practical test. They all are assembled in a toolbox, and you may pick from it what you need. It is still up to you to combine them into a recipe for your own enterprise. If you want to share your experience in finding such a recipe, you can provide feedback on our book at the following Website: www.collaborative-ea.org.
Your enterprise needs EA, and EA needs more collaboration. We wish you good luck in the journey ahead.
10 The picture shows how one of the authors, Uwe, applies this section’s motto in practice. It was taken during a writing workshop for our book in Goa, India, in November 2011.
1 James Gosling (known as the father of the Java programming language), on his reasons to start working for Google. Retrieved on February 13, 2012, from his blog entry http://nighthacks.com/roller/jag/entry/next_step_on_the_road, dated March 28, 2011.
2 EA and its surrounding areas are riddled with different interpretations of the term change management. To name only a few: Managing change as part of a business transformation program is change management. The handling of scope changes in project management is also called change management. The same term is used in ITIL as part of changing the operational infrastructure that belongs to the service transition phase. There are probably more meanings to it. Just to avoid confusion: None of these interpretations are meant here.
3 Heath and Heath (2010); quoted from pages 3, 15, and 12, respectively.
4 The elephant-rider metaphor should be taken for what it is: an image of human nature, narrowed down to its attitude toward change. It is not adequate (and not intended) as a comprehensive model of our conscious and subconscious minds.
5 Heath and Heath cover these steps in a different order. However, the steps are not sequential; they rather represent different aspects that all have to be taken care of.
6 See Kotter and Cohen (2002, p. 29ff.).
7 Commercial online survey platforms are available from many providers for a small fee. In addition, Microsoft SharePoint, used in many enterprise intranets, has a useful online survey feature.
8 Heath and Heath provide an elaborate example for this technique in a therapeutic context (marriage counseling) on page 36ff.
9 Chip Heath and Dan Heath describe another example. The oil company BP, in an attempt to reduce its exploration costs for new oil fields, gave out the vision No Dry Holes (Heath and Heath, p. 86ff.). Before drilling, the explorers try to spot the oil fields by remote sensing. The real costs are then caused by drilling an oil well. Before the maxim, BP had a success rate of 20% with its wells; only in 20% of the cases they actually did find oil—the other 80% produced dry holes. The new maxim required a 100% success rate. BP at least came close to fulfilling it: The company’s hit rate climbed to 65%, three times the industry average (Slogans That Work, 2007).
11 Heath and Heath describe the project mood chart verbally on page 168 of their book. We added the success and failure markers and the possible death-march outcome.
12 Broadbent and Kitzis (2005) describe a Boston square for the opponent and supporter classification and recommend a priority order to deal with them (p. 52ff.). Strictly speaking, their advice is targeted at a CIO dealing with her peers in top management. However, as for nearly all other parts of this extraordinary book, it applies also to initiatives driven by less influential members of the organization, such as enterprise architects or middle managers.