How To Understand The Difference Between Value-Proposition and a Product or Service
One of my startup heroes Steve Blank wrote in a blog post that “value proposition is the fancy name for your product or service” It is with some trepidation that […]
Architecture
The Antifragile Enterprise: Complexity Exists, but Let’s Not Overcomplicate it or IT.
The Enterprise is a complex system. I have accepted that fact. I think many of us in the enterprise architecture profession have also accepted this fact as well, or at least I hope we have. But then again there is nat…
The Antifragile Enterprise: Complexity Exists, but Let’s Not Overcomplicate it or IT.
The Enterprise is a complex system. I have accepted that fact. I think many of us in the enterprise architecture profession have also accepted this fact as well, or at least I hope we have. But then again there is natural response to things in which we do in order to address “complexity.” There is a tendancy to…
Types of Cost
When planning and measuring business benefits there are three basic contributing elements: revenues, costs and intangibles. If you look for guidance on “types of cost” most sources decompose cost types […]
Tom Graves – The Business of the Business
An article by Tom Graves defining the scope of “business” every organisation is also ‘a business’ the business of an organisation is whatever the organisation does, for whatever business-reasons and […]
Culture club
To set my thoughts in perspective I came up with the “brilliant” idea of describing what I think of as designing The Happy People Business. This is part two in an expanding series of posts where I’ll elaborate on this topic. The Manifest One could call this the story of the architecture or one could […]
All Effective Enterprise Architects Are Agile
I explained to one of my clients recently that there is a perception of animosity between the Enterprise Architecture community and the Agile community. Both sides make assumptions about the other, often assumptions that are simply unfair. For example, many in the EA community think of “agile practices” as an opportunity to develop software without any architecture at all, while many in the agile software development community think of architecture as one of the “big design up front” guys who oppose their principles and practices. Of course, it is not difficult to find people who fit those unfair descriptions, but I’d like to point out how these two viewpoints are similar.
I believe that effective Enterprise Architecture must be approached from an agile standpoint.
First off, what does it mean to be agile? We can always look to the agile manifesto for some guidance, but more recent publications do a good job of filling in some of the details as well. I include a number of things in the notion of “being agile.” These are not just from the agile manifesto, but also Kanban and the Theory of Constraints, Systems Thinking, Six Sigma, Scrum, eXtreme Programming, and value stream analysis.
- A focus on performing high-value activities, and removing low-value activities.
- A focus on empowering the people who make things to make decisions about how those things should be made.
- A focus on developing small increments of actual value on a frequent basis and getting direct feedback on them.
- A focus on making sure that one thing is “done” before moving to the next, so that we reduce “debt” as we go.
- A focus on modern practices that remove ‘deployment impedance’ like test driven development and continuous integration.
I follow the terminology of Sam Guckenheimer in calling this the “Agile Consensus.”
We have to recognize that the “agile consensus” is an approach, not a methodology. It is a way of thinking about dealing with problems. More importantly, it is a way for dealing with complex problems. The diagram below comes from Ken Schwaber (inventor of Scrum) who adapted it from Strategic Management and Organisational Dynamics, by Ralph D. Stacey.
When we look at the problems that software is being used to address, and if we look at the process of writing software itself, we have to recognize that both areas of problems typically fall into the category of “complex.” Not always. Some software is simply configured and configured simply. Some problems that software addresses are simple problems. However, most of the discussions around software development are fueled by people addressing complex problems because that is where most of the software development community works. It is the bread and butter of software development: solving complex problems in a complex way.
Enterprise architecture also deals with complex problems. EA models and information are also complex to build and manage. In this way, EA is very similar to software development. EA solves complex problems in a complex way.
In order for EA to be effective, it has to use the same mentality as agile software development.
When I speak with enterprise architects who are actually doing the job of EA, big themes quickly arise:
- do the work that is highly valuable and don’t do the work that the business doesn’t value
- build consensus where it actually lives, not where the “people from above” believe that it does
- deliver value quickly and in increments that your stakeholders understand
- leave your repository in a good state of completeness with all the data that others need to use it
- build in the deliverable artifacts into the business processes that need it, so that you get immediate feedback
If this looks like the list above, that is intentional. I am trying to point out that Enterprise Architects use agile ideas, even if they often don’t use the term “agile” to convey the message.
Why use these techniques? They work for complex problems.
Can someone think of a more complex problem than helping to move an organization towards their goals?
EA addressed complex problems. Agile thinking helps them to do it.
The Death of Planning
It’s not so long ago that we still had debates about whether complex projects should be delivered as a “big bang” or in phases. These days the big bang has pretty much been forgotten. Why is that? I think the main reason is the level of risk involved with running a long process and dropping it into the operational environment just like that. Continue reading →
The most important personality trait of an Enterprise Architect
The video below, from RSA Animate, is not about Enterprise Architecture. At least, on the surface, it isn’t. In the video, we hear the voice of Roman Krznaric, a philosopher, talk about the need to build a greater reliance on the human emotion of empathy in order to create social change.
But as an Enterprise Architect, I am in the business of creating social change. I’m actually paid to get things to change (how’s THAT for a cool job). Of course, I’m paid to make the changes within corporations, and the benefit goes to the corporation by making them more effective, efficient, or timely in their desire to “make tangible” their own business strategy. However, the reasons and rationale aside, my job is all about change. And people do change, but not easily and not quickly.
There are many reasons that people don’t change. My father used to say “the hardest thing for a person to do is to think. The second hardest thing is to change. So if you want them to think, don’t ask them to change, and if you want them to change, don’t ask them to think.” Oh, there’s truth in there. You cannot get people to change simply by “convincing” them to do it. There has to be more to it, and there is. But to understand how to motivate change, it helps to start with a little thought experiment.
Think about the times when you changed. Seriously… stop right now and think about your own changes. Have you ever changed a core belief? Have you ever converted to a religion, or away from one? Have you decided to change your profession or career? Have you ever decided that the things that you always assumed were now completely untrue? Think about family members that changed?
Did you change because someone asked you to think? Or did you change because someone asked you to feel? What led the way?
I am convinced that the only EFFECTIVE way to motivate change is to reach out and touch someone emotionally. You can bring them along with logic, but if you don��t find their heart, and connect with their feelings, they won’t feel your message. Notice, I didn’t say that they won’t hear your message. They can hear just fine… but without connection, they won’t feel your message. And if they don’t feel your message, they won’t follow your lead.
We have often heard that change is about leadership. But how does a leader lead? Is it through logic and elegant words, or is it through emotion and beautiful thoughts? The most effective way to lead is to use both, but if you have to use one, use the emotional side first. In Switch, How to change things when change is hard, authors Chip and Dan Heath argue that you have to engage both the logical side and the emotional side to want to change. However, their metaphor is one of a person riding an elephant. The logical side is the rider. The emotional side is the elephant. Why, in their metaphor, did they choose an elephant? Because the emotional side is much larger than the logical side, and we can viscerally understand the metaphor on the basis of size and strength alone. After all, if the elephant wants to turn around, the rider can do little to stop him.
In Switch, the Heath brothers argue that change is an emotional journey and that there are three parts: the elephant, the rider, and the path. If the path makes sense to both the elephant and the rider, then you have removed the obstacles to change. Make it a clear path. Appeal to the rider to want to take it. Appeal to the elephant by addressing the fear or uncertainty that may drive them away from it. That is the job of the EA. To make a clear path, and to make it so that it starts where the elephant is actually standing at the moment.
So as an Enterprise Architect, how do I find a way to communicate with the Elephant and the Rider in the people that I want to work with? I use empathy. I don’t just use empathy… I live it. Empathy is the single most powerful, most important, and most useful personality trait that an Enterprise Architect can have, bar none. It is a skill that must be practiced, and learned, and honed. It is more than listening, but listening is involved. It is more than feeling, but feeling is involved. It is connecting at a deep level with the people that you are being asked to work with. It is building an empathic bond with them.
Philosopher and author Roman Krznaric explains how we can help drive social change by stepping outside ourselves.
Having a strong sense of empathy means that the EA has a strong internal drive to connect with others. He or she wants to hear their stories, and learn their troubles, and feel their triumphs, because ONLY by connecting with another individual can an EA understand what is motivating that person to change, and what is keeping them from achieving it. Only by listening to their struggles, and their successes, and their own efforts, can the EA create a path for that “emotional elephant” that Chip and Dan Heath describe. Because the job of the EA is to create the path. The job of the leader is to connect with the elephant to bring them down the path.
Some people motivate others through fear. Do this or you will lose your job. Do that or the company will go under (and you will lose your job). Do this other thing or we will cut your bonus or give you an assignment that you will hate. Some will motivate through rewards and recognition. “Look at what Tom did! He delivered excellent results and we want to honor him. You can be honored if you do as well as Tom.” In our capitalist society, that may even be in the form of income: “Your bonus will be larger if you do a better job.” (Both of these approaches fail, by the way. True story. Watch this TED video of Dan Pink’s presentation on motivation).
In order to motivate change, especially in creative jobs, you have to make it easy for the elephant (the emotional side) and the rider (the logical side) to follow the path from where they are to where they need to be. Notice that the path doesn’t start from where you think they are, or where a company thinks their employees should be. It starts from where they actually are. Without empathy, you may build the perfect “path” but it may start in the wrong place… where the elephant is not actually standing!
Empathy also helps you to connect with the person who you want to change, and to discover their intrinsic motivators. As Dan Pink points out in the TED video I linked above, the most important motivators are intrinsic. They are internal. They are not the incentives offered by the business. They are the things that a creative, thinking person already wants: Autonomy, Mastery, and Purpose.
- Autonomy – the desire to direct our own lives,
- Mastery – the desire to get better and better at something that matters, and
- Purpose – the yearning to serve a greater goal.
If an EA wants people to change, that EA has to engage that emotional elephant and that logical rider. To give people the autonomy that they need, and to demonstrate the mastery that they can achieve, and to give them a purpose to follow, in the world of control, incentives, and finance that the business lives in, you have to first listen and connect and understand. That requires empathy.
Flying in the Cloud by the Seat of Our Pants
In the early days of aviation, when instruments were unreliable or non-existent, pilots often had to make judgments by instinct. This was known as “flying by the seat of your pants.” It was exciting, but error prone, and accidents were frequent. Today, enterprises are in that position with Cloud Computing. Continue reading →
“What value will a Solution Architect add to this?”
After some prompting, the technical requirements arrived for architectural review. They had been prepared from a well-intentioned place and under the pressure of project timelines. Scanning through them revealed serious problems: these requirements were much too far progressed, and were based upon several fundamental anti-patterns. Needing to deliver some new information from one ERP system […]
Steps To Create a Core Diagram
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
- Collect a list of your organization’s business models
- Create or leverage a taxonomy of capabilities that reflect differentiation in business processes
- Differentiate each capability on the basis of Ross’ operating model taxonomy (level of Information Integration and level of Process standardization)
- Make an educated guess about the operating model of the company
- Draw the core diagram and build understanding around it
Understanding how to create a core diagram starts by collecting a list of the business models that your organization performs. Each business model is unique and different from the other ones. Each will require different capabilities and will often drive variations in those capabilities for the sake of market or product differentiation. You cannot create a core diagram effectively without the list of business models.
So what is in a business model? I’ve blogged about that fairly well. A business model is a composition of elements that describes how and why a value proposition exists, who it is for, and what it drives in terms of internal and external requirements. The diagram is below. (click to enlarge)
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.