I explained to one of my clients recently that there is a perception of animosity between the Enterprise Architecture community and the Agile community. Both sides make assumptions about the other, often assumptions that are simply unfair. For example, many in the EA community think of “agile practices” as an opportunity to develop software without any architecture at all, while many in the agile software development community think of architecture as one of the “big design up front” guys who oppose their principles and practices. Of course, it is not difficult to find people who fit those unfair descriptions, but I’d like to point out how these two viewpoints are similar.
I believe that effective Enterprise Architecture must be approached from an agile standpoint.
First off, what does it mean to be agile? We can always look to the agile manifesto for some guidance, but more recent publications do a good job of filling in some of the details as well. I include a number of things in the notion of “being agile.” These are not just from the agile manifesto, but also Kanban and the Theory of Constraints, Systems Thinking, Six Sigma, Scrum, eXtreme Programming, and value stream analysis.
I follow the terminology of Sam Guckenheimer in calling this the “Agile Consensus.”
We have to recognize that the "agile consensus” is an approach, not a methodology. It is a way of thinking about dealing with problems. More importantly, it is a way for dealing with complex problems. The diagram below comes from Ken Schwaber (inventor of Scrum) who adapted it from Strategic Management and Organisational Dynamics, by Ralph D. Stacey.
When we look at the problems that software is being used to address, and if we look at the process of writing software itself, we have to recognize that both areas of problems typically fall into the category of “complex.” Not always. Some software is simply configured and configured simply. Some problems that software addresses are simple problems. However, most of the discussions around software development are fueled by people addressing complex problems because that is where most of the software development community works. It is the bread and butter of software development: solving complex problems in a complex way.
Enterprise architecture also deals with complex problems. EA models and information are also complex to build and manage. In this way, EA is very similar to software development. EA solves complex problems in a complex way.
In order for EA to be effective, it has to use the same mentality as agile software development.
When I speak with enterprise architects who are actually doing the job of EA, big themes quickly arise:
If this looks like the list above, that is intentional. I am trying to point out that Enterprise Architects use agile ideas, even if they often don’t use the term “agile” to convey the message.
Why use these techniques? They work for complex problems.
Can someone think of a more complex problem than helping to move an organization towards their goals?
EA addressed complex problems. Agile thinking helps them to do it.
The video below, from RSA Animate, is not about Enterprise Architecture. At least, on the surface, it isn’t. In the video, we hear the voice of Roman Krznaric, a philosopher, talk about the need to build a greater reliance on the human emotion of empathy in order to create social change.
But as an Enterprise Architect, I am in the business of creating social change. I’m actually paid to get things to change (how’s THAT for a cool job). Of course, I’m paid to make the changes within corporations, and the benefit goes to the corporation by making them more effective, efficient, or timely in their desire to “make tangible” their own business strategy. However, the reasons and rationale aside, my job is all about change. And people do change, but not easily and not quickly.
There are many reasons that people don’t change. My father used to say “the hardest thing for a person to do is to think. The second hardest thing is to change. So if you want them to think, don’t ask them to change, and if you want them to change, don’t ask them to think.” Oh, there’s truth in there. You cannot get people to change simply by “convincing” them to do it. There has to be more to it, and there is. But to understand how to motivate change, it helps to start with a little thought experiment.
Think about the times when you changed. Seriously… stop right now and think about your own changes. Have you ever changed a core belief? Have you ever converted to a religion, or away from one? Have you decided to change your profession or career? Have you ever decided that the things that you always assumed were now completely untrue? Think about family members that changed?
Did you change because someone asked you to think? Or did you change because someone asked you to feel? What led the way?
I am convinced that the only EFFECTIVE way to motivate change is to reach out and touch someone emotionally. You can bring them along with logic, but if you don’t find their heart, and connect with their feelings, they won’t feel your message. Notice, I didn’t say that they won’t hear your message. They can hear just fine… but without connection, they won’t feel your message. And if they don’t feel your message, they won’t follow your lead.
We have often heard that change is about leadership. But how does a leader lead? Is it through logic and elegant words, or is it through emotion and beautiful thoughts? The most effective way to lead is to use both, but if you have to use one, use the emotional side first. In Switch, How to change things when change is hard, authors Chip and Dan Heath argue that you have to engage both the logical side and the emotional side to want to change. However, their metaphor is one of a person riding an elephant. The logical side is the rider. The emotional side is the elephant. Why, in their metaphor, did they choose an elephant? Because the emotional side is much larger than the logical side, and we can viscerally understand the metaphor on the basis of size and strength alone. After all, if the elephant wants to turn around, the rider can do little to stop him.
In Switch, the Heath brothers argue that change is an emotional journey and that there are three parts: the elephant, the rider, and the path. If the path makes sense to both the elephant and the rider, then you have removed the obstacles to change. Make it a clear path. Appeal to the rider to want to take it. Appeal to the elephant by addressing the fear or uncertainty that may drive them away from it. That is the job of the EA. To make a clear path, and to make it so that it starts where the elephant is actually standing at the moment.
So as an Enterprise Architect, how do I find a way to communicate with the Elephant and the Rider in the people that I want to work with? I use empathy. I don’t just use empathy… I live it. Empathy is the single most powerful, most important, and most useful personality trait that an Enterprise Architect can have, bar none. It is a skill that must be practiced, and learned, and honed. It is more than listening, but listening is involved. It is more than feeling, but feeling is involved. It is connecting at a deep level with the people that you are being asked to work with. It is building an empathic bond with them.
Having a strong sense of empathy means that the EA has a strong internal drive to connect with others. He or she wants to hear their stories, and learn their troubles, and feel their triumphs, because ONLY by connecting with another individual can an EA understand what is motivating that person to change, and what is keeping them from achieving it. Only by listening to their struggles, and their successes, and their own efforts, can the EA create a path for that “emotional elephant” that Chip and Dan Heath describe. Because the job of the EA is to create the path. The job of the leader is to connect with the elephant to bring them down the path.
Some people motivate others through fear. Do this or you will lose your job. Do that or the company will go under (and you will lose your job). Do this other thing or we will cut your bonus or give you an assignment that you will hate. Some will motivate through rewards and recognition. “Look at what Tom did! He delivered excellent results and we want to honor him. You can be honored if you do as well as Tom.” In our capitalist society, that may even be in the form of income: “Your bonus will be larger if you do a better job.” (Both of these approaches fail, by the way. True story. Watch this TED video of Dan Pink’s presentation on motivation).
In order to motivate change, especially in creative jobs, you have to make it easy for the elephant (the emotional side) and the rider (the logical side) to follow the path from where they are to where they need to be. Notice that the path doesn’t start from where you think they are, or where a company thinks their employees should be. It starts from where they actually are. Without empathy, you may build the perfect “path” but it may start in the wrong place… where the elephant is not actually standing!
Empathy also helps you to connect with the person who you want to change, and to discover their intrinsic motivators. As Dan Pink points out in the TED video I linked above, the most important motivators are intrinsic. They are internal. They are not the incentives offered by the business. They are the things that a creative, thinking person already wants: Autonomy, Mastery, and Purpose.
If an EA wants people to change, that EA has to engage that emotional elephant and that logical rider. To give people the autonomy that they need, and to demonstrate the mastery that they can achieve, and to give them a purpose to follow, in the world of control, incentives, and finance that the business lives in, you have to first listen and connect and understand. That requires empathy.
To be fair, these are steps to create a solid understanding of the architecture of a business, but the deliverable is a core diagram, so that’s the title of the post. I first wrote about a method for creating core diagrams about a year ago, as I was preparing for a talk on the subject at the Open Group conference in San Francisco. Now that I’m preparing for another Open Group conference, I find myself filling out some of the details from the previous effort. Most of the text below is copied from an e-mail that I sent to a fellow business architect who was asking about how to create a core diagram.
The text below describes a five step process
Understanding how to create a core diagram starts by collecting a list of the business models that your organization performs. Each business model is unique and different from the other ones. Each will require different capabilities and will often drive variations in those capabilities for the sake of market or product differentiation. You cannot create a core diagram effectively without the list of business models.
So what is in a business model? I’ve blogged about that fairly well. A business model is a composition of elements that describes how and why a value proposition exists, who it is for, and what it drives in terms of internal and external requirements. The diagram is below. (click to enlarge)
Once you have the initial list of business models, you will want to engage with direct business stakeholders. Make sure that they understand the concept of a business model, and what makes a business model unique from other business models (e.g. selling the same product in the same way to the same people in another country is NOT a unique business model, but selling a product in three different ways to three different, potentially overlapping market segments within one country probably represents three business models). Engage. Build relationships. This is your first shot.
Once you have that list fairly well baked, you have step two on your hands: a capability taxonomy that reflects process differentiation. In this case, it is a good idea to start with a high level process taxonomy like the ones made available for free from the APQC. I don’t know if there is one for financial services yet, but there should be. If not, you can start with a general one, but it will take some editing. You want your capability taxonomy to be worded in such a way that it represents “things that could be done” without reflecting the way in which they are done. For example, “customer identity management” is OK, but “customer deduplication” is not, because we want to make sure that customers have an appropriate identity but the organization may not want to remove duplication in order to do that.
This requires some editing of a large list of items in a hierarchy. Excel is OK for this. There may be other tools as well… I haven’t experimented past Excel. This is the second point where it is good to be engaging with business stakeholders. Get their help to describe their business model to you in terms of capabilities, and make sure that all of their capabilities are included in your taxonomy somewhere (usually around the third level down in the tree).
Step three is to differentiate each business capability on the dimensions suggested in the EA As Strategy book. (This can be done at a high level. If your taxonomy has more than 200 business capabilities in it, don’t use the most detailed level(s) of the taxonomy. No one has patience for the details in a core diagram.
Draw out a grid like the one illustrated in the EA As Strategy book, only make it empty.
In each one of the boxes, write in the capabilities that are well understood by a particular business stakeholder, then go to that stakeholder and validate your choices. Make sure that you have placed the correctly for that stakeholder’s particular business models. Note that very few stakeholders will have a valid opinion about capabilities that are NOT part of their particular business model, so don’t show capabilities that they don’t care about.
You will quickly discover that most folks agree on some things and disagree on some things. Where a single capability shows up in multiple businesses, one stakeholder may say that it needs high standardization, while another will say that the capability needs low standardization (== high flexibility). Take note of these disagreements. THEY ARE THE VALUE POINTS FOR BUSINESS ARCHITECTURE.
On everything you can get reasonable agreement on, go ahead and create a master table that has the capabilities differentiated in the manner above. That will probably be about 90-95% of your business capabilities in your taxonomy.
Step four is to make an “educated guess” about the operating model that your organization has. It’s a guess because most organizations are difficult to read and no one person will be able to answer your question about what the company as a whole looks like. Most of the time, you can start with the generalizations that Jeannie Ross made when describing the four operating models in her book “Enterprise Architecture As Strategy.” If there are a large number of capabilities in the “High Integration, High Standardization” box, you can suggest that your organization is a “Centralization” model. If, on the other hand, there are a large number in the “High Integration, Low Standardization” box, you can suggest that the organization is a Coordination model. This is the educated guess part because there is no good formula for making the guess. By this point, you will know a great deal about the organization so your guess is as good as your stakeholders.
Step five is to take a cut at your core diagram… Draw it out and then work with your stakeholders to get common understanding.
For each of the four styles of models, there are different styles of core diagrams. The centralization model tends to break out capabilities by functional area since there is very little (intentional) duplication. So it will be a diagram with a series of functional areas as boxes with the capabilities for each function listed in the boxes. Good idea to put the name of the person accountable for that business function in the title of the box. Lines between the boxes represent flows of information or value between them.
The Replication model is somewhat similar. There will be some functions that are owned by “corporate” while the rest are replicated into EACH of the operating units, so there will be two large “areas” on your diagram. The corporate area will have some functions with capabilities in them, and a single “replicated” area will have the remaining functions with capabilities in them. This is wildly valuable to business planners because they can get agreement among the leaders of each replicated unit about what each one of the is accountable to do and what they MUST depend on the corporate unit to do.
The collaboration model tends to be “hub and spoke” with the hub being the most integrated capabilities and the spokes being unique to each of the business models (or in some cases, small groups of business models that share a lot of capabilities). The lines tend to be information flow, not value flow. The capabilities in the spokes are usually duplicated between the different business units but they (should be) the capabilities that each business unit needs in order to differentiate itself or its products in the marketplace.
The diversification model is the most complex because the “corporate” unit tends to have a small number of core capabilities (often just financial ones) with each of the subsidiaries having a nearly complete and quite independent set of functions with massive duplication of capabilities across them.
I hope this gives you a good start in creating your core diagram.
I did a scan around the web to figure out what many of the leading thinkers were saying about IT project failure and the root causes. Numbers varied between 20% and 80% of projects failing to deliver on their business case. The root cause analysis that follows from these failure numbers spends a lot of time looking at the IT project, but most forget to look at the causes of failure that are outside the project’s control.
In the diagram below, the central blue box represents causes of IT project failure that are inside the control of the IT team. As you can see, there are many more causes of IT project failure that are OUTSIDE that blue box than inside it. Yet, countless articles have been written on the factors INSIDE the box. I think it is time we take a slightly wider lens to the problem!
The factors outside the project are as important, or more important, than the ones inside the box. I have worked on many projects over the years, and if I look back at the ones that ended up cancelled or scrapped, the reasons were not ones in the blue box. They were usually ones from the top box: where the project should not have begun in the way that it did. Let’s look at these six factors:
Each of these conditions has the potential to kill an IT project. I would suggest that MANY IF NOT MOST of the failures of IT projects can be traced to one or more of these conditions, but these conditions rarely get counted in the statistics for “Causes of IT Project Failure.” Why? Because, in most cases, projects that suffer from these conditions are either never funded, or are reworked so that the political problem is simply avoided. The project business case does not reflect the problem, so the criteria for failure (doesn’t meet the business case) is never met. Efforts are made to avoid (but not address) the problem before the business case is written!
This is the world of the Enterprise Architect. These are the kinds of “failure” that fill the eyes and ears of an Enterprise Architect. If an EA focuses on only these six causes, he or she will deliver real, tangible, and unique value to their enterprise without ever overlapping the roles and responsibilities of an IT architect, business analyst, or technologist.
There is a new book available that I’d like to let everyone know about. It is called “Stories That Move Mountains.” I wrote this book with two fantastic professionals Martin Sykes and Mark D. West. In this post, I’m going to talk about how this book came to be, and why I felt so strongly about it that I invested two years of my life in bringing it to market.
First off, if you are interested in buying the book, and we think you will be, you can click on the image of the cover to take you straight to our “buy the book” page on the book’s sister site, StoriesThatMoveMountains.com.
Edward Tufte and Me
My journey into “rich information” began, as it did many others, when I heard about a book called “Visual Explanations” written by Edward Tufte. It was 1997, and the dot-coms were booming. I had left Microsoft to stake a claim in the modern gold rush. I was working as a development manager in a quickly growing web development company in downtown Seattle called Fine.com International. (see note)
On my team was a talented young web developer named Brian Poel who told me about a seminar he attended hosted by Tufte. In the seminar, Tufte taught about creating visual designs that inform, not just impress. Brian showed me the materials and I ended up reading Tufte’s book myself (Another bit of evidence to support the old saying: a manager is only as good as the smart people that surround him).
At fine.com, we used the techniques described by Tufte in every way we could. His guidance led to design ideas that fed into the Nasdaq.com web site, the Marriott hotels web site, and many more. I learned the power of structuring information in a way that makes it easy to consume, elegant to perceive, and compelling to read.
It would be many years before I needed these techniques myself. That didn’t really start until I became a management consultant. The year was 2001, and the dot-com that I co-founded after leaving fine, Acadio, had failed along with tens of thousands of other young start-ups. I had moved to a consulting company called Sierra Systems Group (headquartered out of Vancouver British Columbia) to make ends meet. For the most part, I focused on technology activities, but I had to ramp up my communication skills. So I started using some of the rich information techniques that I learned from Tufte in our marketing and sales materials. I cannot say that I was particularly good at it.
I Can’t Draw… Seriously
I really can’t. Not even stick figures. Which is odd, because both of my parents, my eldest brother, and my daughter, are all gifted artists. Not that I can’t create useful diagrams… I had trained in high school as a draftsman. Give me a T-square, two triangles, a nice drawing board, and couple of sheets of vellum and I can draw a complete set of floor plans for your house (well… I could in 1980… maybe not so much now). But freehand, I am hopeless.
So when I tried to create a nice visual representation, and failed, I thought it was because of my lack of skill as an artist. I couldn’t have been more wrong. Regardless, the best I could do, at the time, was to follow the guidance in “Beyond Bullet Points” and create PowerPoint presentations that were compelling using emotive photographs. They were nice, but they weren’t the things I wanted to create.
Meanwhile on the other side of the Atlantic
Turns out, I was part of movement of sorts. A growing number of people had taken up the challenge of creating interesting visual representations of complex information. The “infographic” movement had started, and companies were springing up here and there to provide clear, simple, and compelling explanations of complex information. On the other side of the world, in the UK, an enterprise architect named Martin Sykes had begun his own journey, around the same time as I had. Big difference: he didn’t give up.
If you ever get a chance to meet Martin, you will enjoy his company immensely, just as I do. Martin is clever, thoughtful, easy-going, and funny. He’s a systems-thinker and an excellent speaker. Martin was also influenced by Tufte, but he continued on to find many other authors and designers who were publishing and writing about this new way of doing things. Martin started creating his own single page explanations of otherwise complex information, building up his skills and collecting techniques along the way. And, Martin took the time to learn how to draw. That didn’t hurt.
I met Martin Sykes through a mutual friend, Gabriel Morgan. Gabriel had joined the Enterprise Architecture team in Microsoft IT just a few months after I did, but he came to the practice from his work as a consultant using Microsoft Motion (later renamed Microsoft Services Business Architecture or MSBA). Gabriel had met Martin a few times, and had seen some of the visualizations that Martin used to explain business architecture. Gabriel worked with Martin to set up a workshop, for our team, to learn some of these skills. And in late October of 2007, Martin flew to Redmond and spent a week teaching us how to “tell stories” using a series of visual metaphors. At the time, he called them “Big Pictures” but that thinking evolved and we now refer to these creations as “visual stories”.
Can we do this again?
During Martin’s workshop, each of us created a visual representation of some idea or story we wanted to tell. Martin had distilled his own personal techniques into a FIVE DAY COURSE on creating visual stories. He walked us through ample examples, storytelling exercises, and a fairly simple process that he used to create visual stories. I created two visual stories in that class, one of which Martin still uses today… as an example of what NOT to do in a visual story!
The five day class happened once. Over the next few years Martin did four one day classes at different companies where he had been asked specifically to do more following a series of 90-minute presentations he had done at internal and external conferences. But the ideas were not “catching fire”, in large part because Martin was just happy to use what he was learning and focus on his day job of making change happen.
Meanwhile, I kept using his materials, and referred often to the binder full of PowerPoint slides that he provided. I practiced a few times more, and then stumbled into success. I created a visual story to explain an enterprise architecture roadmap to the Vice President of Operations. I presented the one page visual, and the meeting went fairly well. We got the sponsorship we needed. What I didn’t discover until later: that same Vice President took my one-page presentation and gave it to Steve Ballmer, CEO of Microsoft and one of the most powerful businessmen in the world, to explain how Microsoft’s Operations Division was attacking a key problem within the company.
That single page told a story. It was not a bunch of data. It was not a bunch of clever graphics. There was no hand-drawn art. It was a careful construction created using Martin’s techniques, and it changed my career. I was promoted and over time, I was leading a team. I wanted to bring Martin back to our group to do another one of these fantastic workshops, so that more of us could learn his techniques. I was willing to teach it myself if I had to.
A book is born
My goal was to put on a workshop for the entire Enterprise Architecture team within Microsoft IT. I reached out to Martin and asked if he had ever updated those PowerPoint slides. Thus began a series of meetings that morphed into a book proposal. We planned to create something visually interesting, to use our own ideas to tell the story of how use these ideas. Martin reached out to a friend of his, Mark West, a talented artist and designer that had worked with Martin on creating some of his training materials. Mark was familiar with the process because Mark had lived it. And he can draw. (I’m understating rather wildly. Mark has spent time as an art instructor at a college in Seattle, in addition to running his own design firm. Mark is a change agent who masquerades as a very cool designer.)
During those early days, we simplified and clarified the process of creating a visual story, and we called it “CAST.” CAST is an acronym for “Content, Audience, Story, Tell” which are the four stages of the process. We created a simple “canvas” that anyone can use. During this past year, Martin has put together a couple of workshops in other parts of the company and has used them to work out the bugs. We call this canvas the “CAST model” and I have completely adopted it. It’s like a simple visual checklist that helps you remember and iterate through the steps to creating a visual story.
We still haven’t done that workshop for Microsoft IT. We decided to create a book that we could both use to teach anyone we wanted. We decided to focus on using these skills to simplify the process itself, and to make it easy for folks who, like me, are not artists. Note: in a professional setting, on projects that are funded to create compelling information, I strongly recommend enlisting the help of a visual designer… but for your own use, to explain your own information, you can follow the CAST process to do the trick. Just like I did.
The long slog
Anyone who walks the road from idea to a complete book knows that it can be a difficult and time-consuming effort. We had our moments when each of us thought that this whole thing was nuts. After all, there were so many good books already on business storytelling and good design principles. Couldn’t someone just read those books?
They could, but what I got from Martin, in that workshop in 2007, was not in any of those books. Martin didn’t change my career with a collection of art tricks and bits from a dozen books. What Martin gave me, and what we wanted to give our readers, is a simple step-by-step process that a non-designer could follow to create a USEFUL and COMPELLING single-page visualization. Not high art. High value.
We knew we had something unique… something that none of the other books and authors and workshops had built. We had something that the non-artists among us could use to be compelling and useful. We had a book about change, and making change happen. We had a book about stories, and using those stories to drive big changes, huge changes… using those stories to MOVE MOUNTAINS.
Most of the text was written between November of 2011 and May of 2012. Most of the artwork that infuses this book, on every single page, was created in the spring and summer of 2012. The book is compelling and visually beautiful. We treated every single pair of pages as a two-page layout, and each was hand constructed by Mark West. Our publisher, Wiley and Sons, created a new team, with about twice the normal book staff, just to assemble it. Wiley knew we had something unique, and they were willing to take a real risk on it. Our team at Wiley did a fantastic job. I’ve been a co-author before, but never had an experience anything like this one. The level of communication, collaboration, and shared iterative design was simply unprecedented. The Wiley team moved a mountain as well.
Sample of a two-page spread used in the book Stories That Move Mountains
What you will get out of this book
In case it’s not clear already, we want this book to be practical and useful. This is NOT an art book, even though there is one chapter that focuses on detailed visual elements like fonts, colors and layouts. This is not a typical business book either. There are no long expositions on financials or sales strategy or performance measurement. This is a book about change, and it is for ANYONE that wants to influence another person to lead a change.
What you will get out of this book is a step-by-step process to follow that results in a visual story. We walk you through numerous examples, showing how we use the CAST stages to create visual stories and there is a final chapter that literally goes end-to-end in creating another visual story. We provide advice, and hugely valuable nuggets from a dozen other books that fill out shelves in mine and Martin’s and Mark’s libraries.
Our references chapter is also a simple, clear, layout that focuses on a small and manageable list of excellent books for you to use if you want to “go deep” on any part of the process (you won’t have to, but just in case you want to). We are also committed to continuing the conversation on the book sister-site http://StoriesThatMoveMountains.com where all three of us blog and upload resources (including a downloadable CAST model template, like the one on the right). You can also find us on Facebook for a more socially-oriented conversation (www.facebook.com/storiesthatmovemountains) as well.
It should come as no surprise that both Martin and I are Enterprise Architects. The biggest value we offer our clients is helping them to build the case for change. But change can be anything. You could be changing a business, or a team, or a family, or even yourself. You can create a visual story for nearly any situation where you want people to remember, and connect, with your case for change.
Yep, it still works
I’ll give you an interesting example. I am currently volunteering my time to a professional organization called the “Center for the Advancement of the Enterprise Architecture Profession” (or CAEAP, pronounced “seep”). Through that organization, I have been assigned, by CAEAP, to work with another professional organization that they partner with: the “Federation of Enterprise Architecture Professional Organizations” (or FEAPO, pronounced “FEE-poe”). I’m working on creating an industry-wide perspective on Enterprise Architecture. I went to a FEAPO meeting just last weekend where I was working with people, in person, that I’ve only met one time before. They were all aware of my project, of course, but it was not, and is not, their primary focus. I couldn’t be sure that they remembered anything from the last time we’d met, in February. I decided to use a visual story to frame what would have otherwise been a boring status update.
On the plane flight from Seattle to Fort Lauderdale (five hours in coach, on a red-eye overnight flight), I filled out the CAST model and created the entire presentation. (I had no internet access on the plane, so the graphic images I used were all on my PC hard drive). The moment I landed, I drove to FedEx Kinkos, printed the visual story on nice, sturdy, 11x17 paper, and drove straight to the 8:30am meeting. When it came time to present, I handed out the sheets and we turned away from our screens and spoke to each other instead.
Later that evening, as we sat eating dinner at an upscale Surf-and-Turf restaurant, they were reciting back to me the humorous bits of the story that I told. The story stuck. It was memorable. As a result, everyone has a good idea of what I need from them, and what they need from me, because we had a simple compelling visual story to work from. (I’ll see if I can get a link to that document made available so that you, gentle reader, can see it. A thumbnail is on the right).
So yes, I think you should buy this book. I’d say that even if I didn’t help write it, but I did. This is our way of saying: it’s time to change the world. This is our mountain to move. Join us. The world needs change agents to be effective. You are a change agent. If we help you become just 5% more effective, what hurdles will you overcome? What innovations will you introduce? What problems will you solve?
These are interesting times.
A recent experience with poor customer service has got me thinking about the role of EA in addressing customer experience issues.
One of the last things I was working on, while still in Microsoft IT, was working on an initiative to systematically help improve customer experience. With that experience fresh in mind, I was dealing with an issue with my Tivo DVR today where the Tivo box started to misbehave. I began a chat with their representative and the experience was less than ideal. (If someone from Tivo wants to chat, just drop me a line for details).
That got me thinking. Can EA help? In general, can EA be part of the solution to problems caused by poor customer experiences?
First off, I’d like to say that customer experience is one of the most important elements of the highly competitive online world. The Web has made it very easy for customers to abandon their existing relationships and switch to new ones. Even the slightest provocation can send a customer in search of a competitor, and the features of a product are not as “sticky” as they once were. It is increasingly easy for new small companies to appear that copy all of the key features of a technology and release a competing product, sometimes within a few months of the first one. The results can be fierce competition that, unfortunately, is often addressed in courtrooms instead of the marketplace (Samsung vs. Apple, Google vs. Microsoft, Apple vs. Microsoft, etc.).
Some companies will not pay proper attention to their customer’s experience. This is fairly common, especially in manufacturing companies where there are both software and hardware components involved. For some reason, the fact that two different engineering teams are involved often produces a disjointed experience. (Apple has been leading the way in addressing these kinds of problems. The rest of us need to do so as well).
In general, an Enterprise Architect assists with the development of strategic alignment, not by deciding what is important, but making sure that executives don’t miss the important stuff while they are overwhelmed with the mundane. One way to anchor your analysis to ensure that YOU don’t miss the important stuff is to consider some of the high level tools suggested in traditional strategic analysis… tools like SWOT analysis, Five Forces analysis, and partner accountability mapping. However, most of those tools do a poor job of considering the importance of customer experience to enterprise success.
The model that I use is the EA metamodel behind business models. In a prior post, I created a rationalized ontology for the business model canvas that addressed the gaps left by Osterwalder in his analysis. However, in keeping with the effort to make that kind of model useful, I followed the pattern of Osterwalder and created a visual table that represented the corrected business model ontology.
The guidance that you can get from this is to look at each of the blocks in the canvas and consider the possibility that you have not missed anything important in that block. Therefore, if you use this model, you would ask the following ten questions:
This list of questions includes the core questions that we need to be asking in order to address customer experience issues at the strategic level. This is a far more comprehensive list that “5 forces” or “SWOT” and will help you to ensure that you are not missing anything.
The actual experience of a customer is a function of their needs and your products. If a customer needs to drive a nail, a hammer will do. If the customer needs to drive their car to an unfamiliar place, then a Global Positioning System with turn-by-turn directions would be more compelling. If you offer the customer a product that does NOT meet their needs (like a GPS that only shows maps, but doesn’t tell the driver where and when to turn), then they will not be loyal to the product. Their experience will be poor and they will quickly find better products.
Customers don’t want ten inch drills. They want ten inch holes.
Customers don’t want ten inch drills. They want ten inch holes.
When doing a strategy workshop, it is best for the Enterprise Architect to walk in to the workshop with all their preparation in place. Walking in unprepared will produce really poor results. To be prepared, the Enterprise Architect will have already collected the list of “proposed strategies” for the coming period and will have analyzed those strategies from the standpoint of the organization’s business model(s). In other words, for each of the questions above, which ones are being answered by strategy. Now, for the kicker, which ones are not?
Customer experience may already be covered by a strategy, and if it is, you have to do very little. Simply make sure that everyone sees the relative value of that strategy when compared to others (like reducing costs or negotiating new boundaries with existing partners). That is not simple, but not as difficult as the alternative: no strategy for customer experience.
On the other hand, let’s assume that there are goals, or objectives, or themes (rarely actual strategies) already articulated that address the other areas of business model considerations, like costs, or products, or partners. Address the lack of customer focus in your interviews PRIOR to the strategic workshop. Ask your key stakeholders what their customers need. Specifically don’t ask for how those needs are being met… ask what the needs are! Make sure that you plant, in the minds of your stakeholders, the seeds of doubt: do we KNOW what our customers want and need? Is it written down? Would our customers agree with what we wrote down?
During the workshop, propose an initiative to capture the needs of the customers (of each business model) and to map the products and services to those needs. This will let you answer the question: are our products and services meeting the needs of customers? This may involve the development of user personas, scenarios, and competitive surveys. This initiative, when complete, will provide the ammunition that you will need later to propose initiatives to address customer experience gaps.
Note that gaps can exist in many places… not just in the products themselves, but also in the customer service experience that occurs when customers are not happy with their products or have an issue with them.
Enterprise Architecture is a strategic planning function that uses a methodical scientific approach to address the gaps between the goals of a business and the execution of strategy needed to reach them. Using the TEN STRATEGIC QUESTIONS above, Enterprise Architects can capture opportunities and oversights that senior executives may miss. One of those key questions addresses customer experience issues.
Therefore, when an organization fails to deliver good customer experiences, Enterprise Architecture, when used properly, can help to address the situation.