Answers to Common Questions on Enterprise Architecture

Anyone who frequents EA-related conferences, webinars, discussion groups, and other open Q&A forums quickly discovers that there are questions that come up over and over again. Those asking the questions say they cannot find short, easy-to-consume, and direct answers to their questions from traditional research sources such as the Internet. They prefer to get personal answers to their questions and have the opportunity to engage in a discussion that is contextually relevant to their situation.

The following digest represents short answers to just a few of the questions frequently asked to the authors in the last year.

Question: Should enterprise architecture really be called “IT” architecture?

Answer: Most EA-related discussions, certainly those found on the Internet, tend to be about low-level technology issues, frameworks, modeling, or technology-driven adoption issues (what impact “cloud” will have on the enterprise, for example). While within the overall purview of the enterprise architecture function, those are mainly infrastructure/operations/development level concerns. If that is the limit to the scope of an organization’s foray into enterprise architecture, then what it is doing can justifiably be considered “IT” architecture.

Why is that the case? Fundamentally, the lack of business participation in, and any real discernible impact from, efforts in enterprise business architecture is the most glaring weakness of what most organizations call “enterprise” architecture today. If analysis, output, and direction are only focused on the three traditional technology-oriented domains of EA—data, applications, and infrastructure—then it is appropriate and accurate to call it “IT” architecture.

While there is no dispute that EA started out as an IT-centric approach, most definitions describe EA to be more of a business-strategy driven approach. If you truly are trying to “architect the enterprise,” then you must have an effective approach to and competent people involved in business architecture, as well as information architecture (separate from data and only suitably addressed by business people).

One suggestion for your company and to set the stage to grow into the fullest definition of EA: If you are really doing “IT” architecture, call it what it is. That will give you, and the industry, a chance to differentiate these two important aspects of architecture while providing a chance to grow into the broader approach that is EA.

And by the way, if you are really trying to architect the enterprise, the question should be: “How can we leverage cloud (or any other technology) to improve our business?” And the best way to figure that out is a partnership between those with an understanding of technology capabilities and those with an understanding of where the business would like to go.

Question: Should I become “certified” as an enterprise architect?

Answer: When we think of certification for a profession, we think of things like the Series 7 certification for investment brokers, or a CPA, or the bar exam for attorneys. All of these certifications are governed by state and national accreditation boards, are the same for everyone, and thus have a high degree of legitimacy and recognition.

EA certification meets none of those criteria, not to mention that there is still debate as to whether EA is actually even a profession at this point in time. There are several EA or IT architect certification groups, each with their own definition, approach, curriculum, levels, and criteria for becoming certified as an enterprise or IT architect. The Open Group offers both TOGAF and IT architect certification. The Center for the Advancement of the EA Profession (CAEAP) offers certification, as does the EA Center of Excellence (EACOE). The International Association of Software Architecture (IASA) offers an IT architect certification. IBM and Carnegie Mellon have also teamed up to offer certification, and there are other EA certifications as well, though not as well known.

While there are some similarities among these competing efforts, fundamentally none have the same definition for EA. The fact that each of these bodies is competing for candidates goes to the root of the issue—these certifications are not primarily intended to provide a basis of training for EA or IT architects, but rather to promote and provide revenue to the sponsoring organizations. Stay tuned, though, because like many elements associated with EA (such as tools, frameworks, and methods), continued maturation is evident. In the meantime, organizations and individuals alike need to understand the intent and purpose of a particular provider’s EA certificate, associated process, and how the provider tests for achievement.

Question: Would conducting an EA Maturity Assessment add value to my EA program?

Answer: Most current discussions on EA Maturity focus on backward-looking metrics and score them based on levels that are similar to the Capability Maturity Model (CMM) process improvement system developed by the Systems Engineering Institute at Carnegie Mellon University. Over the past several years, we have started to develop a different opinion about using CMM-type assessments for enterprise architecture processes. Here’s why:

1. CMM was originally developed for project-level systems engineering capabilities. While some of the concepts are applicable to an enterprise-level planning process, the measures of success are not. Systems engineering is more tangible such that improved process maturity results in more successful outcomes. The same is generally not true of EA.
2. After many years of experience conducting CMM-like assessments, it became clear that the exercise of collecting the responses to questionnaires aimed at rating EA capability maturity on a scale of 1 to 5 rarely resulted in any kind of consensus on levels of maturity. That exercise usually led to some valuable discussions, but the rating itself was far too subjective and inaccurate.
3. The measure of maturity itself tends to rise with age; however, the outcomes may or may not be improving as maturity increases.

