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.
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:
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 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.
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.
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.
I heard some very interesting talks today from Len Fehskens and Jeff Scott at the Open Group conference. One thing that I picked up in a meeting yesterday was the notion that TOGAF 9.1 is built on “best practices.” Today, as Jeff spoke about the transformation of a technical architect into a business architect, and as Len spoke about the challenges of communicating complex ideas, the notion of a “best practice” kept bothering me, and I cross-pollinated my concerns with the concepts that they were sharing.
I agree that the intent of the people who shared their practices with the Open Group was to provide practices that can be taught and followed. I even agree that the people on the TOGAF committees that accepted the content felt that the practices represented the best that the industry had to offer at the time. But I wonder if any of the work done in framework committees of any stripe (not to pick on the Open Group) can be held to the standard of being a “best practice.”
Are the practices in the TOGAF framework truly “best” practices? Are these practices the best ones that the EA field has to offer?
I guess I would have to follow the EA rabbit hole and ask “what criteria do we use to judge if a practice is the best one?”
After all, when Jeff Scott talks about business architecture using capability modeling, he believes that the practice of capability modeling is the best one to use for the results he is trying to achieve. (I nearly always agree with Jeff, BTW. We sometimes differ in language, but nearly never in approach). That said, as much as Jeff and I agree, our agreement does not mean that the practice should be considered a “best” practice. Who are we to say? We are practitioners. While that is good, it is not enough in my mind to qualify the practice as “best.”
To be a best practice, in my opinion, a method or approach has to meet a higher bar. There has to be evidence that it is, in fact, better than just a “good practice.”
I think a best practice should have:
I wonder if we went through most of our frameworks and highlighted the text that is able to meet a higher bar, like the one I describe, how much of the text would we cover? 2%? 10%?
Is 10% coverage enough to say that a framework is based on best practices?
In the Open Group conference at Newport Beach, I listened to a series of presentations on business architecture. In one of them, the presenter described his practice of using Osterwalder’s Business Model Canvas to create a model of his program’s environment after a business program (aka business initiative) is started. He felt that the canvas is useful for creating a clear picture of the business impacts on a program. There are problems with this method, which I’d like to share in this post.
Let me lay out the context for the sake of this post since there is no business architecture “standard vocabulary.”
A “business program” is chartered by an “enterprise” to improve a series of “capabilities” in order to achieve a specific and measurable business “goal.” This business program has a management structure and is ultimately provided funding for a series of “projects.” The business architect involved in this program creates a “roadmap” of the projects and to rationalizes the capability improvements across those projects and between his program and other programs. For folks who follow my discussions in the Enterprise Business Motivation Model, I use the term “initiative” in that model. I’m using the term “program” for this post because the Open Group presenter used the word “program.” Note that the presentation was made at an Open Group conference but it does NOT represent the opinion or position of the Open Group and is not part of the TOGAF or other deliverables of the Open Group.
A “business program” is chartered by an “enterprise” to improve a series of “capabilities” in order to achieve a specific and measurable business “goal.” This business program has a management structure and is ultimately provided funding for a series of “projects.” The business architect involved in this program creates a “roadmap” of the projects and to rationalizes the capability improvements across those projects and between his program and other programs.
For folks who follow my discussions in the Enterprise Business Motivation Model, I use the term “initiative” in that model. I’m using the term “program” for this post because the Open Group presenter used the word “program.” Note that the presentation was made at an Open Group conference but it does NOT represent the opinion or position of the Open Group and is not part of the TOGAF or other deliverables of the Open Group.
The practice presented by this talk is troubling to me. As described, the practice that this presenter provided goes like this: Within the context of the program, the business architect would pull up a blank copy of the business model canvas and sit with his or her executive sponsor or steering committee to fill it out. By doing so, he or she would understand “the” business model that impacts the program.
During the Q&A period I asked about a scenario that I would expect to be quite commonplace: what if the initiative serves and supports multiple business models? The presenter said, in effect, “we only create one canvas.” My jaw dropped.
A screwdriver makes a lousy hammer but it can sometimes work. The wrong tool for the job doesn’t always fail, but it will fail often enough to indicate, to the wise, that a better tool should be found.
The Osterwalder’s business model canvas makes a very poor tool for capturing business forces from the perspective of a program. First off, programs are transitory, while business models are not. The notion of a business model is a mechanism for capturing how a LINE OF BUSINESS makes money independent of other concerns and other lines of business. Long before there is a program, and long after the program is over, there are business models, and the canvas is a reasonable mechanism for capturing one such model at a time. It is completely inappropriate for capturing two different models on a single canvas. Every example of a business model, as described both in Osterwalder’s book and on his web site, specifically describe a single business model within an enterprise.
I have no problem with using business models (although my canvas is different from Osterwalder’s). That said, I recommend a different practice: If the business initiative is doing work that will impact MULTIPLE business models, it is imperative that ALL of those business models are captured in their own canvas. The session speaker specifically rejected this idea. I don’t think he is a bad person. I think he has been hammering nails with a screwdriver. (He was young).
Here’s where he made his mistake:
In the oversimplified value stream model above, Contoso airlines has three business models. The business owners for these three businesses are on the left: Bradley, Janet, and Franklin. Each are primarily concerned with their own business flows. In this oversimplified situation, there are only two programs, each with one project. If the session speaker were working on the Plantheon program, his idea works. there is only one business model to create. That nail can be hammered in with a screwdriver. Lucky speaker. Showing Franklin his own business model is a good thing.
But if we are working on the Flitrack program, what do we show Franklin? if we create a “generic” canvas that includes cargo, he will not recognize the model as being applicable to his concerns. He will not benefit and neither will the program. In fact, Franklin will think us fools because he had a presentation from Plantheon yesterday showing him an accurate model… don’t you people talk?
Program Flitrack should have one-on-one conversations with Bradley and Janet to develop their business models. The business model that Franklin cares about does not need to be created again. It can come out of the repository. The Flitrack program would consider all three models as independent inputs to the business architecture of the organization impacting the program.
Anything less is business analysis, not business architecture.