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.