Aggregated enterprise architecture wisdom
Frameworks have been established that cover many disciplines including architecture, process, governance, change, skills,and maturity. Having frequently been asked when working , perhaps not overtly, “why bother using a framework?”:- the implication being that they only add unnecessary overheads. When confronted with this it has been worthwhile … Continue reading →
Too often enterprises (businesses, governments, service organisations, …) constrain change to only being responsive to outside influences. Rather than being proactive and having control over their future they are reactive, consequently abrogating their control and the benefits it brings. Ideally … Continue reading →
I created a list of books I would give someone if they told me they wanted to be a good EA. Read all of these and you will be a guru (or more likely an unguru).
The post Everything You Ever Wanted to Know (about Enterprise Architecture) appeared first …
Change is inevitable. Every business enterprise whether private, government or ‘not for profit will be subject to some sort of change. How they respond will influence if the the outcome is positive or negative. Change can be driven by many … Continue reading →
Through ten years of working with dozens of companies, we have seen a lot of good and some not so good developments related to Enterprise Architecture. In recognition of those 10 years, those dozens of companies, and continued success, we would like t…
Through ten years of working with dozens of companies, we have seen a lot of good and some not so good developments related to Enterprise Architecture. In recognition of those 10 years, those dozens of companies, and continued success, we would like t…
Unsettled, the haplessly-institutionalised incumbents huddled together for warmth, two to a cubicle, cruel flickering artificial light obliterating any capacity they once might have harbored for self-actualisation or for problem-solving, casting an especially-stark relief upon their miserable, wasteful, angsty souls. They were unsettled by the juggernaut paperweight reputation of the new shepherd coming to guide them, […]
One of the most common problems in Enterprise Architecture, and one I get asked about routinely, is the “ladder” problem. Many Enterprise Architecture teams are formed by assembling a group of talented technologists into a team and giving them a charter to “go do EA.” The problem is that most of these teams have no credibility outside the technology group, and cannot really operate as a “bridge between business and IT” if they don’t have the relationships and knowledge that they need to be an Enterprise Architect. Building those relationships and that credibility takes time… sometimes many years. Until they make that transition, the team is an Enterprise IT Architecture team (EITA) and while that is useful, the value proposition of EA remains unfulfilled.
I call this “climbing the ladder” from EITA to EA.
While the entire team should work on this, only a few will succeed. Good news: That’s all you need. However, it’s important that everyone makes the attempt to climb the ladder. As a manager, I have no magic “test” to determine, for certain, which member of the team will make the transition and which won’t. I once thought I did, but reality proved me wrong. So everyone makes the attempt. Those who remain EITA’s can continue in that role for the EA team, or they can transfer to a different group where their technical skills are valuable and needed.
So, how is this done? How does an individual EITA climb the ladder?
You need four things:
Business knowledge is the one that should, on the surface, be the easiest of the three to acquire. Unfortunately, it seems to be one that is sorely lacking among EITA’s who are attempting to make this transition. What do I mean by business knowledge? I mean the ability to understand the basic concepts of business at a working level. In other words, can you answer these questions coherently:
Where do you get business knowledge? There are a gazillion books that will give you the basics. Universities are helpful as well. With the wide array of support, Enterprise IT Architects should have no difficulty learning these things… yet it’s startling how many don’t. I have some friends who insist that an MBA is needed. I disagree with that, but college courses do help. I hold out the most hope for success with a blended program like that offered by the Enterprise Architecture degree at Pennsylvania State University.
There has been a good bit of ink spilled about technical topics: mobile platforms, SOA, security, etc. These help with the EITA side of the job. But they don’t do much for the architect who needs to climb the ladder. To successfully make that move, most architects need to invest in training on their soft skills. This means building up the following:
Did you know that courage can be learned? I guess I always knew it was possible, but I never really considered it until I found myself with a situation where I needed to use courage, and needed others to do the same. I was playing the role of a SOA architect, and I needed to convince development teams and technical architects to adopt a set of patterns that would help the enterprise, but may actually add complexity to their own project. I needed to walk into rooms and see if I could demonstrate, convince, cajole, argue, and/or negotiate my way to changes that were not in the obvious best interests of the team itself.
I taught myself courage. I taught others courage as well. Part of teaching, and learning to be courageous, is to put your efforts into perspective. See your work as necessary to a “bigger picture” and be very aware of how much you can get away with before others decide that they cannot actually follow your lead or support your efforts.
Courage is not the lack of fear or operating outside of dangerous situations. It is the conscious choice to move ahead despite danger. As the Will Smith character in “After Earth” tries to teach his son, “Danger is real. Fear is a choice.” Sometimes, as an Enterprise Architect, you will have to tell someone powerful something that they don’t want to hear. The situation can end badly, impacting your ability to continue working as an Enterprise Architect, or worse, resulting in you losing your job. These dangers are very real to many EAs.
Courage means that you will need to move ahead anyway. It does not mean you should be reckless in the face of danger. It is OK to be cautious at times. But real success often requires boldness, and your bold actions cannot be made without the courage of your convictions.
There is a difference between “being courageous” and “being stupid.” The difference is support: do you have the support you need, by someone higher up the food chain, to take on the challenge of climbing the ladder in most organizations. This support from above is critical to your success. I call it “air cover” (a reference to a military situation where ground troops can request a deadly strike on an enemy to be dropped from planes, missiles, or artillery).
In a business setting, air cover means that you have successfully convinced leaders in various places around the company that you can be trusted. They believe that you are valuable and that your motivations are in the right place. So when a problem occurs, or one of your standards is challenged, or your roadmap makes a stakeholder angry, that leader can step in and sooth sore egos.
I cannot indicate the importance of air cover. For architecture managers, if you don’t provide air cover for your team, you are worse than an ineffective leader… you are a disgrace. And for architecture practitioners, if you don’t build the relationships you need to build so that you will have the air cover when you need it, you are not being courageous. You’re being stupid, reckless, or chaotic (take your pick). To climb the ladder, someone has to be holding the ladder. That’s your air cover.
Climbing the ladder is a difficult challenge for any Enterprise IT Architect (EITA). It takes dedication, support, and some significant innate abilities. However, for many who take on this challenge, the rewards are excellent. I truly love Enterprise Strategy Architecture. I hope to see many of you “in the trenches” with me, fighting to make our ecosystems healthier, stronger, and more agile every day.
You’ll notice that I never mentioned Certifications or Frameworks in the discussion above. That’s because I’ve met and known hundreds of Enterprise Architects. Certification was only useful to make them more effective as an EITA. It made no difference for climbing the ladder. Certification will help with some skills and a great deal of knowledge. A certification may build confidence, reduce churn in your team, and make your results easier for others to read and follow. I’m not putting down certifications. I’m just pointing out that this step comes with experience, not certification. At least, not yet.
Can Social Media create new ideas? Here’s an example where the answer is “yes.”
I recently blogged about EA models, and what makes them interesting. I was thinking about providing insight to people who were in the mo…
In the world of Enterprise Architecture, we are still creating “shared” understanding of how to tell our stakeholders what we do. There is no consistency in our diagrams or our descriptions just yet. This post will discuss the different ways we present the value stream of Enterprise Architecture and will attempt to select a particular viewpoint that can be useful for the majority of situations.
First, let’s address the most commonly shared representation: TOGAF. The TOGAF ADM model illustrates a sequence of activities that starts with a preliminary phase and works its way through each of the levels of architecture. Basically, TOGAF illustrates a straight-through process from phase A through phase H to develop and use architecture.
First off, I’m no huge fan of this illustration. I always wondered how you get to an architectural vision prior to considering the architecture of the business. Also, the notion of a center point focused around requirements management feels weirdly tactical. At the level of an Enterprise Architect, I’m dealing with strategies and measures of success. At the level of a technical architecture, the word “requirements” has an altogether different meaning. Grouping together the notion of “strategic needs” with “technical requirements” may make sense to a technologist, but I don’t know a single business stakeholder of EA that would agree with grouping those two rather distinct things.
These observations bring me to my first key consideration: If we want to communicate the value stream of Enterprise Architecture, we first should consider the audience, “who are we communicating to?” If we are communicating to a stakeholder of EA, we should show them the bits of EA that are relevant to them, and we should not show them the bits that are not.
It is not cynical to gloss over the complex bits of EA when talking to a business stakeholder… it is practical. In fact, we do it all the time. If you buy cable TV services, a person from the cable company may come to your house and install a coax cable to your home. He will mess around with a cable box for a few minutes, and then, if you are lucky, he will show you how to do simple things like changing channels and recording your favorite shows. Then, he’s off. He does NOT spend an hour describing the various technical aspects of signal transmission and digital carrier signals. Why should he? You don’t care. You want to watch TV, not get a degree in electrical engineering. And the same applies to EA.
Secondly, if we want to communicate EA, let’s recognize that different people interact with Enterprise Architecture in different ways. Business stakeholders will interact with Enterprise Architecture to ensure that their strategies are being executed effectively, with minimal interference, and producing a result that considers things like security, cost of ownership, and the ability to cope with rapid changes in the marketplace.
Recap:
The ADM from TOGAF is an odd bird, because it attempts to be all things to all people. It represents EA in a way that every stakeholder can use, but honestly, no stakeholder can use it. It is not wrong. Far from it. But it is not useful because it violates every single one of the rules above. The ADM reflects the EA viewpoint, but not the viewpoint of the customers of EA at a level that they can grasp, understand, and most importantly, use. So let’s keep the ADM in our court, and create a view of the EA process that is relevant to our stakeholders.
So who are our stakeholders? For the sake of this post, I’m going to select one set of stakeholders and ignore the rest. Is that correct? Nope, but it is practical for a blog post. What this means is that the rest of this post produces an answer of the “right” representation only for one class of stakeholders… another representation would likely be needed for different people. That is the nature of EA. Let’s not fret it.
There is a widely held view in Enterprise Architecture that an EA must be technically savvy in order to be effective. There are certainly business architects who are quite effective who are not technologists, but in order to move UP to the notion of an EA (which includes business architecture, information architecture, solution or application architecture, AND technology architecture), you would need to be technically capable.
I won’t belabor the point about whether it is correct to view Business Architecture as a subset of Enterprise Architecture. It is the wildly predominant view. (A poll that I put on LinkedIn that asked this question found that well over 80% of EA respondents agree that EA generally includes every aspect of business architecture. That’s pretty overwhelming.)
That said, our biggest struggles in EA rarely involve conversations with other architects. While there may be a great deal of confusion, there is rarely a lack of buy-in for architecture among architects, or even technologists. Our key challenge, when it comes to communication, comes when we are talking to non-technologists. In other words, the proverbial “business” stakeholders of EA. (Please don’t flame me about whether IT is part of the business or not. That is a useful conversation, but it is outside the scope of this post).
Therefore, for the rest of this post, I will focus on the non-technology stakeholders of Enterprise Architecture. These are people whose chief concerns are not technical concerns. We could say that they care about financial performance, role clarity, cycle time, cost effectiveness, market position, revenue growth, opportunity costs, business drivers, and many other factors outside the realm of technology concerns. People in this category include senior business leaders (CEO, COO, CFO, CIO, CMO, etc), as well as business unit leaders (General Managers, Sales Division Leaders, Product Development and Marketing, Customer Service, Online Services, etc).
In order to communicate directly and well to these folks, lets recognize that they don’t care about the aspects of architecture that are technology focused. While the WANT good technology, and will BENEFIT from good technology, they will assume that the technology issues can be handled effectively without bothering them with details. To refer to our previous metaphor, they want the cable company to handle the technology, so that they can deal with changing channels.
So, let’s take the ADM, and trim out the stuff that non technologists rely on, but don’t need to have a conversation about. They assume it is there. That includes the preliminary stage, as well as architectural vision, requirements management, information systems architecture, technology architecture, and architecture change management.
The ADM now looks a bit different. In fact, we can put it in a single row with a looping arrow. Note that, in TOGAF, the Business architecture phase includes both current state assessment and future state modeling.
We have removed the confusing bits from the view of the non-technical stakeholder, but it is tough to say that we are at the point where we are relevant. After all, the non technical stakeholder has a business process that he uses when working with changes to his or her business. We are not representing that process.
The process, frequently described in dozens of bits of EA literature, starts with an understanding of the current situation within the business. Then, when the business creates a strategy, we bring these two bits of information together (current state and strategy) to create a vision for the future. This is the order that the non technical stakeholder may recognize… not the generalized view of the ADM. So it is time to break apart and rearrange the bits a little bit. I will now step away from the “crop circles” representation since it is so far out of the experience of people who describe business processes.
In this view, we can begin to see the steps that an Enterprise Architect would perform that are visible to a non-technical stakeholder. Just for the sake of clarity, this doesn’t mean that the technical steps are absent… it just means that our technical efforts don’t have to be paraded around in front of our non-technical stakeholders.
Note that I relabeled the ADM steps.
Let me point out that the TOGAF process assumes a different order of activities than the diagram above. From the standpoint of the stakeholder, this is what makes sense, regardless of how TOGAF describes the stages. This is why I’m no big fan of TOGAF as a methodology. It doesn’t reflect reality. On the other hand, the elements above are fairly well understood.
Also note that I’m not saying that the substitutions listed above are equivalent. In fact, I’d argue violently that Business Architecture is far more than Current state evaluation and Strategy Development. However, from the viewpoint of the non-architect, business architecture is a process that is involved with the development of business models (current and future), and that’s about it. There is a great deal of effort that is not seen by the stakeholders.
In other words, the blue model above is only showing the tip of the iceberg, and relabeling the phases according to what is (approximately) visible, not what is actually there.
This is an important part of explaining an activity to a stakeholder, and it is a skill that every Enterprise Architect must get good at. You have to explain your activities in the context of what a stakeholder understand and recognizes… not in the context of all your work. It’s not about you. It’s about the stakeholder.
There are a few problems with the view above. In order to understand the problems with that view, let’s mention a couple of rules for representing a value stream. We will use these concepts because the ability to describe EA in terms of a value stream is important. Value streams are sticky… they are easy to remember and easy to relate to. If we want to remove the barriers to adoption of EA, we could do far worse than using this technique. That said, there are some rules that we have to keep in mind:
So let’s apply rule #1. Is it true that the current state of the organization actually feeds the development of strategy? No. In fact, the evaluation of the current state can happen completely in parallel to the development of business strategy.
So the diagram could look like this one.
Here, we can see that there are, in fact, parallel activities for the understanding of the current state of the enterprise, and for the development of business strategy. Where they first intersect is in the development of the future state (the opportunities and solutions phase from the ADM model). You need both an understanding of the current situation and the needs of the future in order to describe where the organization should move towards.
Now, let’s apply rule #2. What is the event that the business considers to be relevant to start the value stream of Enterprise Architecture? The Development of Business Strategy, of course. So the flow should perhaps look more like the diagram below… (note, the arrows and activities are identical to the one above… the only thing different is the order on the page).
Now, let’s apply rule #3… that one is easy. The arrow at the bottom that says “First TIme EA” can simply be dropped. After all, the first time a process is run, it starts from somewhere. It is simply irrelevant to the non-technical stakeholder to point out where that starting position is.
Exception: if you run Enterprise Architecture as a consulting arrangement, you may want to leave that arrow in there. After all, you will need to illustrate where the consulting arrangement will start. That said, I have found that fewer and fewer EA initiatives begin with the hiring of a consulting firm.
When we started with the ADM, we assumed that there was a 700+ page methodology and framework behind the image, describing each step and what is included. However, your stakeholder will not read the TOGAF or any other 700+ page body of information. That would be absurd. You need to add a little detail to the image to describe what is in each of these stages.
It’s also a good idea to “clean up” the diagram a little so that we use less space on the “arrows and boxes” and more engagement on the ideas of what is going on. So the next modification of the process looks like this:
This diagram is a better one for informing the non-technical stakeholders of your Enterprise Architecture program about what it is that you do. We remove a little of the “accuracy” about where an arrow starts and ends, but we add a great deal of context about what is happening along the way.
The “backward” arrow along the bottom clearly indicates that there are activities that flow outside the value stream but which are needed for each repeat of the cycle.
Is this a perfect representation of the EA process? I don’t believe in perfect things… just useful things. But it is better, in my opinion, than showing a non-technical stakeholder the ADM or one of the “box and arrow” models above. It uses the visual language of value streams and business process models, both widely recognized and used in business interactions. It explains itself without going into a lot of detail. And it clearly describes the end to end flow without restricting or dictating where Enterprise Architects start and stop (an important requirement, since maturing EA programs will change their scope as they mature).
I have shown this view to others, and some have wondered about the “backward flowing” process along the bottom. The alternative to showing something as “backward flowing” would be to illustrate it as a cycle (with arrows feeding “in” from the right and “out” from the left). If it is a challenge for you to view the diagram without those arrows, I apologize. I’d love to see other view of this model that illustrate the “cycle” in a way that still meets the “rules of the value stream” as discussed above.
I’d love to get feedback and insight from the community. What do you think? Does the last image above resonate? What would you do differently?
This is in response to the recent article of Richard Veryard “Arguing with Mendeleev”. There he comments on Zachman’s comparison of his framework with the periodic table of Mendeleev. And indeed there are cells in both tables with labelled columns (called “groups” in Mendeleev’s) and rows (“periods” respectively). Another similarity is that both deal with […]
As a lot, Enterprise Architects are not terribly humble people. We name frameworks after ourselves, and sometimes go to great lengths to correct the “misinterpretations” of others who describe our work in a way that we don’t agree with.
Yet, recognizing that the field is young requires that we should be willing to change as the field of EA changes; that we should be willing to look back on our models, developed in the past, and admit that we missed a few steps that we wouldn’t miss today.
I recently had the opportunity to discuss, on LinkedIn, a blog post that I made five years ago. I look back on that blog post and must admit that my opinions are a bit different now than they were five years ago. I still agree with my post, but I would certainly use different words today than I used in the past. I am more than willing to admit it.
I also look at the efforts of Alexander Osterwalder whose Business Model Canvas has proved both practical and flawed. He missed the fact that he needed to create a differentiation between the customer’s needs and the value proposition of the business offering to fill some of those needs. Did he go back and create an updated canvas? Nope. He created a new canvas to describe demand as though it fits with his older one (hint: it’s a mess).
The venerable John Zachman, probably one of the most humble men I’ve met, also made this same mistake. While his original model was only a couple of columns, and was updated only a few years later into the table we see today, the field of EA has changed. The table is no longer representative of companies with multiple business models (most of them) and the lack of a “customer” row simply relegates his “ontological table” to the dust bin.
Neither man will change. They have “legacy” models, with their names attached. To paraphrase Forrest Gump, humble is as humble does.
I would like to think that my willingness to upend my EBMM and replace it periodically with new versions shows my willingness to admit that (a) I’m often wrong, and (b) I’d rather learn than become stale. That said, I’m no paradigm of humility, myself.
After all, a truly humble EA would not have written this blog post.
(As my teenage daughter would say: Oh snap, you pwned yourself!)