Wednesday, July 30, 2008

The 3 Flavors of Enterprise Architect

I work in a very large company and I am the lead architect of one of the divisions. I have had various architecture positions at different companies and I have had this current role for more than a year. I work with some very smart architects who are organized to business domains or disciplines and we are working together very well. There are many other architects and architectural organizations that are not having similar success. We meet sometimes for lunch and sometimes we talk about what it means to be an architect. I realize some of you have just thrown your computers out the window or tried to commit seppuku with some powerpoint printouts, but I continue.

In my experience, I have seen thee classes of working Enterprise Architects. There are others who are in Enterprise Architect roles and I will have a fourth bucket for them, but I would point out that they are not functional architects in any capacity. The classification solidified for me when I thought about where people I know came from - what is their background. Then it all clicked. For your pleasure, and so I can remember them, here are the categories of working Enterprise Architects I have seen in the wild.

Operations => Enterprise Architect

This architect has a background in process and operations. They are good to great at running a meeting and good with schedules. They need a lot of help understanding some of the things that are discussed if the topics get too technical. The value this person brings is that they can make things run if they are surrounded by people who know the business and the technology. This person does have a difficult time in making those architectural decisions as they have to depend almost completely on others. If you can find a good one of these they can really help your team be more effective. If your whole team is made up of people with this heritage, look for a new job.

Q.A. => Enterprise Architect

This is the one I have seen the least and like the least. This group of people came through some sort of QA organization and specialized in compliance of some kind. They are typically good at knowing corporate policies or common standards. The weaknesses are similar to the above. This "breed" of Enterprise Architect became most clear to me when I watched this. I am sure the presenter in this video is a nice person, and she adds value to her clients, but people I know with this heritage have been a death knell for any project / program / initiative I have seen.

Tech Lead => Program Architect => Enterprise Architect

This one is the most interesting to me and possibly the most difficult to find. It is clear to me that one of the primary signs of a person who will be successful in this area (besides having deep technical skills) is in both thought process and discussion, they must have the ability to move between levels of granularity incredibly rapidly and communicate clearly while doing so. The successful EA from this background needs to be able to communicate effectively with technical leads, executives, business analysts, business customers and project managers all about the same topics in language they each understand and does not pander to them. Sometimes in the same meeting. I know very few technical people who can make this transition. Many great technical leads cannot get past speaking at a very detailed level in strategic discussions. They may try to dominate discussions with things they feel they can contribute that really have very little to do with the subjects at hand. I have never met anyone who learned this skill. The reason I like this one the best, and why I try to find people like this to work with is because, if they are successful in making this transition, they "get it". They know how things work and they can communicate clearly with anyone so that it makes sense to the person they are speaking with. They are also the one class of Enterprise Architect who can be neutral when deciding who to invite to a brainstorming session as they can tie all of the discussion and best thinking from across the enterprise together. They have the most value and the most power because they can use all of the best thinking in the enterprise and they can communicate back to the enterprise what the value of any particular initiative is.

Everyone Else => Enterprise Architect

I know many other people in Enterprise Architect roles in many companies and I can fairly safely say that none of them are operating in any "Enterprise-Architecture-Like" capacity. Sometimes people get put here as you would put someone on special projects. Stay away from these folks for anything important and help them where you can as they are fish in a galaxy that has no water.

I guess in a nutshell, my view of the value propositions of each are as follows:

Operations => Enterprise Architect: I can plan things and create and run teams really well. Where process will streamline I can add that.

Q.A. => Enterprise Architect: I can tell you that what you did does not meet compliance with something.

Tech Lead => Enterprise Architect: I can do things. I can work with the smartest people in the company to progress our portfolio.

Misc => Enterprise Architect: Self referencing null object. Help them find a place in the organization where they can be successful.

5 comments:

Adrian Campbell said...

This was an interesting post.

Personally I have never come across an Enterprise Architect with an Operations background, although I think that this type of Enterprise Architect would be useful for many organisations. The Operations viewpoint is a key input to overall business and IT strategies, but often this input only comes from a 'Manager' and not an Architect, and is consequently less valuable.

Many Enterprise Architects come from a Technical/Solution Architecture background where they have only ever been working at a project level, leading the development and integration of software solutions and are capable of deep diving into very technical domains and programming subject areas. These types are very critical at a project /solution level, but many organisations I have spoken to are less keen on them as Enterprise Architects, because they are not so good relating to the business and executive stakeholders or indeed anyone outside of the IT organisation. Often however they end up as Enterprise Solution Architects in a Technical Design Authority type of Enterprise IT Architecture team. Organisations that have these TDA kind of EA teams also tend to have completely separate Business Architecture teams.

For myself I class myself as in another category of Enterprise Architect - One that has come up the Systems Analyst/Business Analyst/Process Improvement/IT strategy/IT management route to becoming an Enterprise Architect.

I focus on Strategy, Business Architecture, Information Architecture and Application Architecture, but far far less on Technology and Infrastructure Architecture.

I find that my kind of Business Strategy/Business Architect kind of Enterprise Architect is becoming quite fashionable, even the more so since Technology and infrastructure is an outsourced commodity these days, and many application architectures are primarily integrated assemblies of COTS applications with just a few core business applications being developed by offshore development partners.

Todd said...

I found this post quite insightful. I am working to mature the EA program in my organization, but I seem to have come from a different background than most Enterprise Architects - an IT Infrastructure/Governance/process background. Due to the smaller size of the organization, there was an element of both Operations and QA to these roles.

I often find other so-called Enterprise Architects are really just Software/Solutions Architects that saw an EA title as a promotion, but have no enterprise view or aspirations toward such.


Todd.
eajournal.wordpress.com

Jeff Carlson said...

@adrian campbell

You know, I agree that coming from the BA / Strategic BA perspective could add some strength to an organization that I did not cover and I have not seen yet. Your comments are interesting in that they really highlight the criticality of communications, in the language of the customer, to any successful EA work. I agree with you whole-heartedly that nearly any tech lead I have worked with could not make that transition from working at that detailed level to being to work and think at higher, more abstract levels and tie that to the business in the language of the business.

I appreciate the thoughtful comment and I will keep an eye out for EAs with the BA / SBA background and see what I can learn from them. I think a good one could add a lot of value to a team and and organization.

Jeff Carlson said...

@todd

One of my favorite Strategic Enterprise Architects I have ever worked with has that Operations / Process background. Much of the success we have had can be tied to his approaches and style.

I agree that many of the PM=>EA, Sales=>EA, Marketing=>EA that I would put in that bucket of non-functional EAs are kept company by tech leads=>EA who were unable to make the transition and who are also non-functional in the role. I am the first to admit that it is hard and uncommon for a Tech Lead to be able to make that transition. You can see them miles away and can usually tell a good pragmatic and functional EA from the others based on one or two conversations.

I also appreciate the nuance of the smaller companies having the QA/Operations combined and usually in the same group. I have not seen this myself but this might be interesting.

Good luck building your team and I hope you can find a team that can take your organization in the direction that maximizes the business value / dollar proposition of your IT portfolio.

aka paddy, aka welshboy said...

hey, can you check out my blog? its still really new mind if i use some of your ideas? Console Stuff www.console-stuff.zoxic.com