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.

Tuesday, July 29, 2008

Pragmatic Services

It seems that the discussion about REpresentational State Transfer (REST) vs. SOAP as the preferred approach for service development is over for many people. There articles about SOAP being irrelevant seem less emotional and seem to lack the fevered pitch they used to have.

You look at the vendors though, and I don't see movement in this direction. One could review the offerings and speculate that a primary reasons vendors are spinning with SOAP is that have not figured out how to monetize REST. You talk with people developing RESTful systems and the point is they are solving business problems instead of using a technology. It turns the whole discussion towards solving a problem - what real SOA is supposed to do. I love that. That may be another reason the vendors are having trouble getting traction in this area; they need us to focus first on the technology stack.