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.

Enterprise Architecture Q&A : Is Enterprise Architecture still relevant in the Digital Age?

Here are a couple of questions that on EA from an online forum that I responded to 

Is Enterprise Architecture still relevant in the Digital Age?

Let us take the overly simplistic description of EA from Wikipedia “Enterprise architecture (EA) is "a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a holistic approach at all times, for the successful development and execution of strategy.”

This need for “conducting enterprise analysis, design, planning, and implementation, using a holistic approach” continues to be relevant in the digital age.

A strong EA based approach will guide the development of a strategy and roadmap for realization. More importantly, it will guide the execution of a digital strategy[1] too.

You may be interested in my article: What is Digital Strategy Execution? And what it means to IS Executives

---

How can I be an expert in enterprise architecture?

Let me change the premise of the question before trying to answer it. One doesn’t become an “expert in enterprise architecture” just like one doesn’t become an “expert in medicine” or “expert in law” or “expert in business”

Building on one of these examples, one becomes proficient in law, and gains expertise in a branch, say patent-law or criminal-law. After a lot of hard work and working in the trenches, one gets recognized as a good lawyer and perhaps an expert in patent filings.

Most Enterprise Architects are generalists in many of the BIDAT EA domains, while some may also be recognized as experts in a domain or sub-domain. For instance, An EA might be recognized as an ‘expert’ in Networking and Infrastructure with a strong background in virtualization and cloud hosting, while his peer in the organization may bring in expertise in transforming HR processes. By complementing their skills, they enhance the practice of EA in their enterprise.

If the question was “How do I learn more about Enterprise Architecture?” I can point you to several books, references and online forums on the topic. (ref: “Enterprise Architecture References”)

Why Application Portfolio Reviews and CMDBs continue to be expensive?

As the Enterprise Architect responsible for key IS applications, it generally comes down to me to guide and enable teams engaged in reviewing application portfolios. In my technology consulting days in the past, I had engaged in several “Application portfolio review” exercises for clients across industry domains.  In all these exercises, there is a common thread: high cost of such “application portfolio” data gathering exercise - in other words, a nice high-value billable engagement for consultants – that can add up in the context of large transformational programs, where understanding of “as is” landscape is a must have.


At the very basic level, the problem comes down to maintaining a verifiable, well maintained inventory of applications. Of course, for many uses, a simple “list” alone is not sufficient. Most of us who have been in the industry realize that for an application list to be useful, it has to inform a cross section of stakeholders looking for varied perspectives. Just a small subset:

• Enterprise Architects: Seek data on applications, application components, data and interfaces between them, and more importantly the business capabilities and functions enabled by such applications. Such inputs are also building blocks for “Roadmaps” that inform the implementation of business strategies and are also used in scenario planning and defining business cases.
• IS Architects and Others: Large technology transformation programs generally require an “impact assessment” to understand, and catalog the impact of changes in the existing application landscape. Typical questions include: How many applications in the landscape? How many applications supporting xyz process, who and how are the applications managed?
• IS Executives and leadership teams: Generally interested in support cost, technologies adopted and other dimensions that can inform TCO of application portfolios, including strategic use of software licenses, vendor negotiations and optimizing the use of infrastructure across the portfolios (Cloud strategies come to mind but delving deeper on the topic in this article will digress us)
• Operational and support teams: Managing the workflow of functional and technical changes and enhancements and propagating them through the application development life cycle.
• Vendor and strategic suppliers: Access to application portfolios can help them proactively suggest optimization or leveraging new product and solution capacities.
• Other uses: Include SoX compliance, responding to regulatory and audit requirements etc.

Reading thus far, you are probably right in wondering if CMDBs are the potential “silver bullet.”  Wikipedia defines “A configuration management database (CMDB)” :

“a repository that acts as a data warehouse for information technology (IT) organizations. Its contents are intended to hold a collection of IT assets that are commonly referred to as configuration items (CI), as well as descriptive relationships between such assets. When populated, the repository becomes a means of understanding how critical assets such as information systems are composed, what their upstream sources or dependencies are, and what their downstream targets are.”

A well-defined and managed CMDB tool may help an organization manage IT assets, including applications and infrastructure supporting them. Many tools also enable “auto discovery” of elements. An entire industry and consulting sub-segment of IT management focused on ITIL and IT operations has sprung up around configuring, supporting and managing CMDBs.
The gap – and perhaps opportunity – is when it comes to data about the business functional and capabilities enabled applications. These are generally defined in the product documentation (in case of COTS products) or in the functional specifications and design documents and need to be manually updated in the CMDBs. Even assuming an initial mapping of such data is accurate, the data generally degrades over time as the applications transform, functionality is added and technical and functional ownership changes.  Updating such changes in the CMDB is both expensive and resource intensive, as it is generally a manual process.
Unless managed with strong executive support, governance, and ongoing funding, the reliability of such data in the CMDB may degrade over time. Such lack of reliability may also weaken stakeholder confidence in the CMDB as the “single source of application information,” causing groups, divisions and transformational programs to begin managing their own lists in wikis, spreadsheets and other smaller ‘databases.’
In a way this is a classic example of being penny wise and pound foolish: by avoiding the cost of updating and maintaining CMDBs, the organization may end up spending a lot more in individual “application portfolio review” and “data gathering” exercises.
Notes:

1. These observations are based on review of CMDBs and application portfolio “lists” at large organizations spanning geographies and lines of businesses. Smaller organizations with smaller IT footprint and limited number of applications may not have the same issues
2. Many organizations have their own definitions of applications and technology platforms. (Wikipedia)  Hence, I have refrained from defining “Applications” in this writeup.

(Repost from LinkedIn Pulse)