Aggregated enterprise architecture wisdom
So, full disclosure, I care about Wikipedia. Call me dumb, I know. Wikipedia has been described, alternatively, as the best platform ever invented for fostering useless arguments among ignorant people /and/ the most successful encyclopedia effort of all time. The truth, as always, lies between these extremes. Well, I’m part of a small team that…
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.
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:
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.
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:
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).
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.)
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.
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’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…
Business trends often tend to follow the patterns of cultural change. In the latter part of the 20th century, businesses developed an interest in fostering employee wellbeing, by installing such facilities as gymnasiums for staff use. This focus on staff … Continue reading →
Thanksgiving is truly one of the best holidays. Food, football, family. As I have young kids I find myself getting back to the basics of actually giving thanks. When I ask my kids what they are thankful for, I get all kinds of funny responses. When I ask myself what I am thankful for, I get more functional responses in my brain: I am thankful for working with talented people. […]
I think most can agree that enterprise architects have been getting more and more narrow in terms of the scope of planning that they touch. In reality, executives and decision makers need a single complete plan of action. They ask, “what do I need to do, how do I secure it, how much will it cost, and when can it be done?” As enterprise architects have drifted away from solution […]
In Enterprise Architecture, one of the most important aspects of the job is not only to communicate, but to lead change. In other words, it is great to have the data to point to a problem in an enterprise. It is better to help that enterprise overcome it by changing something (processes, technology, training, staff levels, departmental structures, roles and responsibilities, artifacts, governance mechanisms, etc). Change requires more than simple communication. It requires a kind of in-person, face-to-face, listening and hearing and absorbing interaction that is difficult or impossible over written mechanisms like e-mail, word documents, and powerpoint presentations.
Our technology has led us to the point, in modern business, that we consider outsourcing and remote work to be a net benefit for all involved, but each of these “distance” mechanisms introduces the RISK of poor communication. That risk is magnified when the person on one end of the line is hoping to change something that the person on the other end is doing. Change is harder across distance, and that difficulty becomes magnified when dealing with the array of different interactions that are needed at the enterprise level.
I wonder if the PC revolution, that brought us personal access to written communication, has created a deep reliance on written communication in corporate processes. I wonder, further, if that access to technology isn’t directly harming our ability to look a person in the eyes and communicate with them.
As a culture, we have moved from the age of face-to-face all the way to text-messaging-someone-in-the-same-room in the course of a single generation.
Enterprise Architecture is more difficult because of this shift in communication patterns. All forms of face-to-face communication are hampered by it.
Modern technology has done more to damage interpersonal communication than any other paradigm shift in human history.
This worries me.
As an architect involved in an agile implementation (my current gig), you can imagine how interested I was to see that there’s a new book on Agile Architecture, and perhaps how disappointed I was to see that it focused on SOA and Cloud. That’s not to put down SOA or the cloud. I’m a huge fan of both. But it wasn’t the area of agility that I was hoping that a book, with that title, would address. The misunderstanding was mine, not the authors. I haven’t read the book yet, but I’m sure I will.
That moment of misunderstanding crystallized a thought: how even a two word phrase like “agile architecture” had two completely different meanings. The opening scene of the movie “The Hobbit, An Unexpected Journey,” puts a rather humorous twist on this idea, when Gandalf introduces himself to Bilbo Baggins (who has apparently forgotten having met him as a boy).
Bilbo: Good Morning
Gandalf: What do you mean? Do you wish me a good morning, or mean that it is a good morning whether I want it or not;
Bilbo: <stunned silence>
Gandalf: Or that you feel good this morning; or that it is a morning to be good on?
Bilbo: All of them at once, I suppose.
Of course, in Enterprise Architecture, we have the same problem. Does Enterprise Architecture mean “the practice of using technology architecture at an enterprise-wide scale,” or does it mean “the practice of using architectural ideas to shape the enterprise itself?”
And after a bit of stunned silence, perhaps it means
“Creating an architecture to describe the externalities of an enterprise to set its context and improve the relationships it has with customers, partners, and suppliers?”
All of them at once, I suppose.
Having just re-watched the Hobbit movie on my morning flight, these bits connected up in my head.
I’m proud to be both an architect of agility (applying the principles of agility to the processes of a business so that the business achieves the ability to change its own processes in response to agile demands), as well as a person who can craft technology architecture that reflects the notion of agility itself (technology that can be set up to change rapidly in response to business events).
All of them at once, I suppose.
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.
What is collaboration? Why do people collaborate? Perhaps more to the point, why don’t they collaborate? How do we end up so often with what we’d have to call anticollaboration – the exact antithesis of collaboration? So I’m standing there in…
In 2011, and again in 2012, while preparing to cofacilitate with Ric Phillips1 a workshop about collaboration across an enterprise-architecture community of practice, we were reminded with jarringly clarity that the word collaboration is misunderstood and misused, and that unhelpful behaviours result from this misunderstanding and misuse. Under the banner of collaboration are in fact […]
What’s the best kind of place to do enterprise-architecture and similar work? What are the best environments, for which parts of the work? And why? This was a fun set of questions that came up in my Twitterstream earlier this…