I’ve met many Architecture Managers over the years. Sometimes they go by the title of “Chief Enterprise Architect” or “Chief IT Architect” and other times, the title is “Vice President of Architecture and Strategy” or some variant. The men and women called to serve in this unique role have a distinct, and uniquely important role to play in the success of the Enterprise Architecture function in their enterprise. Yet precious little is said about them.
In this article, I’ll touch one some of the key qualities I would expect to find in a successful Architecture Manager.
What value does an Architecture Manager provide
As the role of Enterprise Architect matures in organizations around the world, we’ve begun to see the tremendous impact that an effective architecture manager provides. In many ways, the Architecture Manager is the single most important role in the department, but also the most difficult role to fill. That is because, typically, the role is filled by a person who “moves up” from being an Enterprise Architect. Unfortunately, being an excellent EA is poor preparation for this particular role.
An Architecture manager is:
- An expert at “selling upwards” – Convincing management of the need, role, measures, and successes of the EA function as a whole.
- An expert as “peer selling” – Convincing enterprise peers of the value of requiring their staff to collaborate with an architect, especially when doing so forces a change on the processes they would otherwise use. (this is one of the most difficult and valuable activities an Architecture Manager can do).
- A visionary for the development of the function – Convincing the team, the management, and internal partners of the vision and desired impact of Enterprise Architecture in the organization, keeping in mind both short term and long term goals. Without vision, the function cannot grow.
- A good people and resource manager – Capable of aligning people to roles that can be successfully performed, helping his or her staff to grow to meet their potential, and finding new resources from within and without the enterprise capable of performing an architecture function. It’s amazing how many architects move up to a manager role and have no idea how to do this well. This blind spot can kill a team within a year.
In my travels, I’ve met both good Architecture Managers and not-so-good Architecture Managers. The ones in need of improvement nearly always struggled at one of the above.
What are the responsibilities of an Architecture Manager
Enterprise Architects are rare birds… especially good ones. There are many folks who have worked to become Enterprise Architects, and a few who succeeded in recognizing the uniquely holistic role of an EA. Typically an EA has to manage through influence alone, because it’s rare that an EA has a team of resources assigned to him or her. But an Architecture Manager is in a different position. They do have a team, and unlike other efforts where they could be objective about a business leader’s business processes and functional alignment, they now have to perform architecture on themselves. Sometimes, they succeed.
If you find you need to hire an architecture manager, you’ll need a list of responsibilities for your hiring team. Just copy the following list.
The responsibilities of an Architecture Manager include:
- To set the vision, goals, and measures of success for the Enterprise Architecture function within an enterprise, recognizing the current team maturity, skills of the team members, and readiness of the enterprise to accept the role as desired.
- To measure the value of the efforts of the Enterprise Architecture function in a neutral manner and present those measures at appropriate times to stakeholders within the enterprise to earn buy in for the function and the funding it requires.
- To create, refine, and oversee execution of the internal processes of the Enterprise Architecture function, including documenting processes, building support for points of interaction, and ensuring the deliverables match the expectations and timing needed by internal partners and stakeholders.
- To manage the team members of the Enterprise Architecture function effectively and within the required parameters set by Human Resources. This includes hiring staff, setting team goals, and conducting performance reviews.
- To manage the assignment of resources to necessary priorities within the enterprise to meet conflicting strategic needs, and shielding the team members from being pulled out of role.
- To act as an evangelist for the role of Enterprise Architect within the enterprise, working to build support for the function and its staff members among internal partners.
What should an Architecture Manager know
Some of this is pretty obvious, but it’s worth stating anyway. The architecture manager has to be familiar with enterprise architecture. But they also have to be familiar with how things can work in an organization, especially if the focus of the EA program is related to IT (as it nearly always is).
- Experience with and understanding of the deliverables and value proposition of Enterprise Architecture.
- Deep understanding of the methods and processes an appropriate EA framework.
- For telecom, this would be Frameworx (formerly NGOSS and eTOM).
- For US federal government, that would be the FEA or DODAF. (in different countries, there are different governmental frameworks).
- For private business, the leading frameworks would be TOGAF in first, with a tiny number of organizations still using Zachman.
- A small but growing number of companies use the Pragmatic EA Framework (PEAF).
- Most organizations roll their own, often from TOGAF, so starting there is the safest. Note that a certification in TOGAF or the Zachman Framework is a great start.
- Strong written and oral communication skills
- Strong and demonstrable systems thinking and strategic thinking skills. The ability to capture the key elements of a system into a simple abstraction that empowers good decisions.
- Solid business financial skills. Demonstrable ability to perform cost benefit analysis and manage the budget of a team.
- Strong business negotiation skills, influence, conflict resolution, and political savvy
- Demonstrable leadership in Portfolio Management, Project Management and Enterprise Change Management
- Multiple years of Strategic Planning experience, preferably in a governance role
What should an Architecture Manager NOT do
In many cases, people who move into the role of Architecture Manager worked their way to that role as an architect. They may have been a technical architect, solution architect, business architect, or enterprise architect. In many organizations, these roles are deeply technical. Of all the architecture managers I’ve met, the overwhelming majority are technologists.
Unfortunately, most technologists don’t have the skills to focus on the responsibilities listed above. It is tempting to continue to be a technologist once moving to this role. It is also suicide. Your term as the “Vice President of Strategy and Architecture” will be short if you cannot step back and let your team perform the technologies or modeling activities typical of an architect. This means, for the architecture manager himself or
herself: No modeling, No coding, No time spent geeking out. (Ok, exception, fiddling on the side is fine, especially if you want to “stay warm” with your technical skills… but nothing deliverable.)
Where should I look to find a good Architecture Manager
First place is the same as you’d expect for any role: find a person who was successful as an Architecture Manager in another enterprise. Be careful of people who performed but did not succeed as an Architecture Manager. Most folks fail. Find out if the function continued after they left, and if their team enjoyed working for them, and if their stakeholders saw fit to provide an increased level of interaction with their staff members. Look at examples of their teams’ deliverables and ask about their ability to build and maintain new business processes.
Second option is to bring in an experienced architect and let them take on the role. Assuming the team already exists and is well accepted within the organization, this is a reasonable approach. Finding a seasoned architecture manager is extraordinarily difficult, so this may be the only rational option. The person you select should have worked for at least six years as an Enterprise level architect, with increasing levels of responsibility, and should preferably have been a resource manager at some other point in their career. If the program does not already exist, see the next section.
Third option is a seasoned manager who has no experience as an Enterprise Architect. This may be a distinguished technical architect, or the leader of a highly visible program in the past. These folks are expected to bring expert team leadership skills and deep technical skills. The biggest challenge that they will face is being able to adequately learn the role. Unlike most other management roles, the Architecture Manager must be able to SELL the value of the role of Enterprise Architect, and that is extraordinarily difficult to do if the manager wasn’t an architect first. The learning curve is very steep. To pull this off, the Architecture Manager will need a good mentor or an experienced consultant to help guide them through the first year in role.
Building a program around an Architecture Manager
If you don’t already have a functioning Enterprise Architecture program, your very first hire will be the Architecture manager. This role will be doing a great deal of heavy lifting in that first year. Setting up processes and deliverables. Making sure that the stakeholders buy in to collaborating with those processes. Hiring and situating staff. Creating priorities and managing resources. Setting up measurement and demonstrating value. It’s a tough road to build from scratch while providing value.
The only advice I can give: do NOT build a new EA program around an Enterprise Architect who has never been an Architecture Manager before. That is simply too much for a single person to handle. Going from EA to Architecture Manager of a new program is a huge leap, and I have never seen it be a successful approach in the long term. The person you hire may be a “survivor” who knows how to avoid being fired, but that won’t make them effective. Once they move to another role in the enterprise, the function will likely vanish.
You need the Architecture Manager to be effective. To build a program with lasting value. To build a program that matures over time.
So if you are building a new EA program, build it around an experienced Architecture Manager. Then support them with resources that they did not ask for: (a) an outside expert who can provide a neutral point of view and sounding board as they build and struggle that first year, and (b) Serious “air cover” so that they have the time needed to build the team, create the processes, build support, and demonstrate early value.
The single most important person in the Enterprise Architecture function is the Architecture Manager. This critical role is part visionary, part marketer, part people manager, and part evangelist. They have to change the organization and keep the change from undoing itself. The role of Enterprise Architecture is highly dependent upon the skills and the focus of this key role. Choose wisely.
I recently had the pleasure of joining a discussion among organizational development professionals. During that discussion, one individual asked an interesting question: in a distributed organization with multiple operating units, spread geographically around the world, should the organizational structure of each unit be similar?
The illustration that the questioner used: organization structure (org charts). Should the org charts look alike?
As examples, he mentioned two business units of his own company, one that was fairly “steep” with a Managing director having two direct reports, both Vice Presidents, and each of them having a small number of VPs under them. The alternative was a different unit of the same company where the Managing director had something like 16 functional managers reporting directly to him or her.
Unit one looked something like this:
Unit two looked something like this:
The questioner illustrated his example by pointing out in the “steep” structure (unit one), the director of Human Resources was somewhere down at level four. In the “shallow” structure (unit two), the director of Human Resources reports directly to the managing director.
So here’s the problem he faced: the company had a hard time moving a qualified director of Human Resources from unit two to unit one, because he would be “dropping” to four levels below the managing director, and that meant less control, less access, and less effectiveness. On the other hand, the executive in unit two, who had a large number of direct reports, frequently complained about being overworked.
Should we force each of the units to have the same hierarchy?
Think about it. The company had many structures, and they were different from one another, making it difficult for a person doing work in one of those structures to translate their work, their processes, and their efforts from one to another. This limited mobility of workers and cross-pollination of skills. It limited information integration and consistency. It limited process reuse. It meant that quality of the output could be quite variable, even though each of these different units produce the same (highly complex) product!
Before I go on… what do you think? Should the company have the same structure in every one of their geographically diverse operations?
Would you change you mind if I told you that some of those business units were two orders of magnitude larger and more profitable than others?
Which is better: diversity or consistency (replication)?
The first observation I’d like to make about this “problem” is that it is a problem by choice, and not by accident. The organization is NOT a franchise model. This is a large organization that has grown over the past 100 years to be a very successful company. Most of the life of the company preceded the information technology revolution… before computers and teleconferencing and instant communication. Each of the business units had no choice but to operate independently. Corporate management, early on, chose to allow each of the business units to structure itself as needed based on local conditions, people, culture, regulations, and resources. In the terms of Jeanne Ross (author of “Enterprise Architecture As Strategy”), the organization was not a replication model. It was a diversification model.
That said, each of these business units provided essentially the same product in each of a half-dozen different locations around the world.
Only someone who had read Jeanne’s book would recognize that the underlying question in the room was simple. The person posing the question saw a great many advantages to having a “replication operating model,” and didn’t see an advantage to having a “diversification operating model.” He was seeking input on whether he was the only person who could see the advantage to making a switch. (of course, he was not the CEO, so it was a fictional exercise, but a useful one nonetheless).
Switching from a Diversification Model to a Replication Model
There are many problems with making a switch from a diversification model to a replication model.
- It is fairly complex to do. An “ideal” model must be created for all of the business units to follow. Since none of the current business units is likely to have that “ideal” model implemented, you’d first have to create an “ideal” model and then implement it in one place to get feedback on how it actually works (if it does). That takes time. Once you’ve made changes in one place, rolling it out means moving people, recreating processes, and restructuring information and accountability across each of those units. It’s essentially the same a tearing down a company and starting over. Only each of those business units will have to keep operating while it is going on, and will have to show profit at the end of the year.
- Loss of business unit innovation. Companies making that kind of switch usually screw up at the “ideal model” stage because creating the “ideal” model rarely involves the right conversations with every one of the business units involved. As a result, innovations that are working well in one area can be lost because those innovations were not copied to the “ideal” model, even if they would have been useful to everyone. Importantly, innovations that were about to be implemented in any one unit, but had not been, are completely discarded. Evolution of the business units themselves can be thrown backward by years. Also, by the very fact that there is now “replication by policy,” it becomes very difficult for any further innovation to occur because it has to occur once and then be replicated everyone else, regardless of whether that innovation has the same ROI in each business unit. (Hint: it nearly never does).
- Loss of local adaptations. There is a notion that “the person closest to the work knows best how to do it.” In the case illustrated above, the two business units being compared were in different parts of the world, with different business cultures and business expectations. The PEOPLE in these organizations have a specific idea of the way that business operates. They have relationships, cultural expectations, and accountabilities neatly arranged to suit those local conditions. Your “ideal” structure will come from you, and you live in a business culture. We all do. Therefore, you have assumptions about what will and will not work. If you impose your structure on a group of people, be prepared to re-educate every single person in every single business unit on the “one right way” to do business… and then you’d better hope that the “ideal” you have created will be more effective in a local environment than the one that was previously there. (Hint: it probably won’t be).
A better way
As I have explained in my previous discussions of “Minimum Sufficient Business Integration,” I believe that many modern organizations can benefit from taking the time to find the minimum set of capabilities needed across business units to meet key corporate goals. After that minimum set is understood, the rest of the choices can (and probably should) be left up to the people closest to their customers and suppliers. At best, a “reference model” can be widely shared that represents your idea of what an “ideal” structure would look like… but without enforcement from above.
Of course, it can take a little thought to understand what is the “minimum” level of commonality that should be imposed. It should be very carefully considered because, and this is important, for there to be value in this concept, that level of commonality will be strictly imposed. No exceptions. On the other hand, every little thing included in that “common set” will be VERY expensive to roll out consistently across a wide array of business units, so the absolute minimum set should be included.
My recommendation for this situation is to remain in a diversification model, but to consider moving a little closer to process and information consistency through minimum sufficient business integration (MSBI). This means having consistency for those areas that absolutely positively must have consistency, and then to allow diversity (and innovation) to grow atop that minimum set.
In that case, the org charts would probably remain different from one another… and rightly so.
P.S.: I also want to point out that the notion of minimum sufficient integration takes place at the level of business capabilities. Not business processes. Not information elements. Not business functions. Capabilities. So if your business architecture methods don’t use capabilities (or if you don’t know what capabilities are), you cannot use this methodology. This post is not going to teach you what a business capability is, but I’ve blogged about them dozens of times, as have hundreds of other folks including the Business Architecture Guild and the Business Architecture Society. Start there.
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.
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.
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.
Who is our audience?
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.
- We have to care who we are speaking to, and we have to reflect the things that they care about.
- We have to show them the details that matter to them and obscure the details that don’t.
- We should illustrate the activities in the context of the processes that they understand, and not at a conceptual level that may be difficult to relate to their daily experience.
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 compa
ny 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.
Representing the processes of the non-technical stakeholder
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.
- Business Architecture becomes Current State Evaluation, and Strategy Development
- Opportunities and Solutions becomes Future State Modeling
- Migration Planning becomes Roadmap Development
- Implementation Governance becomes two things: Funding and Initiation (the Project Portfolio Management aspects) and Oversight and Governance (the governance of ongoing activities).
- Architecture Vision is cut down to only the elements relevant to the non-technical stakeholders: the evaluation of the current state of the enterprise.
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.
The Rules of Value Streams
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:
- A value stream does not illustrate dependencies that are not really there. Parallel efforts should be represented as parallel if that would improve understanding of how value is created.
- The value stream is illustrated as a sequence of high level processes in a straight line from left to right. That said, a value stream must start with an event that is relevant to the customer who gets value. It must end with the deliver of that value. Any activity that is not part of that flow (from relevant starting point to value) should be represented “above” or “below” the value stream.
- A value stream should be illustrated in its fully operational state. In other words, it should describe a process that is running, not one that hasn’t been created yet. Events that are relevant only for “start-up” activities can be included, but should not be the primary focus of a value stream.
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?
Way back in April, I announced the first of two podcasts with the Canadian Information Processing Society. I just realized this weekend that I had not announced the availability of the second of those podcasts. Error corrected.
The second podcast, once again hosted by the inimitable Stephen Ibaraki, focuses much more on the growth and progress of the Enterprise Architecture profession itself. Specifically this podcast reflects upon:
- The role of Business Architecture in Enterprise Architecture?
- Does an Enterprise Architect have to be able to discuss technical issues like cloud computing?
- How would you define Enterprise Architecture?
- The value proposition of the Enterprise Architect?
For full details, and a link to the podcast, visit the Canadian IT Manager’s Connection, a TechNet site.
As I found in our Enterprise Architecture team in Microsoft, each time an Enterprise Architect is assigned to a specific area of the business, each one has a unique “engagement” with their stakeholders. In very large organizations (like mine), there may be many different IT units as well as many different business units, all involved in a particular strategy. Each situation is different. This leads to a common problem that can framed with two questions:
- So how do you know if your Enterprise Architect is doing a good job?
- How do you set the right expectations to position that Enterprise Architect for success?
A Model for Positioning an Architect
We developed a simple grid that helps to position the EA with respect to a specific area of the business. The two axes of the grid are: Architectural Maturity of the “segment” and Maturity of the Architectural Engagement itself. Within each cell, we put a description of “what we want the EA to do” if they find themselves in that position.
Note that maturity of the engagement is a measurement of a relationship: specifically the relationship between the “business customer” and the Enterprise Architect. Architectural maturity of the segment is measured against both the business area and the IT groups that they use (see below). You need to measure the maturity of BOTH variables in order to understand what an Enterprise Architect will need to do to be effective.
Note that the Architectural Maturity axis has four levels, cryptically described as “Level I” through “Level IV”. This is a reference to our internal maturity model, which I’m not at liberty to share in detail.
The broad strokes are:
- Level I – architecture is not a trusted and well-understood role in business change or IT programs. (This includes business, information, solution, and technology architecture).
- Level II – architecture is used and their processes are defined, but not consistently and not well.
- Level III – architecture is performed consistently and is part of governance as well as some portfolio planning activities. The business stakeholder does not take ownership of driving the funding and execution of the roadmaps developed by the Enterprise Architect.
- Level IV – architecture is performed consistently and is involved in planning and governance. The business stakeholders involved in funding and overseeing the business changes themselves are engaged with enterprise architecture, have been key in developing the roadmaps, and follow through with regular updates to the future state models and the roadmaps. In addition, they decide on which initiatives to use BASED ON the content of the roadmaps.
Using this model
I’ll provide two scenarios to illustrate how this simple grid is used.
In Fabrikam, we are Enterprise Architects. Fabrikam manufactures and distributes consumer electronics. There are six divisions that manufacture different kinds of products (kitchen appliances, television and radio, automotive, etc). Let’s say that we have 18 Enterprise Architects in our EA team. Fabrikam’s EA has divided into three working groups, each with six architects. Maria manages one of these teams, and has six enterprise architects working for her. Her team focuses on addressing business issues related to supply chain management.
Maria is performing an annual review for two of her architects. They are Tomas and Jai.
Case 1: Tomas
Tomas is working with the kitchen appliance team. This is the oldest division in Fabrikam, and they have their own IT group that has been stable for many years. That team has established processes for IT architecture but no business architecture. Their architectural maturity is Level III. Tomas just moved over to the kitchen appliance division from the television and radio division. He is a well established architect with years of experience, but the kitchen appliance team is just beginning to get to know him. As a result, the maturity of the engagement is “Useful.”
The intersection of these axes has the following text:
- Engage in existing review and governance processes
- Engage stakeholders in cross business decisions
- Collect current state data
Maria can set expectations with Tomas and with the Kitchen Appliance division. Tomas will be expected to engage in existing governance and review processes. He will be expected to work with business stakeholders in the kitchen appliance team as well as other divisions to address shared opportunities, capability overlaps, and strategic prioritization. He will be expected to collect current state information models, system models, technology models, and business strategies for the EA repository. He will be measured on his ability to deliver on these expectations.
Case 2: Jai
Jai is working with the automotive division. This is the newest division in Fabrikam, and they are just beginning to roll out their first set of after-market automotive radios and CD players in the North American market. Their IT division is small and rather chaotic. Their architectural maturity is Level I. Jai has been working with the automotive division for about two years, and has repeatedly earned recognition from their business leaders for his skill and depth of knowledge. The maturity of the engagement is “Influential".
The intersection of these axes has the following text:
- Demonstrate EA specific methods and deliverables
- Drive the scoping, approval, and oversight of an enterprise-relevant project
Maria can set expectations with Jai and with the automotive division. Jai is expected to demonstrate EA specific methods and deliverables. The teams know him and trust him. He can demonstrate how EA can be valuable by simply doing the work and showing how valuable the results are. Due to his level of influence, he can work with the business to invest in an area of improvement that will benefit the entire enterprise (for example, a project to improve the distribution of finished goods to retailers), and then work with the IT teams and business stakeholders involved to get the project launched and oversee its development. Jai can be measured on his ability to deliver on these expectations.
In small organizations, Enterprise Architects can be “heros” and just “do what works,” but if you are trying to develop a mature EA program, each architect needs to have specific goals and specific deliverables that they will be expecte
d to deliver. This kind of model, we found, is useful for helping each architect to position themselves and their role in the organization.
Recently, I was contacted via this blog by an individual who had been challenged to set up a new Business Architecture practice within his company’s Enterprise Architecture team. He reached out to me to ask about some books to read and some advice. I’m expanding my message to him here. As always, I’d love to hear your comments and feedback.
You have quite a challenge ahead of you. While it may seem obvious, there are some steps that you need to do first. You have to essentially manage the change that you are bringing to your own organization.
- Value Proposition: Get together with your sponsor and create your charter. This is critical to having a clear goal that you will achieve, and clear measures by which you will achieve them. I cannot underestimate the importance of this step. Do not skip.
- Engagement Model: Create a clear and simple process for deciding what your team will focus on and how you will find the right opportunities to attack. This is your engagement model. Formalize it, and stick to it. You will be pulled in every direction. Clear simple criteria is your only defense against being scattered to the wind.
- Clearly define your service: what deliverables will be produced, and which individual stakeholders are going to be expected to use those deliverables, at what time, to what end.
- Stakeholder buy-in: With the help of your sponsor, meet one on one with each of these key stakeholders and make sure that they understand your value proposition, resources, and process impacts. You may be changing the lives of some key people. Get their buy-in. Be prepared to rewrite the value proposition. The value you deliver must be tied to the needs that they express.
- Scorecard: Hold yourselves accountable. Create a scorecard and use it with your team to demonstrate how progress should occur, and use it with your leaders to show how value has been delivered.
- Staff Training: Send everyone to a training class in Business Architecture… not so that they are all educated, but so that everyone is educated on the same terms, artifacts, and processes. This is the most difficult one to offer advice on because I have not yet found many good options… then again, we have an internal team that has answered the call, so I have not lately looked. Perhaps good options exist.
As far as required reading… specific to the BA practice challenge
The list below is intentionally short. I feel that every member of the team should read each of these books. I placed them in order of usefulness for your task at hand (preparing the staff of a new BA function within an EA team). All are very valuable… but being higher on the list means that I consider the book to be more valuable, sooner, than the ones below.
- “Business Architecture: The Art and Practice of Business Transformation” by Neil McWhorter and William Ulrich
- “Crossing the Chasm” by Geoffrey Moore
- “How to Measure Anything” by Douglas Hubbard
- “Enterprise Architecture as Strategy” Jeanne Ross and Peter Weill
- “Competitive Advantage” and “Competitive Strategy” by Michael Porter
- “Make It Stick” and “Switch” by Chip and Dan Heath
For the team manager, one more book to be read concurrently with the ones above:
- “Business Architecture: An Emerging Profession.” Paul A. Bodine and Jack Hilty
OK… I have probably just angered some of my friends, because I didn’t include all of their books or reference materials in my short list. Please, before you flame me, realize that this response is to a specific individual with a specific problem. The EA team existed, but didn’t have a BA function… what does that tell you? That it is an EITA team, in all likelihood. Is every possible book or resource appropriate for that situation? Probably not. So I selected a small set of valuable books. There are many more out there.
OK… I’ll say it. The whole idea of an Architecture Review Board may be wrong-headed. That officially puts me at odds with industry standards like CobiT, ongoing practices in IT architecture, and a litany of senior leaders that I respect and admire. So, why say it? I have my reasons, which I will share here.
CobiT recommends an ARB? Really?
The CobiT governance framework requires that an IT team should create an IT Architecture board. (PO3.5). In addition, CobiT suggests that an IT division should create an IT Strategy Committee at the board level (PO4.2) and an IT Steering committee (PO4.3). So what, you ask?
The first thing to note about these recommendations is that CobiT doesn’t normally answer the question “How.” CobiT is a measurement and controls framework. It sets a framework for defining and measuring performance. Most of the advice is focused on “what” to look for, and not “how” to do it. (There are a couple of other directive suggestions as well, but I’m focusing on these).
Yet, CobiT recommends three boards to exist in a governance model for IT. Specifically, these three boards.
But what is wrong with an ARB?
I have been a supporter of ARBs for years. I led the charge to set up the IT ARB in MSIT and successfully got it up and running. I’m involved in helping to set up a governance framework right now as we reorganize our IT division. So why would I suggest that the ARB should be killed?
Because it is an Architecture board. Architecture is not special. Architecture is ONE of the many constraints that a project has to be aligned with. Projects and Services have to deliver their value in a timely, secure, compliant, and cost effective manner. Architecture has a voice in making that promise real. But if we put architecture into an architecture board, and separate it from the “IT Steering Committee” which prioritizes the investments across IT, sets scope, approves budgets, and oversees delivery, then we are setting architecture up for failure.
Power follows the golden rule: the guy with the gold makes the rules. If the IT Steering committee (to use the CobiT term) has the purse strings, then architecture, by definition, has no power. If the ARB says “change your scope to address this architectural requirement,” they have to add the phrase “pretty please” at the end of the request.
So what should we do instead of an ARB?
The replacement: The IT Governance Board
I’m suggesting a different kind of model, based on the idea of an IT Governance Board. The IT Governance Board is chaired by the CIO, like the IT Steering committee, but is a balanced board containing one person who represents each of the core areas of governance: Strategic Alignment, Value Delivery, Resource Management, Risk Management, and Performance Measurement. Under the IT Governance Board are two, or three, or four, “working committees” that review program concerns from any of a number of perspectives. Those perspectives are aligned to IT Goals, so the number of working committees will vary from one organization to the next.
The key here is that escalation to the “IT Governance Board” means a simultaneous review of the project by any number of working committees, but the decisions are ALL made at the IT Governance Board level. The ARB decides nothing. It recommends. (that’s normal). But the IT Steering committee goes away as well, to be replaced by a IT Steering committee that also decides nothing. It recommends. Both of these former boards become working committees. You can also have a Security and Risk committee, and even a Customer Experience committee. You can have as many as you need, because Escalation to One is Escalation to All.
The IT Governance board is not the same as the CIO and his or her direct reports. Typically IT functions can be organized into many different structures. Some are functional (a development leader, an operations leader, an engagement leader, a support leader, etc.). Others are business relationship focused (with a leader supporting one area of the business and another leader supporting a different area of the business, etc.). In MSIT, it is process focused (with each leader supporting a section of the value chain). Regardless, it would be a rare CIO who could afford to set up his leadership team to follow the exact same structure as needed to create a balanced governance model.
In fact, the CIO doesn’t have to actually sit on the IT Governance board. It is quite possible for this board to be a series of delegates, one for each of the core governance areas, that are trusted by the CIO and his or her leadership team.
Decisions by the IT Governance board can, of course, be escalated for review (and override) by a steering committee that is business-led. CobiT calls this the IT Strategy Committee and that board is chaired by the CEO with the CIO responsible. That effectively SKIPS the CIO’s own leadership team when making governance decisions.
And that is valuable because, honestly, business benefits from architecture. IT often doesn’t.
So let’s consider the idea that maybe, just maybe, the whole idea of an ARB is flawed. Architecture is a cross-cutting concern. It exists in all areas. But when the final decision is made, it should be made by a balanced board that cares about each of the areas that architecture impacts… not in a fight between the guys with the vision and the guys with the money. Money will win, every time.
I’ve been looking at different ways to implement the ATAM method these past few weeks. Why? Because I’m looking at different ways to evaluate software architecture and I’m a fan of the ATAM method pioneered at the Software Engineering Institute at Carnegie Mellon University. Along the way, I’ve realized that there is a flaw that seems difficult to address.
Different lists of criteria
The ATAM method is not a difficult thing to understand. At it’s core, it is quite simple: create a list of “quality attributes” and sort them into order, highest to lowest, for the priority that the business wants. Get the business stakeholders to sign off. Then evaluate the ability of the architecture to perform according to that priority. An architecture that places a high priority on Throughput and a low priority on Robustness may look quite different from an architecture that places a high priority on Robustness and a low priority on Throughput.
So where do we get these lists of attributes?
A couple of years ago, my colleague Gabriel Morgan posted a good article on his blog called “Implementing System Quality Attributes.” I’ve referred to it from time to time myself, just to get remind myself of a good core set of System Quality Attributes that we could use for evaluating system-level architecture as is required by the ATAM method. Gabriel got his list of attributes from “Software Requirements” by Karl Wiegers.
Of course, there are other possible lists of attributes. The ISO defined a set of system quality attributes in the standard ISO 25010 and ISO 25012. They use different terms. Instead of System Quality Attributes, there are three high level “quality models” each of which present “quality characteristics.” For each quality characteristic, there are different quality metrics.
Both the list of attributes from Wiegers, and the list of “quality characteristics” from the ISO are missing a key point… “Time to release” (or time to market).
The missing criteria
One of the old sayings from the early days of Microsoft is: “Ship date is a feature of the product.” The intent of this statement is fairly simple: you can only fit a certain number of features into a product in a specific period of time. If your time is shorter, the number of features is shorter.
I’d like to suggest that the need to ship your software on a schedule may be more important than some of the quality attributes as well. In other words, “time-to-release” needs to be on the list of system quality attributes, prioritized with the other attributes.
How is that quality?
I kind of expect to get flamed for making the suggestion that “time to release” should be on the list, prioritized with the likes of reliability, reusability, portability, and security. After all, shouldn’t we measure the quality of the product independently of the date on which it ships?
In a perfect world, perhaps. But look at the method that ATAM proposes. The method suggests that we should created a stack-ranked list of quality attributes and get the business to sign off. In other words, the business has to decide whether “Flexibility” is more, or less, important than “Maintainability.” Try explaining the difference to your business customer! I can’t.
However, if we create a list of attributes and put “Time to Release” on the list, we are empowering the development team in a critical way. We are empowering them to MISS their deadlines of there is a quality attribute that is higher on the list that needs attention.
For example: let’s say that your business wants you to implement an eCommerce solution. In eCommerce, security is very important. Not only can the credit card companies shut you down if you don’t meet strict PCI compliance requirements, but your reputation can be torpedoed if a hacker gets access to your customer’s credit card data and uses that information for identity theft. Security matters. In fact, I’d say that security matters more than “going live” does.
So your priority may be, in this example:
- Testability, and
This means that the business is saying something very specific: “if you cannot get security or usability right, we’d rather you delay the release than ship something that is not secure or not usable. On the other hand, if the code is not particularly maintainable, we will ship anyway.”
Now, that’s something I can sink my teeth into. Basically, the “Time to Release” attribute is a dividing line. Everything above the line is critical to quality. Everything below the line is good practice.
As an architect sitting in the “reviewer’s chair,” I cannot imagine a more important dividing line than this one. Not only can I tell if an architecture is any good based on the criteria that rises “above” the line, but I can also argue that the business is taking an unacceptable sacrifice for any attribute that actually falls “below” the line.
So, when you are considering the different ways to stack-rank the quality attributes, consider adding the attribute of “time to release” into the list. It may offer insight into the mind, and expectations, of your customer and improve your odds of success.