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.
The Effectiveness of 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.
![image]( "image")
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.
![Enterprise Architecture As Strategy: Creating a Foundation for Business Execution]()
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.
How to Create a Story
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:
- Focus first on the Content: Why do you want to change? What must change? How will the change occur? What if the change happens (and what if it doesn’t)?
- Focus second on the Audience: Who must change and in what way? Who do they listen to? How do these folks learn? How do they make decisions? If you don’t know who you are telling the story to, you are reducing the odds of success.
- Focus third on the story elements themselves: What is the structure of your story? Who are the characters of your story? What drives them to move forward in the story? And, very important, how will you tell the story to the audience? Will you use videos? Will you use a PowerPoint presentation? Will you have people enact the characters? Will you rely on signs and posters? You have to think about all of these elements.
- Focus fourth on the Design of the story and the Testing of the story. Design is critical and important, but as you can see, we don’t jump into design first. We first understand the story we want to tell. We go to design late in the process, only after we’ve thought about the problem we are solving, the people we are trying to change, and the elements of story. But even minor mistakes in design can create unnecessary distractions from your story.
How do you find the mistakes? Test, Test, Test, Test, Test. You wouldn’t “ship” a software product without testing it, right? (unless you are the Center for Medicare and Medicaid :-). So why would you “ship” a story without testing it. This means rehearsal, delivery to friendly audiences, feedback from peers and the friends of your stakeholders, etc. Any way that you can get good ideas about how well your story is connecting.
I use a simple mnemonic to remember these four steps: C-A-S-T. Content- Audience- Story- Tell.
![image]( "image")
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).
How Many Stories Do You Need?
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).
Conclusion
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.
![]()
.
