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”)

Design Thinking: Beyond the hype

Those of us who frequently browse business and technology magazines and publications would have noticed a surge in headlines about “Design Thinking.” For instance, just this past Sunday, New York Times business section had an interesting cover story about “IBM’s Design-Centered Strategy to Set Free the Squares” When the media journals like the esteemed Harvard Business Journal dedicate cover stories to such technology or business buzzword, one can be sure C-level Executives are taking note. (“The Evolution of Design Thinking” HBR – September 2015).

During the past few years, consulting firms have been “investing” in building their Design Thinking skills and capabilities. The HBR article describes how

"The pursuit of design isn’t limited to large brand-name corporations; the big strategy-consulting firms are also gearing up for this new world, often by acquiring leading providers of design services. In the past few years, Deloitte acquired Doblin, Accenture acquired Fjord, and McKinsey acquired Lunar."

Offshore consulting services firms aren’t too far behind

“Infosys has already signed up 22 customers on its design thinking offering and will train 30,000 of its employees on design thinking by the end of the year to further boost growth in that consultancy service”
(TOI )
“For this year the company has announced a number of 100,000, but the long-term plan is to make sure all TCSers i.e., 324,935 will undergo this training.” (Rediff) 

Corporate leaders are taking note of this buzz over Design Thinking, which means an opportunity for those of us in the corporate world to cut through the hype.

Beyond the hype

Consultants and self-proclaimed gurus are yet to converge on common terminology. Definitions and terminologies vary in subtle ways, but most experts agree on a few common aspects, like having Personae, Users and user stories at the front and center of any design effort. For instance, Stanford’s D-School (link) highlights “Empathy” as the start of a design journey. 

Most experts, likewise, agree on the need to “Define” the problem, “Ideate” and evaluate options and alternatives before commencing with rapid prototyping and testing by the user; finally scaling up execution: developing what works better and faster. While these are easy enough concepts to understand, one cannot trivialize the practice in real life scenarios; if Design Thinking were that easy, would HBR devote a cover story to the topic?

So what does this mean?

Many of us have long used aspects of user-centric thinking, focusing on use-cases to highlight user requirements. The approach is straightforward: identify and understand the interactions between Actors (Personae ?) and systems to achieve their needs.  That said, agreeing on “Architecturally Significant Use Cases,” with stakeholders has been a perennial challenge, leading to the design of systems that partially meet the needs of users, or in some cases meet the need of only a small segment of users.
This is where Design Thinking techniques, if applied skillfully, can help bridge the gaps in our understanding of the user’s needs and wants. By empathizing with users, understanding their needs, and prototyping and validating with them early in development cycles, one can ensure that the limited resources are dedicated to scaling solutions that satisfy most of their needs.
In the past few years, I have observed several large programs adopting aspects of Design Thinking. For example, early identification of Personae and interviewing key users are intuitive and common enough. However, many of us are in early stages of adoption, and are bound to encounter challenges that may include:

• Diverging needs of Personae: The popular case study from “U.S. Department of Veterans Affairs’ Center for Innovation”  highlights the divergence in needs of Personae. The four Personae - LIFER, TRANSACTIONAL, JUST-IN-CASE and THE INFREQUENT – have widely diverging needs.  For corporate design teams, without the deep pockets of the federal government, designing to satisfy all the needs of these personae, with limited budgets can be a challenge.
• Business sponsors may not be users: Project sponsors - people with money - can be vocal about what they think users need. Sponsors may or may not understand user requirements, leaving the design team to wonder if sponsors also be included as distinct Personae
• Typical users may not be the most vocal: The most vocal and eloquent Personae being interviewed may not represent the views of his/her peers, requiring the design team to be creative in gathering inputs

• Organizational Culture: Organizational culture and internal dynamics may also dictate how Design Thinking can be applied. For instance in hierarchal organizations, where internal users are expected to manage with less-than-optimal solutions mandated by their leaders, design thinking needs to factor-in this constraint.

Please feel free to add to this list of challenges. And if you have used Design Thinking techniques in your corporate settings, please share your success stories too.

(Republished from my LinkedIn Pulse article)