I have read several blogs over the past few months arguing over the role of the Enterprise Architect.  Architect and architecture means many things to many people.  Here is my opinion of  what an Enterprise Architect (EA) is.

The EA is responsible for understanding the business mission, strategy, and processes and creating an IT technology strategy that enables the business to meet its goals.  In other words, the EA is responsible for making IT an enabler and not a cost center.

To accomplish this, the EA must excel is the following areas:

• Leadership
• Change management
• Communication
• Technology
• Business knowledge
• Financial analysis
• Business processes
• IT governance
• Infrastructure
• Security
• People management
• Negotiation
• Vendor management
• Presentation skills
• Coaching and mentoring
• R&D

Many self proclaimed EAs are extremely bright but lack in many of these areas.  Notice that programming skills was not mentioned.  If the EA is developing software, he/she is probably not fulfilling the role as described above.  The EA should have a staff of talented sr. developers who can turn the vision into solutions.

It takes a rare breed to fit the bill of an EA.  I have had the luxury of working with many brilliant developers and designers over the years.  Many of them struggle communicating technical topics to non technical people.  Others focus so much on technology that they fail to align technology with key business drivers.

I have read many blogs that slam EA's who do not code.  These folks obviously have a different definition of EA then the one I described.  My response to them is that there is a huge difference between being an architect and being an EA. 

There are many different types of architects.  I will categorize them into three groups: Solutions Architects, Infrastructure Architects, and Enterprise Architects. 

Solutions architects focus on one or more of the following areas of expertise:

• Software
• Data or Information
• Services
• Testing
• Integration

Infrastructure architects focus on one or more of the following areas of expertise:

• Networks
• Security
• Systems

The bigger the company, the more specialized the architects usually are.  Smaller companies may have architects who represent several of these areas while bigger companies may have an architect for each one of these areas.  The EA forms the strategy and direction while the solutions and infrastructure architects execute the plan.

So the next time you come across a blog where the author is slamming EA's who don't code, ask them what their definition of an EA is.  Let me clarify one point before this article shows up on many blogs and gets slammed.  The EA should know how to code and should have spent many years developing, designing, and managing technical projects.  So when I say that the EA should not be coding, that does not mean the EA doesn't know how to code.

With that said, the EA's focus should be on strategy and vision.  The architects below the EA should turn the strategy and visions into reality.  The architects that have many of the skills that I listed above should be groomed as successors to the EA.  The one's that prefer to stay strictly technical can have long successful careers in their area of expertise but should not be given the role of EA as I have defined it.

I'd be happy to hear your thoughts.  I am sure that some people will strongly disagree with me.  I am happy to debate this in a civil manner.

You do not have flash or javascript support.

Average (4 votes)

Reply
Digg this
Slashdot
Reddit
LinkedIn