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