Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

Posts
  • Inside Architecture

    All Effective Enterprise Architects Are Agile

    • 7 Comments

    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.

    • A focus on performing high-value activities, and removing low-value activities.
    • A focus on empowering the people who make things to make decisions about how those things should be made.
    • A focus on developing small increments of actual value on a frequent basis and getting direct feedback on them.
    • A focus on making sure that one thing is “done” before moving to the next, so that we reduce “debt” as we go.
    • A focus on modern practices that remove ‘deployment impedance’ like test driven development and continuous integration.

    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.

    image

    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:

    • do the work that is highly valuable and don’t do the work that the business doesn’t value
    • build consensus where it actually lives, not where the “people from above” believe that it does
    • deliver value quickly and in increments that your stakeholders understand
    • leave your repository in a good state of completeness with all the data that others need to use it
    • build in the deliverable artifacts into the business processes that need it, so that you get immediate feedback

    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.

  • Inside Architecture

    The most important personality trait of an Enterprise Architect

    • 4 Comments

    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.

    Philosopher and author Roman Krznaric explains how we can help drive social change by stepping outside ourselves.

    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. 

    • Autonomy – the desire to direct our own lives, 
    • Mastery – the desire to get better and better at something that matters, and
    • Purpose – the yearning to serve a greater goal.

     

    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.

  • Inside Architecture

    Steps To Create a Core Diagram

    • 0 Comments

    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

    1. Collect a list of your organization’s business models
    2. Create or leverage a taxonomy of capabilities that reflect differentiation in business processes
    3. Differentiate each capability on the basis of Ross’ operating model taxonomy (level of Information Integration and level of Process standardization)
    4. Make an educated guess about the operating model of the company
    5. Draw the core diagram and build understanding around it

     

    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)

    Metamodel for a Business Model

    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.

    Diagram illustrating the dimensions of Operating Models with Integration (low and high) on the Y axis, and Standardization (low and high) on the X axis

    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.

  • Inside Architecture

    Everything you’ve read about IT Project Failure is wrong

    • 8 Comments

    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!

    image

    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:

    1. Lack of accountability for success – Sometimes, in an organization, an interesting situation will arise.  I call this the “can’t lose” scenario.  In this scenario, the CIO will suggest that the business can benefit by doing some particular initiative, and his or her people will set out to find a business sponsor for the initiative.  In this case, the sponsor will reap the benefits of the initiative, not the CIO.  (Let’s say that the CIO has suggested a Business Intelligence initiative, and signs up the Chief Marketing Officer to sponsor it).  If the project succeeds, the sponsor wins.  If the project fails, the CIO (not the sponsor) loses credibility.  After all, it wasn’t the sponsor’s idea.  The CIO dreamed it up, after all.  In fact, the sponsor may not do any real “sponsoring.”  He may sit in an occasional status meeting and check his e-mail while the program manager he assigned from his team answers questions… and keeps him protected from any blowback.  The sponsor in this case is not accountable for success.  No one is.  The odds of this project succeeding are small.  (Note: a good IT Governance system prevents this condition). 
       
    2. Failure to get buy-in from above – Often, a senior executive will ask his operational leaders to suggest IT projects for the planning cycle.  The executive (let’s say Tina Smith, Vice President of Sales) assumes that the leaders (William, Ashok, and Lee: all three are General Managers) will ask for projects that align to their individual strategic needs.  One of those General Managers, William, decides to create an IT project to implement a SOA service bus.  He wants the bus because he is investing in replacing an application and his IT team tells him that a bus is a good idea.  After all, if everyone in the Sales group uses it, everyone will benefit.  But William doesn’t get Tina Smith’s buy in.  He implements his SOA service bus, but when subsequent IT funding requests come up to move other sales applications over to the bus, his peers Ashok and Lee are not interested.  Their priorities don’t include moving to the bus.  William bought a white elephant.  Because he didn’t get Tina’s buy in, none of his peers will reap the benefits.  Is the SOA bus a failure?  Well… it’s not a success.
       
    3. Misaligned prioritization – Lee James, General Manager of Sales for the Western region of Contoso owns a sales strategy for the enterprise.  The strategy is to make the sales force more productive by moving the company over to a new CRM system.  The CRM system has out-of-the-box support for a long list of reports, but his team tells him that he shouldn’t use those.  Instead, he should put in a Business Intelligence system in the cloud.  Lee wants to trust his team to pick the right solution.  They tell him that the cost of this system is $4 Million over two years.  The company is moving to a new strategy that de-emphasizes the direct sales force.  Instead, the company will be relying on social networking and direct eRetail to make sales.  To make the new strategy work, there are eight projects totally $8 Million that need funding.  There is a competition for dollars in the IT budget.  Lee goes to bat for his $4 Million commitment.  It’s important because “we are already here, so we have to complete the job.”  This is an example of misaligned priority.  The new BI project can be safely cancelled or scaled WAY back to support a strategy elsewhere, but that other strategy doesn’t belong to Lee.  The one that he owns needs money and he’s going to keep fighting to fund it because his boss, Tina Smith, isn’t aware of the tradeoff.  Lee fights, and Contoso loses.  Which project will fail?  Both of them.
       
    4. Slow decision making – This one is related to the other problems in that it is often, but not always, caused by a poor governance system or poor prioritization of the effort.  In this scenario, the team implementing the project needs the sponsor to make a decision, often one that requires consultation with his or her peers or counterparts in another part of the company.  The sponsor may be unwilling, unable, or incapable of having a difficult conversation.  On the other hand, they may be indecisive.  Regardless, this situation can cause serious delays in a project.  For example, Ashwin’s application sends EDI-formatted messages to a health insurance provider.  The provider had indicated that new fields are allowed in the messages that are very valuable to Ashwin’s line of business.  However, he has to upgrade his EDI translation software to get the new fields.  The EDI translation software is also used by the Finance group to send banking transactions.  Ashwin knows that the finance group will get a benefit out of the upgrade and wants them to help cover the costs.  This upgrade will add $25,000 to the cost of his project and he’s on a tight budget.  The software team offers to write a small component that will insert the fields into the data stream, but its complicated and fragile. Ashwin cannot decide if he should ask the finance team for funding or if he should upgrade the software.  The project team cannot proceed without a decision. 
       
    5. Lack of authority to drive change – This one is quite common.  Ashok reports to Tina Smith, VP of Sales for IBuySpy.  He has told her that he wants to take the lead on one of her strategies: to consolidate all of the eCommerce systems in the company to a single outsourced vendor.  Tina things that this will reduce costs all around, and Ashok is happy to take on the challenge.  His business analyst does a survey and it turns out that the services and support team offers customers the right to buy replacement parts online.  In addition, the “outside services” team allows customers to buy a service contract on their own area of the website.  The main sales site, of course, uses a high-volume low-cost vendor that Ashok is comfortable with.  Ashok sets up meetings with the owners of the other applications, but they choose not to provide the needed transaction cost information or the cost estimates of changing their internal systems.  His data is light but he strongly suspects that there is a good business case for switching.  Unfortunately, he doesn’t have the data to prove it.  Without data, the Tina won’t take the case to the CEO to require the other teams to jump onboard.  The strategy fails.  Neither Ashok, nor his manager Tina, have the authority to require their peers to adopt a lower cost system.
       
    6. Lack of influence to rally peers – In many organizations, the prevailing attitude is that the boundary between “centralized” services and “federated” services is intentionally fuzzy.  In these companies, there is no policy that requires a function to be centralized vs. federated.  For example, if a company has ten divisions, three may have their own financial processes, while the other seven share a common finance unit.  The decision to use the central finance unit, or to own a federated unit, can be made and unmade depending on who the leaders of the business are.  (Note: leaders change, and with them, these decisions change as well).  This kind of policy is good for flexibility, but creates both inefficiencies and often, confusion.  This is simply a tradeoff in the design of organizations.  It is neither right nor wrong.  In this environment, any business can create a “centralized” function by convincing more than one business leader to come together to create a shared resource.   The flaw comes when a group wants to create a “centralized” (or simply “shared”) function, but they lack the influence needed to get multiple businesses to join the initiative.  Difficult questions of shared funding can be demotivating, and the political need to create “alliances” can be difficult for junior executives that, in many ways, are competing with one another for the next rung on the career ladder.

     

    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.

  • Inside Architecture

    The Story behind “Stories That Move Mountains”

    • 5 Comments

    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

    book_cover_image_sm

    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).

    Visual Explanations: Images and Quantities, Evidence and NarrativeAt 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. 

    Beyond Bullet Points: Using Microsoft PowerPoint to Create Presentations that Inform, Motivate, and Inspire (Business Skills) (English and English Edition)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?

    imageDuring 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. 

    image

    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. 

    imageOur 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. 

    imageOn 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. 

  • Inside Architecture

    Is Enterprise Architecture accountable for improving customer experience?

    • 2 Comments

    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? 

    The Official Dilbert Website featuring Scott Adams Dilbert strips, animations and more

    Customer Services is important to the success of any organization

    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).

    What are the questions you must always be ready to answer?  (The Ten Strategic Questions)

    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.

    image

    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:

    • Are we targeting the right customers for the growth that we need?  (Customer Profile)
    • Do we have a good understanding of what our customers want and need? (VOC)
    • Do we have a compelling value proposition to address the needs and demands of those customers? (Value Proposition)
    • Are we developing products and services that deliver on our value proposition, or is there a gap in our products and/or services that we need to address? (Products and Services)
    • Have we considered all of the channels we should be using, or are we using too many channels, to distribute our products and services to our customers? (Channels)
    • Do we have a good idea of the resources we need to deliver on our value proposition? (Resources)
    • Do we know how to use our resources sufficiently well to produce the results that customers expect? (Required Competencies)
    • Have we addressed all the cost and revenue implications of the resources, competencies, and channels that we’ve selected? (Cost and Revenue Models)
    • Are we reaching our customers in the geographies and locales in which they live and work, and if not, why not? (Geographies and Locales)
    • Have we relied on partners in the right way, leveraging their strengths and the cost implications of using them without opening ourselves to problems of key dependencies? (partner profiles)

    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. 

    How does Enterprise Architecture address customer experience?

    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.

    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. 

    Conclusion

    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.

Page 6 of 106 (631 items) «45678»