Inside Architecture

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

Posts
  • 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”

    • 3 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.

  • Inside Architecture

    Many (flawed) Definitions of Business Architecture

    • 6 Comments

    Not long ago, I attempted to create a refined definition of “business architecture.”  I felt compelled to do so because the definition that I found in the Business Architecture Guild’s BizBOK (Guide to the Business Architecture Body of Knowledge) defined the word “business architecture” in terms of an artifact (a thing).  In my eyes, that "thing" already had a name, and creating a new name for an old thing, while forgetting the practice that creates part of it, seemed like a mistake.

    Literally, within minutes of posting a question on LinkedIn about my definition, I found that there had already been a raging debate about the definition of the term “Business Architecture.”  (egg on my face).  So I went through that other discussion and picked up the various definitions I found there.  I also scanned the web looking for additional definitions, and found a few. 

    The list of definitions that I found is copied here.  Note that, at the bottom of this post, I will make some observations about these entries and what it says about the maturity of our definitions.  If you’d like to skip the list of definitions, I encourage you to scroll down and look for the analysis.  The surprising conclusion (I’ll spoil the surprise) is that every one of them is flawed, including mine.  Read on.

    List of definitions of business architecture

    Below is a list of various definitions of business architecture, drawn from a LinkedIn Discussion in the Business Architecture Community, started by Terry Roach.  This list was extracted from LinkedIn on September 9th, 2012.  In addition to the discussion on LinkedIn, I searched the Internet (using Bing, of course) to find additional definitions.  Note that if a definition is cited in multiple locations, it appears in the table below only once, citing the original source.

    For each definition, I captured its source and two attributes of the definition: the scope and the perspective.

    Scope: The definitions tend to vary about whether they describe one or more of these three aspects of business architecture:

    • Contents – Treats Business Architecture as a noun and describes the contents of it.
    • Purpose – Describes the reason for either performing or creating a business architecture.
    • Activities – Describes some of the activities that intersect the performance of, or management of, business architecture.

    Perspective: Each definition takes one of these two perspectives: Either Business Architecture is a thing or a process.   

    Who

    Scope

    Perspective

    Text

    Terry Roach

    Contents

    Thing

    "A business architecture articulates organisational objectives and associated strategies in a conceptual model of the domain, the behaviour and the governance of business operations. "

    Bruce McNaughton

    Contents

    Thing

    "The business strategy, governance, organization, and key business process information, as well as the interaction among these concepts." (derived from TOGAF)

    Sunil Muduli

    Contents, Activities

    Process

    Business Architecture is about Modeling/Capturing Business Motivation, Capability, Process (Level 0 & 1) and People(Role/Responsibility)

    Rubina Polovina

    Contents, Purpose

    Thing

    Business Architecture—A model of real-world that contains discourse relevant for an IT-intensive endeavor (or, simply, IT endeavor)

    OMG Business Architecture Group

    Contents, Purpose

    Thing

    a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands. (Bizbok 2.1)

    Tim Blaxall

    Purpose, Activities

    Process

    Business Architecture helps to implement our business strategy by designing the developments needed in the way our business operates

    The Open Group Architecture Framework [TOGAF]

    Contents

    Thing

    Overview: The Business Architecture defines the business strategy, governance, organization, and key business processes.

    Definition: A description of the structure and interaction between the business strategy, organization, functions, business processes, and information needs. (TOGAF 9.1, Section 3.22)

    Taurai Christopher Ushewokunze

    Activities

    Process

    Business Architecture is the process of planning, designing and implementing macro level to micro level business structures at a minimum it defines the relationships between finance, marketing, operations and technology.

    Nick Ananin

    Activities

    Process

    Business Architecture is the process and outcomes of planning, designing and building a system that delivers tradable products (goods, services etc) that are of value to customers.

    /Also/

    Definition of Business Architecture = "An architecture applied to a business system".

    Michael Poulin

    Contents

    Thing

    Enterprise Business Architecture is architecture that comprises business functionality and business informational models, positions itself across business administrative and organisational enterprise structures, and that transforms goals and objectives defined in a business enterprise model and refined in the Strategic Business Plans into the functional and informational definition for a corporate business

    Joanne Dong

    Contents, Purpose

    Thing

    Business Architecture is a holistic set of descriptive representations of the different components of the business and their relationships. The purpose of a business architecture is to ensure proper alignments and integration among the components.

    Ralph Whittle

    Contents

    Thing

    Informal: the Business Architecture is a blueprint of the enterprise built using architectural disciplines to improve performance.

    Formal: The Business Architecture defines the enterprise value streams and their relationships to all external entities, other enterprise value streams, and the events that trigger instantiation. It is a definition of what the enterprise must produce to satisfy its customers, compete in a market, deal with its suppliers, sustain operations, and care for its employees. (Source)

    Tim Manning

    Activities, Purpose

    Process

    Business Architecture is a discipline and set of methods for the holistic design of organisations. The architecture of a business is “the arrangement of the functions and features that achieve a given set of business objectives” (adapted from King, 2010).

    Sam Holcman

    Purpose, Activities

    Process

    Business Architecture is explicitly representing an organization’s desired state and as-is state, through a set of independent, non-redundant artifacts, defining how these artifacts relate with each other, and developing a set of prioritized, aligned capabilities needed to meet the organization’s goals, communicating this understanding to stakeholders, and advancing the organization from its as-is state to its desired state. (BACOE, EACOE)

    Nick Malik

    Activities, Purpose

    Process

    Formal: Business Architecture is
    (1.) 1. A specialization of the Enterprise Architecture business function that collects and manages functional, structural, and motivation-related information using a rigorous scientific and engineered approach for the purposes of business design, functional improvement, motivational alignment and decision support.
    (2.) One of the four traditional domains of Enterprise Architecture.
    Informal: Business Architecture -- A specialization of the Enterprise Architecture business function that uses science and engineering to design and implement business functional and process improvements and strategically-aligned change initiatives.

    Derek Miers (Forrester)

    Activities, Purpose

    Process

    An organized and repeatable approach to describe and analyze an organization’s business and operating models to support a wide variety of organizational change purposes; from cost reduction and restructuring, to process change and transformation.

    Art Caston (as cited by Dave Woods)

    Activities, Purpose

    Process

    Business Architecture supports business opportunity assessments, strategy development, and business transformation program planning by creating various business reference models, populating these reference models with current business information, and creating integrated target architecture models to show future market positioning, product and service capabilities, enterprise structure and responsibilities, and proposed business partner relationships. These target models are used by related business planning functions to structure, organize, and govern related transformation programs.

    IASA (as cited by Kevin in comments below)

     Contents

     Thing

    A business architecture is a part of an enterprise architecture related to architectural organization of business, and the documents and diagrams that describe that architectural organization.

    Ben Gray

    Contents, Purpose

    Thing

    A business architecture [noun] helps a client (the business owner/director) to better understand the landscape (business environment, context, or market); understand their choices and constraints; and articulate their vision (requirements) such that designers (of processes, roles, systems, apps, etc) can create a coherent set of artefacts that can be used to plan and build/buy and test against

     

    Analysis of the definitions of business architecture

    The first thing to notice is that there are PLENTY of definitions of business architecture.  I have listed seventeen (20) definitions above from seventeen (17) people.  If I find more definitions, I may add them to the list, but I probably won’t update the numbers in the analysis below (too much hassle).   It is interesting to note that very few of the respondents referred to a pre-existing definition from a reliable source (like TOGAF, OMG, or Forrester). 

    I did a little categorizing as I went, and you can see that effort in the table above.  The reason for doing the categorizing is to understand what the community considered important to include in a definition.  Think about that for a minute.  A definition captures the important distinctions of a concept, sufficient to clearly differentiate that concept from other, potentially similar, ones.  Definitions “should” be minimal, but they don’t have to be.  The folks who contributed were not trying to make a perfect definition.  They were trying to provide all the information that they found important.  So let’s look at what the contributors found important.  Of the 20 definitions provided, the numbers were VERY evenly split…

    Definitions Containing Activities Purpose Contents
      10 10 11

    As for the other attribute, it highly correlated to the numbers above.  Everyone who described business architecture in terms of “activities” was describing a process.  All other definitions described a thing.  The number of definitions was EVENLY SPLIT between the two.

    Definitions describing a Process a Thing
      10 10

    (Note: Sunil described the process of capturing contents without describing where those contents would go.  Therefore, his definition described activities and contents, but still described a process.  Hence, the number of definitions describing contents does not equal the number that describe business architecture as a “thing”)

    What can we draw from this: of the respondents to that thread on LinkedIn, and from various sources around the Internet, there is NO CONSENSUS on whether business architecture is a process or a thing. 

    Since a definition describes how a word is used, and is NOT a reflection on what we want it to mean, and given that 20 different definitions submitted describe the term in two different ways… I would consider it likely that the term is used in both ways (both as a process and as a thing). 

    Next Steps

    Assuming that my analysis is correct, EVERY SINGLE DEFINITION ABOVE IS WRONG (including mine).  All of them define business architecture in terms of either a process or a thing.  Not one define the term to have two meanings.  Yet the term ‘business architecture’ clearly has two meanings!

    My suggestion to the reliable sources for the definition of business architecture: update your definition to include both sides of this coin.  I will do the same.  Note that I will not update the numbers in the analysis to reflect that change. 

  • Inside Architecture

    Taking a Careful Slice – Defining Business Architecture

    • 16 Comments

    I’m putting together my presentations for TechEd New Zealand, one of which is titled “Business Architecture for Non Architects.”  In that presentation, I need to provide a good, SHORT, definition of business architecture.  So, like a good soldier, I marched over to the Business Architecture Guild and dug in to the Business Architecture Body of Knowledge (the “BizBOK”), which defines Business Architect in this way.

    “A blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands”
    – Business Architecture Body of Knowledge Handbook 2.1, Business Architecture Guild

    I copied this definition into my deck and went on.  Then, as I came back and practiced the presentation, I hit this slide and realized, to my horror, that I do not think this is a very good definition.  Why?  Because of the problem of two parallel phrases: business architecture, and business architect.

    Is the business architect responsible for describing the business architecture?

    Here’s the problem with the BizBOK definition...  The field of Enterprise Architecture clearly includes four domains: business architecture being one of them.  Enterprise Architecture is accountable for creating a complete description of the enterprise, useful for many things.  One of those things is for the alignment of strategic objectives and tactical demands.  Therefore, to use the “model, viewpoint, view” language of the ISO 42010 standard definition of architecture, we would say

      • Model == Enterprise Architecture
      • Viewpoint == Concerns of Business Stakeholders
      • View == Business oriented architectural artifacts


    Therefore, the “blueprint of the enterprise,” is the Enterprise Architecture.  There is no distinction between the “architecture of the enterprise” and the “blueprint of the enterprise.”  These concepts are identical.

    Who creates the Enterprise Architecture?  All of the domains do.  Business Architects contribute, but so do Information Architects, Application or Solution Architects, and Technology Architects.  Non architects contribute as well, including process engineers, sales managers, product managers, relationship managers, and others.  A few business architects are involved.  In most organizations I’ve had contact with, business architects do not lead the effort to create the enterprise architecture. 

    Conclusion: the BizBOK 2.1 defines the concept of “business architecture” in terms of an artifact that business architects do not create!  That seems a bit exuberant.  It’s a little like saying that “bricklaying is the act of building a house out of bricks.”  Um… no it isn’t. 

    What is the role of the business architect?

    A Business Architect is one of the four well-defined “domain” architects under Enterprise Architecture.  The other three are: Information Architect, Solution or Application Architect, and Technology Architect.  These different domains are supposed to represent “layers” in an outdated model.  While I reject the entire notion of “layers” or “tiers,” I understand that these terms have become embedded in business over the last two decades.

    I’m on the fence about the value of even employing “domain-specific” architects, especially in smaller firms or at the program level.  I believe that, in many cases, a good generalist Enterprise Architect is probably the most effective use of resources and training.  That said, I understand that many large organizations have created specializations around each of the domains, with some folks being “Information Architects” only, and others as “Business Architects.”  I even wrote a job description of a business architect a number of years back that proves popular today.

    That said, as we define the “activity” of business architecture, I believe we should remain clear that business architecture is an application of enterprise architecture… a careful slice of general EA skills with a focus on meeting the needs of only one of many levels of the architecture.  That level, the business level, meets the needs of different stakeholder groups (multiple business viewpoints) like strategy development, strategic alignment, process improvement, innovation management, and organizational development.  But the business viewpoints are deeply integrated into the unified model of the enterprise, one that is not complete or effective without the viewpoints of the other domains.

    The role of the business architect is therefore to develop specific architectural artifacts needed to meet the concerns of business stakeholders.  Those artifacts are derived from the model of the enterprise (the enterprise architecture) which evolves as they go.  Many experts suggest (and I agree) that it does not make sense to develop the EA model as a standalone artifact, but rather to develop the parts of it that are needed to meet immediate concerns, use the model to meet those concerns, and move on to the next concern, building the enterprise architecture model as you go.   This iterative approach works well and keeps enterprise architects out of the proverbial “ivory tower.”

    Clearly the concerns of the business stakeholders include “aligning the strategic and tactical demands” of the enterprise.  I would not LIMIT the scope of enterprise architecture to this one concern.   This is the other problem I have with the BizBOK definition… it is limited to alignment only.  Perhaps that was intentional.  I have not asked.  But it is clearly limiting.

    How does that role affect the definition?

    A couple of years ago, I defined Enterprise Architecture as a single term with three definitions.  (That’s pretty normal, if you think about it).  One of the definitions was “A rigorous model of the motivations, structures, information, processes, and systems of an enterprise created for the purpose of decision support.” 

    [Updated 11 Sept 12] That model is the enterprise architecture.  Therefore, in order to create a non-overlapping and complementary definition for business architecture, I wanted to remove the artifact from the definition.  However, clearly some members of the community used the term "business architecture" to refer to part of that model.  So I left in the notion of an artifact, but defined it as a subset of the larger enterprise architecture artifact.   

    [Updated, 5 Sept 12] I am considering two "definitions" at this time.  One is a full definition that provides the necessary and sufficient differentation needed to create a reasonable understanding of the term.  The other is a shorter definition useful in a business context. 

    The definition I’m considering at this time is:

    Business Architecture is

    1. A specialization of the Enterprise Architecture business function that collects and manages functional, structural, and motivation-related information using a rigorous scientific and engineered approach for the purposes of business design, functional improvement, motivational alignment and decision support. [Updated, 5 Sept 12] 

     

    2. A subset of the architectural description of an enterprise sufficient to produce models that meet the functional, motivational, and alignment concerns of stakeholders. [Updated 11 Sept 12]

    And the short, "useful" definition is this:

    Business Architecture -- A specialization of the Enterprise Architecture business function that uses science and engineering to design and implement business functional and process improvements and strategically-aligned change initiatives.  [Updated, 5 Sept 12]

    There it is… a careful slice.  I look forward to your (continued) feedback. 

  • Inside Architecture

    Podcast on the Enterprise Architecture profession–Interview with CIPS’s Stephen Ibaraki

    • 0 Comments

    Way back in April, I announced the first of two podcasts with the Canadian Information Processing Society.  I just realized this weekend that I had not announced the availability of the second of those podcasts.  Error corrected.

    The second podcast, once again hosted by the inimitable Stephen Ibaraki, focuses much more on the growth and progress of the Enterprise Architecture profession itself.  Specifically this podcast reflects upon:

    • The role of Business Architecture in Enterprise Architecture?
    • Does an Enterprise Architect have to be able to discuss technical issues like cloud computing?
    • How would you define Enterprise Architecture?
    • The value proposition of the Enterprise Architect?

     

    For full details, and a link to the podcast, visit the Canadian IT Manager’s Connection, a TechNet site. 

Page 6 of 105 (628 items) «45678»