Is Enterprise Architecture a Profession?

By Jason Uppal, QRS

I have been involved with the Enterprise Architecture (EA) industry for the past 12 years. If the number of open positions for Enterprise Architects is any indication, there are a great many vacancies for EA opportunities that are going unfulfilled. Every time we discuss how to close this supply and demand gap for architects, the same question arises time and time again – is Enterprise Architecture a profession or discipline? Having some insight to this question – if not a complete answer – will help us further define the curriculum, mentoring and process to develop architects.

The purpose of this blog is to discuss what makes a profession and how to apply this to Enterprise Architecture. The July-August 2010 Harvard Business Review explored a similar subject – Is management a profession or discipline? I would like to apply the same thinking to Enterprise Architecture and would welcome your comments.

What makes a Profession?

The HBR article outlined the following characteristics of a profession:

• Professions are made up of particular categories of people from whom we seek advice and services because they have knowledge and skills that we do not.
• We cannot judge the quality of information ourselves even after the actions according to the advice and/or service has been implemented.
• Since a professional is an expert and we are not, there is always an asymmetry of knowledge.

Scenario for Medicine as a Profession

Let’s apply these characteristics to a well-known profession such as a physician. After a four-year hiatus from marathon running, I asked my family doctor for advice on how to approach my training, the goal being that I just wanted to complete the marathon in less than four hours. He reviewed my physical condition, training plan and demeanour from past records and provided me with a training plan, nutrition plan and regular checkup schedule. During the training, he helped me understand how best to use the tools he provided. The final result, I completed the run in 3 hours and 45 minutes, without injuring myself, and still had enough strength to celebrate afterwards.

Situation Diagnostics – Could another physician have given me a different plan that would achieve the same results? The answer is perhaps yes, but as an information seeker I would have never known. I needed to trust my physician as the expert and that I did not have the expertise to judge the quality of his advice. This information asymmetry will permanently exist.

Scenario for an Enterprise Architecture as a Profession

Let’s apply similar scenario to an Enterprise Architect. Three years ago, I was asked by a manufacturing VP (George) to help upgrade his company’s aging manufacturing production infrastructure with a financially viable business case. For simplicity, let’s ignore other constraints for now. I studied the current situation, defined the target state, quantified the business benefit of being at the target state, validated it with key stakeholders, defined the transition map, created the architecture  — including total cost, benefits, risk and impact of the change on people. We presented the architecture and business case to the CEO in three slides and in seven minutes. He looked at both of us and said, “Are you telling me that you can solve the production problems at that price” – which was half of the anticipated price – “and deliver these benefits by this schedule?” The answer came, “Yes sir”. He immediately said, “George, we should do this program.”

Situation Diagnostics: I framed the problem, defined, implemented and exploited the capabilities to deliver the results at a certain cost and risk appetite. Would George – given his own abilities – be able to determine that the problem could have been solved for half the costs and less risk and impact to the organization? The answer is no, unless he asks another architect for a second review of the problem. This option is not very realistic in practice.

In conclusion, I would like to say that Enterprise Architecture is a profession where we define the role of Enterprise Architect as a person who takes responsibility for the definition and development of necessary Enterprise Capabilities required to achieve the goals and provide expertise based in leading the exploitation of those capabilities until the intended outcome is achieved. This is no different from what I asked my physician in the scenario above.

Are we ready to define and accept Enterprise Architect’s role as above? I welcome all feedback … negative and positive.

This post was originally posted to the QRS blog on April 16.

The profession of Enterprise Architecture is a subject that will be discussed in depth during The Open Group Conference, London, May 9-13, both in public sessions and during The Open Group Architecture Forum meetings. Join us in London for best practices and case studies on Enterprise Architecture, Cloud, Security and more, presented by preeminent thought leaders in the industry.

Jason Uppal, P.Eng. is the Chief Architect at QRS and was the first Master IT Architect certified by The Open Group, by direct review, in October 2005. He holds an undergraduate degree in Mechanical Engineering, graduate degree in Economics and a post graduate diploma in Computer Science. Jason’s commitment to Enterprise Architecture Life Cycle (EALC) has led him to focus on training (TOGAF®), education (UOIT) and mentoring services to his clients as well as being the responsible individual for both Architecture and Portfolio & Project Management for a number of major projects. Jason has found that education is only beneficial to those companies who can industrialize the EALC process – staff must be able to implement what they have learned. To that end, he lead a team of java software developers to develop an end to end industrialization product which encapsulates Enterprise Architecture, Portfolio and Project Management, Project Management and  IT Services Management processes. Implementing this software product, ITO, (www.itoProcesses.com.) permits companies to take full advantage of TOGAF® and any other custom processes which might already be in place within their organization.