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.
If your personality doesn't fit the bill, you will never climb the ladder succesfully; even if the mentioned issues are fullfilled! In the Netherlands we are working with an architecture assessment that gives indications whether you are able to grow in this direction and what is in your reach. For organizations it is a big indicator if investing in the individual is appropriate or not. After assessing over 200 architects we feel very strongly that certain personality trades and cognitive abilities have to be present tot start with. For further information pls mail me at marleenoldehartmann <at> gmail.com
Great post Nick!
From experience I've seen how some consultants can go on and on about EA using highly technical wording and causing "death by PowerPoint" with slides filled with diagrams that lead to no end.
I've seen clients nod their heads and exit the room saying "Huh"?
I strongly agree that soft skills can play a major part for any EA serious about the field especially when your prime support comes from CXO's who don't necessarily have or care about EA lingo.
I love how this post ties nicely with the previous one, story telling would be a definite plus in an architects Swiss army knife of skills.
This advice is well put, and reminds me of a diagram I have since lost the attribution for, simply stating that good enterprise architecture is that which satisfies the business needs of enterprise leadership.
Trust is everything in this, and only a visible progression of successes can (or should!) confer the level of trust that would lead executives to subject/entrust their goals to governance apparatus.