The best answer for most organizations is that it is better to accept the subjective nature of EA and assess the capabilities of an EA program, not its maturity. The goal is to identify how effective the program is within the organization. The categories are similar to the ones that are traditionally seen in EA maturity, but adjusted to measure against a scale ranging from “significantly inhibits effectiveness” to “significantly enables effectiveness.”

This type of an assessment is a step forward in helping an EA team to better understand its opportunities for improvement, the obstacles to overcome, and its leverageable strengths. The best measure of success is still going to be the impact on shareholder value. Being effective is a surer path to increasing shareholder value than being mature.

Question: How does an EA group demonstrate value?

Answer: What value does the EA function provide to the enterprise? That question consistently ranks in the “top 10 list” of most frequently asked EA questions. The question, unfortunately, doesn’t lend itself to a simple answer. It is more often a matter of value being in “the eye of the beholder.” In other words, the answer to the question depends on who is asking and what answer they expect to hear based on their personal and professional interpretation of the word “value.”

A systematic, multi-part approach to addressing the value question can lend clarity. By classifying the various ways that EA groups contribute value and identifying the stakeholder communities and how they align themselves with those classifications, each organization can address the value question in terms that are meaningful to its particular stakeholder mix. Every organization always has multiple value expectations.

The weighting among various value contributors differentiates one organization from the next. The weightings will change as the EA function grows and evolves. To begin to answer the value question, let’s define three possible value contribution classes. These are focused not on what an EA function is but on what it does for the enterprise:
Project Support: In some organizations, value is defined exclusively by an individual’s direct contribution to the completion of project-oriented tasks. While one can argue as to what proportion of individual EA team member’s time is directly or indirectly linked to project tasks, and it will vary by role, skill set, and EA maturity, in the aggregate every EA team interested in long-term survival must make their contribution to project completion visible. After all, it is the rare organization that doesn’t perceive “getting things done” as the highest value component.

Strategic Direction: The “raison d’être” of an EA group is to understand the strategic direction of the organization and capture it into a future state representation that reflects the eventual achievement of that direction. For leaders that believe in EA, their expectation is that the EA organization will invest resources in creation of go-forward standards, patterns, platforms, models, and other representations. After all, an EA team cannot effectively and efficiently perform their “support projects” value contribution if they don’t have a basis to use in providing guidance.

Portfolio Transformation: It is a rare organization, indeed, that doesn’t suffer from the accumulation of past incremental additions to its asset portfolios (technology, solutions, information, etc.). Only upon retrospective analysis does an organization discover the burden those portfolios place upon it in the form of cost, resources, or inflexibility. Given the future state holistic perspective defined by an EA function, a significant value contribution of EA is to help guide portfolio transformations to shed excess or duplicate components and bring them into alignment with the go-forward wishes of the organization.

By analyzing how the EA function can contribute in each of these categories, and by thoroughly understanding the expectations of stakeholder communities in each, the EA team can strike a balance that will satisfy itself that it is doing the right things and demonstrate it to leadership as well.

Question: Is it important to develop and maintain traditional “domain architecture” documents?

Answer: Domain architecture documents are one of the most widely created, and probably the most misunderstood, of the various EA deliverables an EA team might have in its document repository. EA teams often have these documents in various states of disrepair, from perpetual draft, to a complete but out-of-date document, to a minimalist listing of product standards, to over-written tutorials on topics long ago commoditized or no longer relevant.

Are they important? The simple answer is that, yes, domain documentation can provide value if you understand who they are for and the purpose they serve, and then balance the level of effort in creating/maintaining them.

The primary audience for technical domain documentation is the EA group itself and its extended SME community responsible for the asset categories contained in the specific domain. As such, in and of themselves, any given domain document has prescriptive appeal primarily to those who select, operate, and maintain “platforms,” “networks,” “middleware,” etc. The primary content of domain documentation is design principles, categories, standards, products, and configurations, including specific use-case descriptions for when and how to select them.

Taken together, the collection of technical domain documents contain “parts” or “building blocks” and, through the use-case scenarios and design principles, become components of higher-order constructs like “patterns” (e.g., infrastructure or development) or “platforms” (e.g., application). These patterns deliver higher-order value, consumable in the direct construction of solutions. The domains, in turn, have foundational value because they inform the consistent creation of the patterns as common building blocks.

by George S. Paras and Tim Westbrock, managing directors of EAdirections. Paras is a widely recognized speaker, writer, and thought leader in enterprise architecture, strategy and planning, portfolio management, and IT governance with more than 26 years of IT and business experience. He is also editor-in-chief of A&G. Westbrock is a leading authority on enterprise architecture, enterprise portfolio management, governance, and organizational issues related to enterprise level planning. He has worked with 300+ companies in various industries and the public sector to mentor them in their approach to enterprise architecture.