Enterprise Architecture Q&A : How important is it for an Enterprise Architect to have business domain knowledge?

Here are a few Questions on Enterprise Architecture that I answered recently.

How important is it for an Enterprise Architect to have business domain knowledge?

There is no doubt that an Enterprise Architect must have EXCELLENT technical knowledge. Usually an Enterprise Architect is a person who has worked as Application Architect in the past, sometimes in various applications for business domains such as Telecom, Finance or Insurance. In this role, the person concentrates on using technical skill to build an application. This person is unlikely to concentrate on building business domain knowledge (also called functional knowledge) and only learning it to build the application.

Meanwhile a Business Analyst (BA) concentrates only on gaining business domain knowledge. A Business Analyst provides the business input required by the Application Architect. 

Does an Enterprise Architect need to have excellent knowledge of business domain? If so, how can this person gain it they have been working as an Application Architect in the past?

Yours is a multi-part question.

Enterprise architects could come from an IT background, in which case the EA will have “have EXCELLENT technical knowledge” (as you mentioned.) However, many Enterprise Architects also come from management consulting, Business Partnering and from business functions. Such Enterprise Architects will have extensive business domain knowledge.

Let us look at your other questions:

• Does an Enterprise Architect need to have excellent knowledge of business domain?

Yes, a knowledge of business domain certainly helps. However, the term “excellent” is a bit of a misnomer, especially for large, complex businesses with many lines of business or operations across geographies. In such organizations, breadth of knowledge of business operations and domains will help more than an endless pursuit of depth in all domains

• If so, how can this person gain it they have been working as an Application Architect in the past?

When I was hired as an EA for a multinational Ag-Chemical company, I had little knowledge of the complex supply chain of chemicals (pesticides, herbicides and insecticides) or the complexities in GMO or breeding of seeds. (Check out my blog on the topic)

I began attending appropriate training and 101-orientation sessions on the business -business models and continue to learn during my engagements with functional stakeholders.

---

Which is the best EAI tool?

If you can tell me the best Car I can buy, then I can advice you on the ‘best EAI tool’

If you think I am being cheeky, think again. Buying a car is highly context sensitive. Unless you know me and my needs, and requirements, your advise is going to highly subjective and useless!

In the same way, your adviser will need a lot of information on your context, landscape and requirements before s/he can suggest the ‘best EAI tool’ for your organization’s needs!

---

Can you effectively practice as a Enterprise Architect or a Solutions Architect without the ability to code?

Even my 7-year-old is ‘learning to code’ at school. So I will assume the OP implies “ability to write production ready code using the processes, tools and techniques used in the organization.” Using this assumption, my answer is simple:

• Enterprise Architect - Yes, you can effectively practice as a Enterprise Architect without the ability to code.
• Solutions Architect - A qualified Yes for this role too.

Why do I say this?

Enterprise Architects could come from any of the BIDAT domains and only those from an ‘A’pplication background may know to code. Even assuming an EA came from an application development background with hands-on coding experience, s/he may not be proficient in the newer languages and programming paradigms.

Executives who let their Enterprise Architects roll-up their sleeves and code are not making the best use of their (the EA’s) talent.


Solutions Architects are expected to bring a depth of the Application life cycle including development and integration. Many of them may also have a ‘coding’ background, but the ability to visualize and communicate solutions is more important than the ability to code. In smaller organizations, it is not unusual for the SA to sit with developers to prototype and validate solutions.