Too many business leaders dismiss architectures because they’re too complicated and/or appear too focused on information technology. Our challenge is to create understandable architectures with the right balance of business and technology focused on delivering important enterprise outcomes. Many believe the separation of business architecture and technology architecture as the solution. However, separation of these architectures greatly diminishes the fundamental purpose and value of an architecture.
Before I discuss the relationship of business and enterprise architecture (EA), let’s review a few important definitions. These definitions are not mine; rather, sources include Dictionary.com, Merriam Webster, among others and are crafted from definition patterns from multiple sources. Important definitions include the following:
Enterprise: a business or company; entrepreneurial economic activity.
Business: an organization or economic system where goods and services are exchanged for one another or for money.
Architecture: the carefully designed structure of something.
System: a group of devices or artificial objects or an organization forming a network specially for distributing something or serving a common purpose—ex., telephone system, heating system, highway system, computer system.
Capability: people, processes, and technology delivering value for a specific purpose. The quality of being capable; to have the capacity or ability to do something, achieve specific outcomes, effects, or declared goals and objectives.
There’s not much distinction between the definitions of enterprise and business. They’re both economic activities relevant to exchanging goods and services. Therefore, according to the definition, one can conclude that business architecture and enterprise architecture are the same thing. However, they are not. They each serve an important distinction.
We frequently use the term business to also mean an immediate task, objective, or mission—not the enterprise itself; rather, the operations of the enterprise. In most enterprises, operational folks execute the mission and technology folks provide automation products and services to assist mission accomplishment. Typically, operational people create business architectures frequently referred as operational architectures to establish vision, goals, measurable objectives, and capabilities to accomplish their mission.
Successful enterprises perform these activities even if they don’t call them architectures. Business activities frequently include the documentation of business processes to increase efficiency, integrate cross-department activities, and ensure clear identity of roles and responsibilities. Ideally, technology people follow the business architecture to create system or information technology architecture with the purpose of assisting business operators with automation technologies. Here’s the frequent misinterpretation: operational people believe their business architecture is the underlying truth used to guide the enterprise (hence the frequent presumption it’s the enterprise architecture), and the technology people believe that operational people don’t understand technology and are incapable of creating a comprehensive, system, or technical architecture to describe technology services. The interesting thing is they’re both correct, and this points to the nature of the architecture challenge.
An architecture of the enterprise is a carefully designed structure of a business or company entrepreneurial economic activity. One can easily assert that these entrepreneurial or economic activities include people, processes, and systems working in harmony to yield important business outcomes. These structures include organizational design, operational processes producing value, and the systems used by people during the execution of their mission. Enterprise architects use the business-prescribed operational end-state (results of value) to guide (like a blueprint) the enterprise to accomplish its mission—frequently, the end-states include vision, goals, objectives, and capabilities. Can a business exchange goods and services without technology and survive? Of course not. Therefore, why would you exclude systems (technology) from your overall architecture (your enterprise architecture) and expect successful results? Enterprise architecture marries all architectures into one practice—the enterprise practice.
The enterprise architecture is neither the business architecture (operational viewpoint) nor the system architecture (technical viewpoint)—rather, the enterprise architecture is both architectures created in an integrated form, using a standardized method of design, and usable and consumable by both operational and technology people. It is the mission of the enterprise architecture to establish policy, method, and tooling of this practice.
Here’s a frequent confusion. Too many architectures (frequently called enterprise architectures when they’re actually system architectures) are too information technology focused. These architectures frequently lack contextual reference to the operational process and relationship (ties) to business vision, goals, objectives, and capabilities. Also, due to their complexity, these architectures lose the interest of noninformation technology business people, and these folks are paying the bills!
The overall success of achieving business outcomes requires a binding (integration) with the system architecture (ex., information technology); otherwise, the architecture is incomplete. In automotive terms, the steering wheel is not connected to the vehicle’s axle. These integrated bindings guide or steer the system architecture toward the processes and outcomes identified in the business side of the architecture. Architectures are blueprints used as a guide to build things—in many instances, information technology, but not always. Otherwise, what’s the purpose of the architecture? Analysis of the business side alone (typically the business processes and important outcomes) establishes a road map of what’s important to the business. However, this approach leaves gaping holes in the roles systems play toward these business outcomes. Without an architecture agreement between business people and systems people, developers have a free-for-all, which is where we are today. Many leaders place great hope in agile, which is the ultimate free-for-all.
Fundamentally, EA is a structure (both words and pictures) of the people, processes, and systems required to efficiently achieve important business outcomes of the enterprise. These structures are not the “as is” architecture; rather, they are the “to be” architecture. An enterprise architecture is a visionary blueprint of what the enterprise desires to be at some future state—much of the architecture, however, might be current depending on the maturity of your architecture practice. I remember a guest speaker at a Department of Defense enterprise architecture conference stating, “I only architect as much of the ‘as is’ process needed to architect the ‘to be’ process.”
I remember thinking, “He gets it.” I can’t remember the speaker’s name, but he greatly impacted my understanding of the value of architecture. As an example, traditional structural architects don’t create architectures of existing buildings—they create architectures of future buildings that become realized at some future date. The value of these blueprints (architectures) includes their ability to communicate across a large audience—ex., masons, carpenters, electricians, suppliers, etc.—to create the vision documented in the architecture. The same is true for an enterprise architecture.
A business architecture without an interface to the system architecture (frequently information technology but not always) is incomplete—even pointless. This approach is similar to creating a building architecture and leaving out the electrical system design. The electricians have a challenge wiring the building. They have to guess what they think it’s going to look like leading to much rework as they discover actual load requirements, unanticipated doorways, outlet placement, lighting, etc. after the work is done—not a good idea. An enterprise architecture establishes the results of value needed to architect not only the people and processes, but also the desired behavior of systems and information flow to achieve business results. Behaviors are the way systems dialogue with people—the expectations of systems (frequently information technology) responding to humans and their desired results. The system could just as easily include telephones, mechanical production devices, or some other system abstraction by its traditional definition—not just information technology.
An enterprise architecture is made up of the business, system, and technical standard architectures whose culmination are included in a well-architected process, yielding predictable and desired business results. The multitude of these results yield the goals and vision established by the business/operational portion of the architecture. To be successful, the enterprise architecture employs a standardized method of design to integrate the business, system, and technical architectures through documented (blueprinted) dialogue with both business and technical stakeholders of the enterprise. The resulting blueprints (enterprise architecture) establish a contract (documented agreement) with business and technical people to evolve to some desired future state. The architecture makes it clear what success looks like! The EA is also a living blueprint, in that the architecture is never done. Rather, EA is a continuous architecture—a cultural part of the way enterprises manage their business and how they communicate ideas with each other. A clever enterprise architect is skilled at building future and visionary blueprints that both business and technologists understand. This is the challenge.
Here we are, nearly 20 years after the term was first used, still debating what EA is and how to establish it. Not to mention the difficulty finding skilled and competent enterprise architects. Many enterprises don’t even know what questions to ask during an enterprise architect interview. This is evident every time I see enterprise architect job postings that appear to be eliciting for highly skilled developer-like positions overseeing highly complex enterprise systems. Too many enterprises designate highly technical people as their enterprise architect; when in fact, these folks are system experts and lack business analysis skills. Similarly, many enterprises view their lead business architect as their enterprise architect, but that person lacks system behavior skills. When in fact, the enterprise architect is a highly skilled business analyst, system behavior expert, and technology standardization leader. This is not an easy person to find, and most enterprises fail to place this role in a position of prominence and provide the needed leadership support. Without leadership support, EA is a doomed endeavor, no matter the skills of the people leading it.
For example, the chief enterprise architect frequently reports directly to the chief information officer. When in fact, the chief enterprise architect is peer (or higher) to the chief information officer. The chief information officer is responsible for the information systems and information technology standards—responsibility includes the system information architecture, which is a part of the enterprise architecture—but not the enterprise architecture itself. The chief enterprise architect is both the lead business analyst and the lead system engineer for the enterprise. Definitely large shoes to fill. In my opinion, there’s a successful chief enterprise architect in all top companies of the world, even if this role is not identified as such specifically. Someone is making operational and system integration happen, or they wouldn’t be on top—or their top status won’t last long. A&G
