One of the most common mistakes that people make about Enterprise Architects is the notion that we are problem solvers. Yes, EA solves problems, but to frame EA in those terms is like saying that an ER Doctor is a bandage changer.
To help clarify the distinction between a “problem solver” and an Enterprise Architect, I will illustrate the logical argument for both, and show their differences.
The left column is what business analysis is for. It is what solution architecture is for. It is NOT what Enterprise Architecture is for. I don’t care how good you are at doing the stuff on the left. I don’t care how well it has worked for you in the past while working as an EA. The “raison d'être” of EA is not to solve well-understood problems. It exists to find out why the organization hasn’t seen the obstacles that actually prevent success, hasn’t removed them, and hasn’t figured out how to cope with them.
Five blind men describe an elephant, each in different ways. The EA is the sixth blind man. He listens to the other five and says “the problem is not that an elephant is like a fan or a rope or a wall… the problem is that it is standing in the living room, and dropping large amounts of waste on the floor. Problem solvers try to find a better way to feed the elephant and remove it’s waste. Enterprise Architects asks why everyone is standing in the same room as an elephant.
Frequently, when reading articles or books on business architecture, the following advice emerges:
Business architects start with the strategy of an organization. They take that strategy and map it to the capabilities of the enterprise to clarify the capabilities that must be improved or matured in order to effectively execute.
Business architects start with the strategy of an organization. They take that strategy and map it to the capabilities of the enterprise to clarify the capabilities that must be improved or matured in order to effectively execute.
Sure… you could do that, if you want to fail. (Before you flame me, read on.)
A business analyst may start with some bit of strategy and start hunting for capabilities… a business architect will start with a model of the enterprise, its value streams and its business models. Starting with strategy is a fool’s errand.
Because strategy is meaningful within context. It is not meaningful without context. Starting with strategy means “starting without context.”
Outside of the context of a business model (and, in some cases, value streams), business strategy is about as useful a tire swing with no tree to attach it to.
But wait, you ask, don’t management consultants say to “start with the strategy?” Yes, but it’s a trick statement: they don’t define what strategy is, so that they can start with a business model and CALL it a strategy. That’s what smart ones do. Dumb ones simply fail.
Business architects add no value if they bring analysis methods that are no more valuable than the poorly described “consulting methods” that management consultants use today. (If those methods worked, why would “alignment” be a problem?) Simple methods like SWOT and Five Forces and even Balanced Scorecards can fail catastrophically if there is no recognition of the fact that these methods are only useful within the clear and well described boundaries of a business model.
This post is a follow-up to my prior post: Business Models in Business Architecture. In that post, I discuss the fact that some business thinkers, including Osterwalder, consider business strategy to be “on top” with business models being “underneath” the strategy level. (At least, that’s what he wrote when he was a student in college.) In that ordering, Osterwalder himself was saying “start with strategy” and then to describe the business model. On this we disagree. I agree that business strategy is different from a business model. I disagree on which comes first. Depending on what you define as strategy, the business model should be on top.
[Aside: Note that some people consider “strategy” to include many of the elements that Osterwalder, and I, consider to be part of the business model. Is the value proposition and the list of products the same as the “business strategy” or the “business model?” If the strategy represents the things that need to change, in an organization, in order to achieve a mission, then the business model comes first, and the strategy comes second.]
The business model answers key questions about the INTENT of an organization. How does that organization WANT to make money or deliver value? Who does that organization WANT to reach through customer channels? How SHOULD costs be structured? How do you HOPE the partners will react? These are all wishes, but they represent the intent of the organization. A business model is the context. It is the setting for the business story.
Note that once a business is operating, there are realities in that business model. Sometimes the most important question is: are we living up to our business model?
Strategy is the action: what changes do we have to make in order to REALIZE that business model? What do we need to do differently than we are doing today in order for the business model to become reality? That is strategy. It is the action, not the destination. But action starts somewhere and travels somewhere. Strategy starts from where the business model is today, and gets an organization to where the business model SHOULD be tomorrow.
There are two possibilities, of course. Either the organization TODAY is living up to the promise of its business model, or it isn’t.
As I noted above, a business model is a declaration of intent. It includes things like “channels”, “partner relationships”, and “value propositions”. So, what if your costs are too high, or your customers don’t accept your value proposition? That means your organization is not living up to the business model. In that case, the diagram above is a little misleading. Your strategy takes you from your INTENDED business model to your REALIZED business model. (In effect, the business model is not changing… the organization is).
So what if your business is doing very well. After all, it does happen. Sometimes a business will earn the money it intended, with the cost structure it hoped for, and the business relationships it wants, along with value propositions that delights the customers. What is strategy in that case?
In this case, strategy usually reflects one of two possibilities:
The most common one is the first. Minor improvements: Increase the predictability. Reduce the risk. Cut costs. Improve customer satisfaction. Expand to a new market with an existing product. These are all incremental changes to the business model.
The second one grabs a few more headlines: adding a new business model to the organization. When Amazon decided to offer cloud services, it was adding a new business model. When Google brought out G+, it was adding a new business model. When Exxon Mobile bought a series of natural gas extraction companies, it was adding a new business model.
In that case, the executives didn’t just say “we are good, let’s stop innovating.” They pushed for something better. They defined what that something looked like with an update to the business model (or an addition to it) and then pushed the organization to achieve. How did they push? Strategy.
So, here comes the kicker… all those business architecture journals and articles that say “start with the strategy” are naïve at best, and at worst, dead wrong. Understanding the value of the business model concept means changing your practices, updating your methods, and doing something different. It means, before you look at the strategy, look at the business itself. How does it work? How is it supposed to work? What is the business model? Is the organization living up to the business model?
Only after you understand those basic questions should you consider business strategy. Only after you understand the business model does business strategy even make sense.
It still surprises me to see various discussions of business architecture where there is a poor understanding of the relationship between business models and business capabilities. The vast majority of discussions of business architecture, including books, articles, and blogs, make very little mention of business models, and nearly never discuss their relationship with business capabilities, organizations, stakeholders or resources.
To me, the concept of a business model is fundamental to using business capabilities. I cannot imagine attempting to understand a commercial organization without understanding the business models of that organization as a first step.
In this post, I will discuss the reasons why business architects must consider business models. I’ll start with some definitions to minimize confusion, given the fact that everyone has different definitions of these concepts. I’ll then discuss the concerns that I have about the lack of integration of core concepts. In a future post, I will discuss the various information models for including business models into business architecture as well as needed changes to business architecture methods (including capability analysis) in order to correctly place this role.
Caveat Emptor: The following discussion of business models will focus on commercial systems. If you are examining this space from the standpoint of a non-profit organization or government agency, your needs may not be well represented. My apologies. The reason for this will be immediately apparent when you read the definition of “business model” below.
The Business Architecture Society and the Business Architecture Guild have joined forces and created a common definition of a “business capability.” From the Business Architecture Body of Knowledge Handbook: “A business capability is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome.” Note that the BIZBOK cites Ulrich Homann as the originator of the definition. For the sake of this discussion, let’s take this definition as a given.
There are many definitions of a business model. Perhaps the most popular definition today comes from Alexander Osterwalder, author of the popular business book “Business Model Generation.” However, his book doesn’t have the same level of discussion of a definition as the Ph.D. thesis that he wrote in which he defines a business model as follows. “A business model is a conceptual tool that contains a set of elements and their relationships and allows expressing a company’s logic of earning money. It is a description of the value a company offers to one or several segments of customers and the architecture of the firm and its network of partners for creating, marketing and delivering this value and relationship capital, in order to generate profitable and sustainable revenue streams.” [Osterwalder, 2004]
Osterwalder carefully notes that a business model is not a representation of the business organization itself. He states, and I concur, that the business organization is the “material form that the conceptual business model takes in the real world”. [Osterwalder, 2004]
I will also take a moment to define business strategy. This time, from Kaplan and Norton: Business strategy is a description of how an organization intends to create value for its shareholders, customers and citizens. Note that this is not the same as a business model. Osterwalder addresses this distinction by illustrating that one can view strategy, business model, and process model as a three-tier hierarchy. The top level, business strategy, describes the conceptual approach to business change. The business model goes into more detail, describing the relationships between various components. The third level, process, illustrates the association of activities to the people and business functions that will perform them. All three are necessary, but all three are different in level of detail and analysis. The following picture is directly from his Ph.D. thesis (click to enlarge for readability).
One of the challenges in bringing together these concepts is the fact that most business architecture references make no mention of business models or describe business models as a “side concern”, and most of the business model literature makes no reference to business capabilities. I attempted to address this gap in the paper where I introduced the Enterprise Business Motivation Model, back in 2008. While the model has dramatically improved since then, the core motivation remains the same: to integrate these two concepts into a single coherent approach to understanding and modeling a business.
Business architecture cares about the organization of a company. It also cares about the resources or tools in a company. Business architecture cares about the processes, and the information. These elements are all brought together in the understanding of a business capability. Business architecture also cares about strategy. However, as Osterwalder notes, connecting strategy to organization or processes without an understanding of the business models is a partial understanding at best.
Let’s be clear about one thing. Business strategy is related to business models. In fact I will go further to say that all effective business strategy applies to one model at a time. Business strategy that applies to more than one model is not strategy. It is either a goal, a principle, or a vision of some kind. A strategy, by definition, has to express “how” the goal will be achieved, and that requires the context of a business in which to achieve it. I know that this may be controversial, but it is CORE to my understanding and the experience I want to share.
So let’s look at the viewpoints of business model proponents and business architects.
There are a number of problems within large organizations that cannot be solved by business architects without a consistent and careful understanding of business models. These problems are tenacious and challenging.
I would like to suggest that three of the key value propositions for business and enterprise architecture lies in addressing these specific challenges. In other words, Business architecture is only effective if it copes with conflicting strategies, inconsistent understanding, and indecisiveness caused by poor prioritization.
Conclusion: Including business models directly into the business architecture practice is critical to quality. Failure to include them is a recipe for disaster.
One of the chief complaints of senior executives in midsize and large companies is that their organizations don’t “execute” on the goals that they set. This concern is so common, it’s the butt of jokes. Entire systems of governance and measurement are created specifically to provide assurance to senior execs so that they can maintain some level of public integrity. Yet, when Enterprise Architects describe their roles to their peers, it is surprisingly rare to hear them talk about this issue. That is a mistake. Let’s talk about how to tell the story of Enterprise Architecture as the maintainer of executive integrity.
In 2003, when Motorola sent their CEO Chris Galvin packing, USA Today wrote about what a “good guy” he was:
He turned out to be a lackluster CEO, which, sadly, often seems to be the case when good guys land in the corner office. Friday, Motorola said Galvin would resign. Motorola under Galvin had suffered through six years of disappointing results, laid off one-third of its workforce, failed hugely on new ventures like Iridium, and waited for turnarounds that never happened. The board apparently had had enough; Galvin thought he'd better leave. I have to say I feel bad for Galvin. Of course, I wasn't a Motorola shareholder who watched the stock go from $60 (split-adjusted) in 2000 to about $11 last week. Nor am I a laid-off Motorola employee. And yes, Galvin was paid handsomely: $2.8 million in salary and bonus last year.
He turned out to be a lackluster CEO, which, sadly, often seems to be the case when good guys land in the corner office. Friday, Motorola said Galvin would resign. Motorola under Galvin had suffered through six years of disappointing results, laid off one-third of its workforce, failed hugely on new ventures like Iridium, and waited for turnarounds that never happened. The board apparently had had enough; Galvin thought he'd better leave.
I have to say I feel bad for Galvin. Of course, I wasn't a Motorola shareholder who watched the stock go from $60 (split-adjusted) in 2000 to about $11 last week. Nor am I a laid-off Motorola employee. And yes, Galvin was paid handsomely: $2.8 million in salary and bonus last year.
Did Galvin fail, or did Motorola fail to execute on Galvin’s strategy? The board of Motorola, and the board of any company, won’t see a difference. Note that this story has happened over and over in high-tech, from Steve Ballmer to Michael Dell, usually without the board firing their CEO. Far from being limited to high-tech, stories abound of retailers (Best Buy), manufacturers (General Motors), and financial services companies (too many to name) that have suffered through strategies that failed to pay off.
Here’s what stockholders see: you said “X” would happen and it didn’t. You lied.
From their perspective, the CEO loses credibility for lack of integrity.
Integrity is a personality trait and a virtue. A person has integrity when they can be trusted to perform exactly as they said that they would perform. In other words, they “do what they said they would do.” This person makes a commitment and keeps it. This means that they make commitments that they are fairly sure that they CAN keep, and they don’t forget the commitments that they made. In every high-performing team that I’ve been a part of, each member had a high level of integrity. Integrity is key to developing trust. If you do what you say you will do, people will trust you.
Executives need to develop trust just as much as individual contributors do. For private for-profit organizations, those stakeholders own stock, and purchase the goods and services of the company. For public organizations, those stakeholders are voters and legislators. Where an individual contributor must earn the trust of his manager and his or her peers, an executive is in a very visible position. They have to build trust daily.
Building that trust requires that they make bold pronouncements about the things that the organization will do under their leadership… and then their organization has to perform those activities. And that’s a key difference. When an individual contributor says “I will do this,” they are talking about their own performance. Rarely are individual contributors held accountable for failures of the people that they cannot control. Executives, on the other hand, are not talking about their personal performance. They are talking about the performance of the many (often hundreds, sometimes thousands) of people under them.
An executive doesn’t actually “control” the people under him. He or she must lead them. Sure, there can be an occasional “public hanging” (as Jack Welsh used to encourage), but, for the most part, the executive’s ability to speak with integrity comes from the trust he has in his organization to perform. In other words, how will with “they” correctly do what “I” said they would do?
Enterprise Architecture is a keeper of executive integrity
Enterprise Architecture is the only profession (that I know of) that is focused on making sure that the strategy announced by an executive actually comes to pass. Enterprise Architects exist to make sure that the needed programs are created, and executed well, keeping in mind the end goals all along the way. EA’s go where angels fear to tread: to execute strategies and produce the desired results if they can be produced.
If you value executive integrity, EA is an investment worth making.
As I’m about to complete my share of a longer engagement on using Lean principles to improve the processes at an online services firm, it occurred to me that the efforts we undertook to properly embed Architecture practices into their Scrum process were novel. I haven’t seen much written about how to do this in practice, and I imagine others may benefit from understanding the key connection points as well. Hence this post.
First off, let me be clear: Agile software development practices are not at all averse to software architecture. But let’s be clear about what I mean by software architecture. In an agile team, most decisions are left to the team itself. The team has a fairly short period of time to add a very narrow feature (described as a user story) to a working base of code and demonstrate that the story works. The notion of taking a couple of months and detailing out a document full of diagrams that explains the architecture of the system: pretty silly.
The value of software architecture is that key decisions are made about the core infrastructure of the system itself: where will generalizations lie? Will a layered paradigm be used, and if so, what are the responsibilities of each layer? What modules will exist in each layer and why will they be created? How will the responsibilities of the system be divided up among the layers and components? How will the modules be deployed at scale? How will information flow among the modules and between the system and those around it?
The way these questions are answered will indicate what the architecture of the system is. There are many choices here, and the “correctness” of any choice is a balance between competing demands: simplicity, security, cost, flexibility, availability, reliability, usability, correctness, and many more. (These are called “System Quality Attributes”). Balancing between the system quality attributes takes thought and careful planning.
So when does this happen in an agile process?
Let’s consider the architect’s thinking process a little. In fact, let’s break the software architecture process into layers, so that we can divide up the architectural responsibility a little. You have three layers of software architectural accountabilities. (Repeat: I’m talking about Software Architecture, not Enterprise Architecture. Please don’t be confused. Nothing in this post is specific to the practice of Enterprise Architecture). All this is illustrated in the diagram below. (Click on the diagram to get something a little more readable.
At the top, you have the Aligning processes of software architecture. These processes consider the higher levels of enterprise architecture (specifically the business and information architecture) to create To-Be Software Models of the entire (or relevant) software ecosystem. If you’ve ever seen a wall chart illustrating two dozen or more software systems with connectors illustrating things like flow of data or dependencies, you’ve seen a model of the type I’m referring to. Creating and updating these kinds of diagrams is a quarterly or semi-annual process and reflects the gradual changes in the strategy of the enterprise.
In the middle, you have the Balancing processes of software architecture. These processes consider the needs of a single system but only from the level of deciding why the software will be divided up into modules, layers, and components, how that division of responsibility will occur, and what the resulting system will look like when deployed in specific technologies in a specific environment. All of this can be conveyed in a fairly short document that is rich in diagrams with a small amount of text explaining the choices. This occurs once when a system is moving forward, and the software architecture can be developed alongside the first couple of sprints as input to the third and subsequent sprints.
At the bottom, you have the Realization processes of software architecture. This is where the architecture becomes software, and this is where decisions are made about the choice of specific design patterns, the appropriate level of configurability vs. simplicity, and the ability to demonstrate whether the actual intent of the architecture occurs in practice. In agile, this layer occurs within the team itself. The software architect can offer advice about what patterns to use, but it is up to the team to realize that advice and/or decide not to implement it. The team will very likely implement the software architecture as described, but may choose to improve upon it.
What does the process look like
There are many visualizations of scrum running around. Some are described in books, others in papers or blog posts. Most share some common elements. There is a product backlog that, through the magic of sprint planning, the team extracts a subset for the sprint. This becomes the sprint backlog. The illustrations then tend to show the various rhythms of Sprint as cycles (sprint cycles and daily cycles), ending with a demonstration and retrospective.
In order to illustrate and train a team on all elements, including the business analysis elements, we chose to be a bit more explicit about the steps PRIOR to sprint planning, including the processes of creating and improving the stories prior to the start of a sprint. (as above, click on the image to enlarge it).
Astute observers will notice that we added a step that we are calling “pre-sprint story review.” This is a meeting that occurs one week prior to the start of a sprint. It is called by the product owner and he or she invites “senior chickens” (architects, user experience leads, development and test leads, and any other “non-team” members that want a say in the sprint.
In that week prior to sprint planning, those folks, working with the product owner, can improve the stories, add constraints, refine the description and acceptance criteria. And here’s where the architects get to play. Architects fulfilling the role of “Balancing” in the model above will have (or can create) an outline document describing the architecture of the software system, and can “link” that document to the SPECIFIC STORIES that are impacted by that design.
(Note: assuming you are using a tool like Microsoft’s Team Foundation Server, that fully enables Scrum in multiple forms, this is a nearly trivial activity since a document can be easily linked to any story. Enough advertising.)
So is an architect a chicken or a pig? Answer: depends on what “layer” the architecture is at. The top two layers are chickens. The third layer, realization, is done by the team itself. The person on the team may or may not have the title of “designer". (I’d prefer that they did not, but that’s just because I believe that ALL team members should be trained to fulfill that role. In reality, the skill may not be wide spread among team members). Therefore, the third layer is done by the pigs.
I hope this provides some insight into how a team can embed software architecture into their scrum cycles. As always, I’m interested in any feedback you may wish to share.
A question on LinkedIn recently reminded me that, as the team leader for Segment Architecture in my former EA team, I was accountable for identifying a core set of deliverables for the team. The idea was that we could focus on defining standard formats and contents for these deliverables and, in doing so, we could start to measure both our output and our quality.
We only created pre-canned templates for a few of them. This is partly because the team was not mature enough in its practices to get consistency, and partly because Enterprise Architecture itself is not mature, or accepted, enough to have stakeholders that would notice if our deliverables meet an objective standard. Also this list is not intended to be comprehensive. The goal was to describe deliverables where it may possibly make sense to go for some level of consistency. Any EA could (and often did) create deliverables that were not on the list.
Perhaps it is time to share what we came up with.
Note that this list is the result of a single team doing its work, and is not representative of any “standards” effort across other EA groups. That said, I stand beside this list. I think it is a useful start. Note that many are technical in nature. I did not, in making this list, differentiate between BA and EITA deliverables. So if you are someone who believes that EA = BA + EITA, then you will see both sets of deliverables, intermixed, in the list below. If you are someone offended by the inclusion of technical architecture deliverables in an EA list… tough. I was working with reality.
Why create it
Architectural Point of View (or Technical Policy)
Provide clear input to Business or IT leadership on issues relevant to Enterprise Architecture
Short document describing a problem that requires attention and the opinion of EA for solving it.
Architectural Reference Model (or Architectural Pattern)
Provide clear input to IT project SMEs on optimal or preferable design options
Short document describing a set of concerns and a proven approach for addressing them
<Segment> Current State Model and Analysis
To demonstrate and communicate challenges inherent in current processes / systems / information
A collection of architectural models, including a context model, process models, and information models, as understood to currently exist , plus an analysis of issues and risks
<segment> Future State Vision and Model
To demonstrate the design of the future processes / systems / information needed by strategic intent.
A collection of architectural models that reflect a specific set of engineered changes
Governance Model and Analysis
Clarify roles and responsibilities and decision making processes for planning and oversight of initiatives
Process model, description of roles and responsibilities, and description of deliverables needed for planning, oversight and governance, along with implementation ROI and plans
M&A Business Case & Analysis
To provide a rationale for the acquisition of a company for the purpose of improving operational effectiveness. (M&A)
The document contains rationale including Competitive Analysis, SWOT / Twos analysis, and Strategic Alternatives Analysis
System Integration Recommendations Document
To set a vision for how key processes and systems shall be integrated into enterprise infrastructure (primarily M&A)
End to End business scenarios, Process and System Integration points, Risks and Issues for each integration concern, and an analysis of alternatives and recommendations
Value chain and operating model analysis
To clearly address gaps and strategic requirements for integrating or divesting a set of processes and/or systems (primarily M&A)
Target value chain and operating model for post-M&A future state. Mappings of key processes to or from the enterprise core diagram, and analysis of changes with the intent of composing key initiatives.
Enterprise Core Diagram
To clearly declare the processes and systems that are NOT core to the operations of the enterprise
A list of systems and processes mapped grouped into “ecosystems” that are clearly indicated as “core” and “edge” with analysis of governance
EARB Engagement Package
To demonstrate project level architectural quality to the EA Review Board
A pre-defined collection of project architectural models and artifacts.
Capability Model and Assessment
Provide clear basis for data collection for a segment
List of capabilities for a segment with assessment of capability maturity, etc.
Capability Gap Analysis
Highlight underperforming capabilities to focus investment
Map of capabilities needed by strategies, highlighting those needed investment, and listing relative and absolute program spend against each
<segment> Roadmap (a.k.a. Transition Plan)
To clarify the scope, timing, and dependencies between initiatives needed to deliver on a strategy
List of proposed initiatives and dependencies between them to deliver on strategic intent
Strategy Map and/or Balanced Scorecard
To clarify the strategies, goals, and objectives of a segment and allow for measurement and alignment
Categorized strategies, measures, and metrics for a specific timeframe and business scope
<segment> Process Model and Analysis
To clarify and build consensus on the business processes (as-is or to-be), and as input to process improvement / measurement
Models of processes, activities, information assets and system interaction points , and an analysis of opportunities to improve.
Enterprise Scenario and Analysis
To get clarity on the experience of a key stakeholder (often a customer or partner)
Textual and diagrammatic description of an experience, often with analysis to indicate opportunities
<segment> Information Model and Analysis
To improve understanding of requirements and the rationalization of design
Well-constructed information model, at one or more well-defined levels of abstraction, covering all aspects of a segment, aligned with EDM, along with an analysis of risks and issues
Capture ability of an app or platform to meet strategic needs
Collection of measurements, attributes, and mappings to an app or platform
Proof of Concept (POC) delivery
To create a design that demonstrates, and proves, an approach for solving difficult issues
A software deliverable and an architectural reference model (see above)
Record of Architectural Tradeoffs
To clearly communicate the tradeoffs made by architects on the customer’s behalf
Textual description of architectural decisions and the implications for the owner of the process / tool