(Note: I've added an addendum to this post)
It has been many years that we have lived with the concept of technical debt. Martin Fowler did a good job of describing the concept in a 2003 article on his wiki. Basically, the idea is that you can make a quick-and-dirty change to software. You will have to spend time to fix that software later. That additional time is like an interest payment on debt that you incur when you made the change. Fixing the code to make it more elegant and clean “pays down the debt” so that future changes cost less to make.
I’d like my fellow practitioners to consider joining me in extending this idea to the enterprise.
Organizations change, and sometimes the changes have to be made quickly. Processes that are implemented “quick and dirty” may have poorly defined roles, overlapping responsibilities, and duplicate accountabilities. It may work, and it may be necessary to hit a deadline. However, these “dirty” processes have the same problem that dirty code does – it costs more later to fix them.
In a sense, partial process or accountability “fixes” in an organization create “enterprise architecture debt” or “EA debt.” We run into it all the time in organizations. Here are some examples that I’ve personally seen:
These, and a thousand more situations, are the result of “partial” or “messy” implementation of organizational changes. They are a form of “EA debt” because any change to the organization that hits these capabilities will be more expensive to change in the future as complexity slows down the organization. In effect, EA debt is like taking a Lego set and gluing the pieces together. The parts will remain just as they are, but the will be very difficult to change in the future if something needs to change. (Apologies to “The Lego Movie” for the metaphor).
Why call this “EA debt?” Because it is not a financial term. It is nearly impossible to accurately measure all of the EA debt in an organization. It is, however, fairly straight forward to measure monetary debt. So we have to be careful not to use terms like “enterprise debt” or “organizational debt” as these may be confused with general accounting concepts. Just as technology teams sometimes twist the concept of an “asset” to apply to an information system, Enterprise architects are using the metaphor of debt to refer to one of the root causes of difficulty in making organizational change.
Addendum: I guess I shouldn't be surprised that this idea is not novel. It's fairly self-evident. It was my mistake that I didn't go looking for other references to the idea before writing the above post. Laziness. No excuse. While the concept of technical debt does in fact trace back to Ward Cunningham (inventor of the Wiki), as discussed by Martin Fowler in the referenced blog post, the application of that concept was first applied to EA in 2008 in the Pragmatic EA Framework, and is part of the current version as well. I'd give a link to that presentation if I could but the best I'm able to do at this time is a general link to PEAF at http://www.pragmaticea.com. Kevin directly responded below with links into his material . It is no disgrace to be in the shadow of Kevin Smith (author of PEAF). It is an error, however, to appear to originate the idea. For that, my apologies.
Many folks frame enterprise architecture (EA) as a function that is necessary because organizations need alignment. In that mind set, the primary value proposition of EA is to create initiatives that are aligned to strategy, are feasible, well scoped, and should result in a fit-for-purpose organization and information infrastructure. In this way of thinking, it is up to the enterprise architect to figure out what trains need to leave the station, where they are going to go, and when they need to arrive. All the passengers have tickets and all the conductors have schedules and everyone is set and ready to go.
Note that I highlighted two words: “create initiatives.” In this view of enterprise architecture, once those initiatives are created, their work is done. Projects teams “drive the trains” and move the people and get the work done.
Source: Train Wallpapers
I have a problem with this viewpoint. Consider this question: Does enterprise architecture “go away” after the initiative is framed, business case is proposed, and the funding cycle is complete?
The answer is emphatically “no.”
You see, the real problem is NOT alignment. It’s execution. Creating a great strategy is tough, but getting your organization to change to meet that strategy is far tougher. Sure, part of that problem is solved with alignment. Alignment is necessary because it gives you the right mix of things to do. It is essentially a planning activity.
But execution is not a planning activity. There are far more screw ups in the execution than in the planning. So if the EA is trying to bring about the changes that an executive has demanded, in order to make a strategic change actually occur, he or she cannot stop when “alignment” has been achieved. The role of the EA has to continue all the way through execution to make sure that the “train” (the initiative) reaches the right destination. That is why, within Microsoft Services, we refer to Enterprise Architecture efforts using a “framework for value realization.”
The train metaphor is problematic because we think of a train as a tightly engineer marvel of modern efficiency running on a pair of rails that are carefully laid out. Initiatives are not like that. Business initiatives are like a train built by monkeys. They are not remotely similar to marvels of modern efficiency. They are noisy, rattling, energy wasting, Rube Goldberg machines that would fall apart at the drop of a hat if not for the efforts of many people, often unsung heroes, who keep everything moving in the same direction.
What’s more, that train is running on a network of tracks that interlock and weave and visit multiple places from different directions, full of dead ends. There is rarely a central dispatching office(PMO) watching over the whole operation and even when there is, it rarely has good information on which to base decisions, reducing it to a status-reporting role. Without oversight and plenty of assistance, the business initiative “train” may end up stalled in some wayward place, abandoned.
Photo: R. Lowsek Source: Uyuni – Bolivia’s Train Graveyard
Enterprise architects have a duty to complete their mission: execute the strategy and realize business value. Creating the schedule and planning the route is not enough to deliver business value. An enterprise architect must actually ride the train (or watch to make sure it moves through a particular set of stations). He or she must listen to the rattles it makes as it switches from one direction to another, evaluate the alternatives of design and implementation, and consider whether the train is carrying too much or too little cargo (scope) for it to handle. Most importantly, an enterprise architect must be focused on making sure that the train, upon reaching the destination station, actually delivers value when it gets there.
All too often, a train (project) will drop scope or change course along the way. It may get to the right station, eventually, but along the way, the conductor had to lighten the load, so he dropped a few cars. The conductor (project manager) declares success when the train hits the station. To him, it doesn’t really matter if the time delay caused by the "Left Turn at Albuquerque" meant that the cargo missed its connection.
According to project management professionals, it is up to the business stakeholder to make sure that the value is delivered properly. The enterprise architect has nothing to do with it, right? The twist is that the operational business stakeholder rarely cares about the enterprise perspective. He or she may be interested in “local success” that can be reached, regardless of the compromises taken along the way. In this case, both the project manager and the business stakeholder declare success, while the actual value needed to reach the strategy is lost.
So success leads to failure. The train gets to the right station, perhaps even “on time,” but without actually delivering the value. The wrong cargo is delivered or it was left behind along the way. This describes countless “business initiatives” that I’ve seen over the decades. It’s so common, we have a term for it: watermelon project (green on the outside, red on the inside). Maybe we should call it a “dead strategy walking.”
A business initiative is not a smooth, well oiled machine. If it were a machine, it would be a train built and operated by monkeys. Parts would fall off, or be added on, for reasons unexplainable, and the direction taken would depend on the whims of political decisions that can seem arcane and undecipherable on a good day. Getting an initiative going is not the hardest thing you will do in your life. Far tougher is riding atop the initiative train, making sure that it doesn’t do really dumb things, or fall off the rails, and gets to the actual intended destination with the value proposition intact.
An enterprise architect is an invaluable element for ensuring that business value is actually realized from an initiative. An EA will collect metrics, prior to the initiative, that illustrate both the problem to be solved and the various other measures of productivity and business value that could be impacted as the program proceeds. He or she will do more than just collect and report on value realization. He or she will use the opportunity of collecting this information to guide key decision makers towards decisions that maintain enterprise value and away from decisions that diminish enterprise value.
The enterprise architect, in the best case, is involved in key decisions through this oversight process: how processes are to be changed, where activities (both operational and change focused) should occur, how people will get ready for change, how the change will be orchestrated to ensure that operations don’t lose value, what information will be leveraged, what systems will be impacted and in what way, what lifecycle considerations must be taken into account (both service, information, systems, and technology life cycles), and what dependencies will be created or relinquished. In most of these decisions, the EA is not the final decision maker. He or she is there to provide the “enterprise perspective” and argue on behalf of senior leaders whose strategy may be impacted. In a best case decision matrix, an EA would be able to escalate a disagreement to a governing board that includes a broad array of enterprise stakeholders.
The role of an Enterprise Architect is focused on much more than simply “aligning initiatives to strategy.” They are also called upon to oversee those initiatives as they proceeds through execution, and to advocate on behalf of the enterprise all along the way. Let’s recognize that a plan has no impact on an organization… only the initiative that follows the plan (or not) can change things. When the Enterprise Architect oversees these initiatives, he or she has the opportunity to fulfill their promise to execute strategy and realize business value.
There are a spate of new Social Media apps that have emerged lately, all of which allow people to post comments and ideas anonymously. They are being quickly adopted, especially among the very important 13-18 year old “adolescent market.” They are also being quickly banned for promoting cyberstalking, cyberbullying, and otherwise cruel behavior. Does anonymity protect cruelty? And what does that say about more established Anonymous sites, like Wikipedia?
Normally I don’t comment on Social Media. My regular readers know that I tend to focus primarily on enterprise architectural concerns like business model viability and strategic alignment. But there is an interesting cross-over between Enterprise Architecture and Social Media, especially anonymous social media: the creation of community consensus.
For those not keeping up, there is a spate of new social media apps that have emerged lately, from Whisper to Secret to Yik Yak, that allow smartphone users to sign up and then post messages unfiltered and anonymously. When in anonymous mode, users tend to say things that they feel uncomfortable saying on Twitter or Facebook (where their friends, family, and coworkers may discover a side of them that they may not agree with).
YikYak especially is troubling because it uses a geolocation filter… you can see things posted by people within a certain distance of you. Sounds innocent, right? After all, young adults filtering through Bourbon Street festivities in New Orleans could share that a particular bar was playing really good jazz, or that drinks are strong and cheap across the street. But you may quickly see the problem when I use two words: middle school. Already, some High Schools and Middle Schools have had to ban the app because it became a platform for bullying and cruel comments.
But what does it mean to be anonymous? What are these comments that the guy next to you would like to send to “the world” without anyone knowing it was him?
You can look for yourself at Whisper.sh. I spent a few minutes browsing through some of today’s messages. Most were simple secrets… many were sexual or related to dating. Some were work related. Most had responses from equally anonymous people, and most were fairly benign. Of course, there could be some judicious editing going on for the sake of casual surfers like me that own a Windows phone (and therefore can’t use the app). Secret and Yik Yak don’t even make an effort to show any of their messages on their website. It’s all in the app (once again, only for IPhone or, in the case of YikYak, android).
Of these, I think Yik Yak is the most interesting from a consensus point of view, because it is the only one that attempts to filter according to a community. GeoLocation, especially when it comes to universities or even small towns, is sure to limit the reach of a message to people who share something in common with you. That sense of “sharing something in common” is really what defines a community, and consensus only really matters in a community.
Does anonymity work to create consensus? Sure. Think of standing in a large crowd. If one person yells something, you don’t normally turn to them and identify the source before considering, and possibly agreeing with, the content. This is the very essence of a political rally or a protest march. Taking in unfiltered ideas and deciding on them, on the spot, is part of how consensus is built. Of course, there is no good way to take in ONLY good ideas when you are in a crowd. We count on the crowd to do that for us. If someone in a political rally yells “Death to the other guys!” we would expect the folks standing next to them to react, possibly causing the rabble-rouser to back down. (Unless your protest march is in Karachi or Tehran or Cairo… but that’s another post).
In that sense, standing in a crowd is only “partially” anonymous. There are still people who can see you, and if you do something really outrageous, there are people who could react by hitting you. This is why you won’t find many people who will go to a crowded Yom Kippur (Jewish) service and stand up in the middle of the crowd and yell “Hitler was right!” Pandemonium.
But consensus and anonymity online is very different than standing in a crowd, and I think we need to be aware of the differences.
Online, you can make claims that are difficult for another person to dispel, without consequence at all. There is no one next to you ready to elbow you when you use name calling, or circulate unfounded rumors, or simply make things up! Even when we use our actual names, we may participate in a discussion where we are not in the same room, or even the same continent, as our peers, and this can cause problems.
I cannot count the number of times I’ve witnessed this on LinkedIn. A person will ask a question about frameworks, and I may point them to PEAF (a framework created by Kevin Smith). No problem. But if Kevin himself gets on the thread and mentions PEAF, his messages are blocked and he may even be kicked out of the discussion. Why? Because someone somewhere made a spurious charge (that he makes money when you use PEAF, which is not true). Since the administrators of most LinkedIn Groups are anonymous, they can make bad decisions without consequence. There is no good way for Kevin to clear his name of these charges because he does not know who the administrators are, and they appear unwilling to consider the possibility that he is not, in fact, using the platform to promote his own self interests. Rumor rules the roost. Not good.
I believe that the same thing applies to Wikipedia.
Wikipedia, with its millions of articles, has emerged as one of the chief sources of encyclopedic content on the Internet. It is widely respected, and most search engines make a point of returning Wikipedia entries near the top of their search results. However, the administrators on Wikipedia are mostly anonymous. (They use pseudonyms to do their editing work).
This causes the same problems to occur in Wikipedia that occur in any other setting where people can be anonymous… mostly benign behavior with occasional outburst of bad behavior (with nearly no consequence).
There is an essay (not a policy) on Wikipedia that says “Only Martians Should Edit.” This policy says that some topics are so controversial that anyone associated with the actual content would be too biased to edit the content in a neutral manner. Therefore, topics dealing with such things as State or Provincial politics, or national boundary disputes, or whether specific historic events should be counted as a genocide. These things trigger strong emotions, so having people edit the articles as though they are “from Mars” can be a good policy.
On the other hand, for some topics that are very narrow, it is not possible to edit the article without knowledge of the subject. If you are not an expert in African pop music, you may not do a good job discussing Azonto music and dance from Ghana. In this case, an editor with no grounding in the subject is likely to make mistakes.
The problem is that Wikipedia is based on consensus, and you may find yourself editing a page on Wikipedia where you have to build consensus among anonymous people, people that may or may not have ANY understanding of the subject matter. And those people can be nice, or cruel, with no consequence. There is no one in the crowd next to them ready to elbow them for making an outrageous statement… because the other editors don’t know if the statement is outrageous! You can build credibility on how well you enforce the rules, and then use that credibility to attack someone, and no one else can tell the difference.
I’m of the opinion that anonymity on the Internet has to be handled with care. There are times when it is necessary, especially when attempting to avoid governmental or organized oppression to free speech. On the other hand, there are times when it is a license for ill-informed people to promote nonsense as a consensus. After all, one third of Louisiana Republicans have been misled into thinking that Obama is to blame for the poor response to Hurricane Katrina. I can think of a other examples of an ill-fated consensus among the ill-informed, but rarely one so laughable.
I believe that Sites and Apps should not leverage anonymity as a feature. I make exceptions for Tahrir Square and Occupy Wall Street, etc, where rumor may be the only information you can trust, but that is not what these apps do. For normal social interactions, anonymity is actually a problem. On Wikipedia, I believe that anonymity has outlived its usefulness.
I made an interesting mistake, today… one that comes up from time to time. I used a business term in one way, and some members of my audience understood what I meant, while others did not. In this case, the word was “core”. The word has two different definitions. Unfortunately, the definitions are quite different, at least in an Enterprise Architecture context.
The dictionary definition of “core” reflects the problem. Bing dictionary defines “core” as the “central” or “most important” part of something. Notice the word “or.” Either meaning can be intended.
This goes to an old idea of putting the most important part of something in the middle. In ancient kingdoms, the capital city was often very centrally located, usually near a convenient transportation route (like a river) that offered quick access to all parts of the kingdom (within reason). So, the word core can mean “most important” or it can mean “in the middle.” In the past, those two meanings were synonymous.
But in business, the thing “in the center” is not the most important thing. Porter illustrates this with his (now famous) value chain model:
Porter’s Value Chain. Image source.
What is the most important part of that model? It’s the bottom-half, illustrated as the “primary activities” or value chain. Porter is smart enough to avoid the word “core” because it has the connotation of “in the center” when he wanted to illustrate that value chains are not “in the center.” They traverse “end-to-end”.
Porter seems to be somewhat alone in avoiding the term “core.” Many business books and resources use the term “core” when referring to the primary activities. There are countless illustrations, if you bing for images with the search phrase “business core”, where you are looking either at a set of service offerings or a value chain. The following diagram is a business architecture reference model for the hospitality industry. The name of this model: Core Business Domains and Processes.
Core Business Domains and Processes – Hospitality Technology Next Generation Reference Architecture
On the other hand, there are also illustrations of business where “shared” items are at the center, and non-shared items are “at the edge”. Illustrations like this one are also quite easy to find:
Source: United Nations Office for the Coordination of Humanitarian Affairs
In business architecture, do we illustrate “core” things to be “shared things at the center of a circle” or do we mean “core” to be “the most important things?”
In Enterprise Architecture, the distinction becomes more problematic. Shared things are often the LEAST important thing from the perspective of the business, not the MOST important thing. For example, the HR department is often a shared function, and unless the company is an HR service provider, that business function is not part of the value stream. On the other hand, from the perspective of information architecture, the shared things are the most important and the non-shared things are the least important. For example, a single understanding of “customer” is critical, especially when that understanding is shared across marketing, sales, and customer service. It is shared, common, and very important.
Now, add a specific use of the word “core” that is used in EA: the notion of a “core diagram” as described in the book “Enterprise Architecture As Strategy” from Ross and Weill. In that sense, the diagram itself may vary depending on which one of the operating models is being used, but the model itself is a shared, common understanding of the key items that are shared (whether that is process, information, or both). In that case, the thing that is important is the thing that is shared. That is called “core.”
Two years ago, I made a presentation to the Open Group conference about creating core diagrams using a method I created called “Minimum Sufficient Business Integration.” In that method, I use the word “core” many times to refer to “shared” items that are central to an organizations’ Enterprise Architecture.
So, what definition should I use for “core” when having a discussion about business and enterprise architecture? Should the word “core” refer to “the most important” thing, or “the most shared” thing?
I don’t have a good answer. Perhaps the best answer is to avoid the word “core” altogether.
One of the most common problems in Enterprise Architecture, and one I get asked about routinely, is the “ladder” problem. Many Enterprise Architecture teams are formed by assembling a group of talented technologists into a team and giving them a charter to “go do EA.” The problem is that most of these teams have no credibility outside the technology group, and cannot really operate as a “bridge between business and IT” if they don’t have the relationships and knowledge that they need to be an Enterprise Architect. Building those relationships and that credibility takes time… sometimes many years. Until they make that transition, the team is an Enterprise IT Architecture team (EITA) and while that is useful, the value proposition of EA remains unfulfilled.
I call this “climbing the ladder” from EITA to EA.
While the entire team should work on this, only a few will succeed. Good news: That’s all you need. However, it’s important that everyone makes the attempt to climb the ladder. As a manager, I have no magic “test” to determine, for certain, which member of the team will make the transition and which won’t. I once thought I did, but reality proved me wrong. So everyone makes the attempt. Those who remain EITA’s can continue in that role for the EA team, or they can transfer to a different group where their technical skills are valuable and needed.
So, how is this done? How does an individual EITA climb the ladder?
You need four things:
Business knowledge is the one that should, on the surface, be the easiest of the three to acquire. Unfortunately, it seems to be one that is sorely lacking among EITA’s who are attempting to make this transition. What do I mean by business knowledge? I mean the ability to understand the basic concepts of business at a working level. In other words, can you answer these questions coherently:
Where do you get business knowledge? There are a gazillion books that will give you the basics. Universities are helpful as well. With the wide array of support, Enterprise IT Architects should have no difficulty learning these things… yet it’s startling how many don’t. I have some friends who insist that an MBA is needed. I disagree with that, but college courses do help. I hold out the most hope for success with a blended program like that offered by the Enterprise Architecture degree at Pennsylvania State University.
There has been a good bit of ink spilled about technical topics: mobile platforms, SOA, security, etc. These help with the EITA side of the job. But they don’t do much for the architect who needs to climb the ladder. To successfully make that move, most architects need to invest in training on their soft skills. This means building up the following:
Did you know that courage can be learned? I guess I always knew it was possible, but I never really considered it until I found myself with a situation where I needed to use courage, and needed others to do the same. I was playing the role of a SOA architect, and I needed to convince development teams and technical architects to adopt a set of patterns that would help the enterprise, but may actually add complexity to their own project. I needed to walk into rooms and see if I could demonstrate, convince, cajole, argue, and/or negotiate my way to changes that were not in the obvious best interests of the team itself.
I taught myself courage. I taught others courage as well. Part of teaching, and learning to be courageous, is to put your efforts into perspective. See your work as necessary to a “bigger picture” and be very aware of how much you can get away with before others decide that they cannot actually follow your lead or support your efforts.
Courage is not the lack of fear or operating outside of dangerous situations. It is the conscious choice to move ahead despite danger. As the Will Smith character in “After Earth” tries to teach his son, “Danger is real. Fear is a choice.” Sometimes, as an Enterprise Architect, you will have to tell someone powerful something that they don’t want to hear. The situation can end badly, impacting your ability to continue working as an Enterprise Architect, or worse, resulting in you losing your job. These dangers are very real to many EAs.
Courage means that you will need to move ahead anyway. It does not mean you should be reckless in the face of danger. It is OK to be cautious at times. But real success often requires boldness, and your bold actions cannot be made without the courage of your convictions.
There is a difference between “being courageous” and “being stupid.” The difference is support: do you have the support you need, by someone higher up the food chain, to take on the challenge of climbing the ladder in most organizations. This support from above is critical to your success. I call it “air cover” (a reference to a military situation where ground troops can request a deadly strike on an enemy to be dropped from planes, missiles, or artillery).
In a business setting, air cover means that you have successfully convinced leaders in various places around the company that you can be trusted. They believe that you are valuable and that your motivations are in the right place. So when a problem occurs, or one of your standards is challenged, or your roadmap makes a stakeholder angry, that leader can step in and sooth sore egos.
I cannot indicate the importance of air cover. For architecture managers, if you don’t provide air cover for your team, you are worse than an ineffective leader… you are a disgrace. And for architecture practitioners, if you don’t build the relationships you need to build so that you will have the air cover when you need it, you are not being courageous. You’re being stupid, reckless, or chaotic (take your pick). To climb the ladder, someone has to be holding the ladder. That’s your air cover.
Climbing the ladder is a difficult challenge for any Enterprise IT Architect (EITA). It takes dedication, support, and some significant innate abilities. However, for many who take on this challenge, the rewards are excellent. I truly love Enterprise Strategy Architecture. I hope to see many of you “in the trenches” with me, fighting to make our ecosystems healthier, stronger, and more agile every day.
You’ll notice that I never mentioned Certifications or Frameworks in the discussion above. That’s because I’ve met and known hundreds of Enterprise Architects. Certification was only useful to make them more effective as an EITA. It made no difference for climbing the ladder. Certification will help with some skills and a great deal of knowledge. A certification may build confidence, reduce churn in your team, and make your results easier for others to read and follow. I’m not putting down certifications. I’m just pointing out that this step comes with experience, not certification. At least, not yet.
One of the most compelling things that an EA can do is frame the vision of a better future as a story. I’ve found this to be true many times, and others have discovered this as well, but it is not frequently discussed among architects. I’d like to bring together some of these threads and talk about three things: a) the effectiveness of story, b) how to create a story, and c) whether you need more than one story.
Enterprise Architecture is about change. If nothing is changing, the value of EA is fairly low. That said, very few organizations, public or private, are in a stable state these days. Change is everywhere. But change is not easy.
Your stakeholders need change, but they may not want it. In some cases, they want the change, but their peers are not asking for change. Either way, getting change to happen in an organization requires a touchstone – some common belief or idea that everyone can relate to. It has to be more than a fact, and more emotive than a strategy. It has to be compelling, interesting, surprising, and easy to remember. In the words of Chip and Dan Heath, this central idea has to be “made to stick.”
In my experience, every time an organization changed, there was a story at the heart of the change. In each case, there was a single story that helped people to see how the change would happen, or helped to see how the customer would be happier, or helped to illustrate how the new world would work.
In the book, “Enterprise Architecture as Strategy,” Jeanne Ross described the concept of a “core diagram” which was a single image that people rallied around. I’ve spoken about core diagrams before, and have suggested a way to create a core diagram that reflects an optimally agile organization. However, the core diagram is only part of the story.
The story itself is what makes change possible. The story itself is the touchstone – the “shared memory” that everyone recalls when the topic of change is discussed.
Truly effective leaders understand this. Steve Jobs would often use stories to get audiences (internal and external) to see the value of what he was doing. Bill Gates, having shifted to health and education issues, still uses stories to communicate and connect. The most effective political speeches, and most rousing situations, are always connected to a story. At the time of this writing, Nelson Mandela recently passed away. What are people remembering? They are remembering his story. They are also remembering how he used stories, as well as principles and a dedication to action, to create change.
Successful change requires more than a story. You also need to have a vision of what the destination of your change is. But you cannot get to that destination unless people move, and people won’t move without an emotional connection to that destination. Stories are necessary, but not sufficient. Stories are the connection, not the destination… but you need both to survive.
Storytelling is an old craft, but business storytelling is fairly recent. There are many things to consider, and it can take a while to figure out all the steps. In general, I suggest that change agents should focus on four areas:
I use a simple mnemonic to remember these four steps: C-A-S-T. Content- Audience- Story- Tell.
In all fairness, this is a simple blog post, and the topic is a bit bigger than can be placed here. Big enough, in fact, for a good book. If you want to actually create a story, I’d recommend readers to pick up a copy of my book from Amazon or your local bookstore: Stories That Move Mountains. It is a visually striking book (thanks to Mark West) that tells the story of storytelling for business change.
Note that the book is available in multiple languages, so check out your local bookstore. (I shared a copy with one of my friends, and my wife picked up the Italian edition off my bookshelf to hand to him. We all got a good laugh out of that).
In telling a story of Enterprise Architecture, you may need more than one story. You may need a story for the IT folks, and another story for your business stakeholders (especially for heavily technical stories like you’d find with BI or SOA initiatives).
For each story, you will go through the process above, and in each, you would consider the audience. But for the sake of this blog, I’d suggest that an Enterprise Architecture story needs to consider each of the changes being suggested. Typically EA impacts each of the BAIT areas, but you probably only need two or three stories: one to tell about the IT changes and one or two stories for business stakeholders (a low-level story for impacts to business processes, and a high-level story illustrating alignment and customer centricity).
I don’t have any better advice to give to an Enterprise Architect seeking to increase his or her level of impact and influence than this: learn to tell effective stories. The story never stars the Enterprise Architect. At best, you are the helper, the assistant. You are not Frodo, but Samwise (or Gandalf). But the story compels the mind, and engages the heart. The story holds the vision and makes it easy to communicate. Wrap your vision in a story. It is not a promise of success, but it helps.