The Three Characteristics of an Enterprise Architect

The Enterprise Architect, and technical architects in general, have only been recently recognized by business.  This is much in the same as recognition for true technical roles themselves became recognized by within the enterprise not so long ago.  There is has been much debate over what the role of an Enterprise Architect (EA) is, their skills, where in the organization they should reside and what are the responsibilities.  I present for your consideration, my point of view on the Enterprise Architect.  It has evolved over the creation of three world class EA consulting organizations and implementation of the EA function in six of the world's top brands.

Once, the joke was that CIO stood for "Career is Over", and now this is changing.  Technologist have been recognized and rewarded in the enterprise, as well as IT consultancies for value and relevance they bring.  Their relevancy has gone beyond keeping lights on in a data center or building the next web app.  Becoming a technical architect is a dedication to technology, understanding how to develop it, how to address key non-functional requirements (NFRs):

  • Scalability - How well will the system(s) scale under volume and load.  This includes what is known as horizontal and vertical scaling.  Horizontal means that the system will scale simple by adding more resource units (e.g., more servers). Vertical scaling is the increase of one or more resources (e.g., memory, CPUs)
  • Reliability - What is the elasticity or fault tolerance under multiple conditions and stimuli
  • Extensibility - Can the system's core functionality do more without rewrite
  • Flexibility - How well does the system respond to integration or implementation in different environments
  • Availability  - How dependable is the system uptime
  • Maintainability - How easy is it to maintain the code and components of the system
  • Usability - Are the interfaces intuitive and desirable

They must also understand how to develop these in business context. EA is not a pure technical discipline, there is a strong responsibility to extending the business.

One does not develop a series of applications and get anointed as an EA.  It is both a journey and an apprenticeship. Dedication to a technical career path is not easy and also not well recognized/rewarded in many organizations outside of tech start-ups.  Becoming an EA means at least ten years of developing (requirements gathering, designing and coding) systems at the department and enterprise level.  It's a complete understand of application development and the network infrastructure, data architecture as well as security concerns.  It means learning from network engineers, database administrators and having a deep understanding of business processes.  The discipline goes well beyond application development.  Good EA is an improvement or realization of a business goal.  The discipline is a merger of business and technology.  Some thoughts:

  • An application without a network is an engine without a chassis or roads to drive it on
  • Applications without data are engines without fuel
  • Applications without security is an engine without coolant
  • Applications without business understanding are like engines that cannot be steered

If asked what ten fundamental things a mission critical system needs for roll out, an EA should be able to explain those components quickly and with confidence.  I remember when I first took on the development of Cognizant's Architecture practice.  At the time (late 2002) few people knew what an architect was for what they would be responsible for.  The resumes we received ranged from design architects (buildings and landscaping, really!) to career developers. 

I propose there are three levels in career progression:

  • System Architect - Someone with deep proficiency in a single technology, its development and deployment
  • Solution Architect - Someone with deep proficiency in a horizontal stripe of an end to end solution. For example an applications that supports a single business function
  • Enterprise Architect - Someone who has built and delivered multiple enterprise class solutions

Then what about the Chief Technology Officer (CTO)? Are they too not EAs?  In my opinion, the answer is, yes.  CTO is a functional title for an Enterprise Architect charged with being primarily responsible for the development of an enterprise's, or in larger enterprises, technical strategy for a line of business or perhaps geography.

Then there are the people who are lightly technical and develop presentations about how a technology might be used.  I am not a fan of the Powerpoint Architect. These are folks who have a good deal of skills in developing presentations but were never or haven't been hands on with technology for many years. They are technical enough to know how to provide direction but not the technical depth or hands on expertise to actually do the work or determine is something has been designed/delivered with quality.  In my mind this is a valuable skill called a Technical Project Manager.  Architects must be the technical equivalent of a business owner. That is they should have enough depth to sell and develop the technology.  Imagine someone in the Retail line. They are responsible for deciding all of the brands across all of the products sold in their Retail outlets.  They may certainly have multiple buyers working for them but imagine you have the most senior engineer in an aircraft company who has never built or even flown a working helicopter, disaster!

What are the characteristics of an EA?

  1. Excellence in Delivery
  2. Deep technical technical Perspective
  3. Innovation that withstands market scrutiny


An architect must be hands on with technology and understand the complexity of the business. To be the advisor to the business they must not only understand a range of technologies (e.g., Microsoft, Java, Open Source, Legacy) but have a mastery of the implementation and "fit to purpose" for business goals. This is should be in two of the afore mentioned technologies. 


The EA must have developed systems that enhance the enterprise or business.  These are generally systems that drive the critical or market facing business and support it end to end.  The EA would have been the primary technologist and have designed the major components.

EAs will also develop "the Art of the Possible" that is what can be done with technical assets to meet or extend the business of the enterprise.  There is a strong entrepreneurial streak.  What exists is generally not good enough for them.


The EA was with the design and implementation from beginning through conclusion.  They reviewed and supported the development team in the creation of technical standards and frameworks. This includes a validation of the business requirements.  Each step along the way goes through a review to standards and match up with functional requirements.  A "building permit" process if you will.

Want to put these lessons to work for you?


I hope you have enjoyed this article.  I have purposely left out, the "where in the enterprise" does the EA reside.  That will be a topic for a future article.

I am working on the development of a larger community, that follows the criteria mentioned above.  This will become a series of articles that help develop the EA community.  I invite discussion and welcome your participation.





I would be intrested in knowing what metrics can be used to track the success of an enterprise archiect; are there performance measures that can be directly attributed to the role of an architect and that in turn to the success of the IT function.