Chapter 1.1 - Introduction of enterprise architecture
Introduction
The fundamental concept of Enterprise Architecture Management (EAM) is illustrated in the schematic shown in Figure 1.1. This concept begins with an enterprise which possesses a strategic vision and defined corporate goals. Typically, these goals are linked to delivering a product to the market through the execution of various business operations. Implementing these operations necessitates the involvement of personnel, assets, and an organizational structure. Essentially, the primary aim of an enterprise is to generate revenue through product sales. This operational model is the backbone of the company and must be the driving force behind the corporate information technology. While this may seem obvious or even simplistic, as all departments must collaborate to fulfill corporate goals, the fundamental principle is that information technology should facilitate the business in making money and achieving success.
However, in observing large-scale enterprises, it becomes apparent that IT departments have evolved to form a distinct culture, viewing themselves as separate entities. They tend to concentrate on information technology and their specific concerns, which leads to a detachment from the actual business activities. Multiple factors contribute to this misalignment:
- IT departments are evaluated on their ability to implement technological solutions, not on meeting business objectives.
- Information technology is often seen merely as an ancillary function, separate from the core value chain (a symptom of ‘silo’ thinking).
- IT professionals excel at creating and deploying information systems but frequently fail to grasp the full value that information technology brings to the company.
It is at this juncture that EAM comes into play, aiming to bridge the divide between business operations and IT. Our goal is not just to focus on technology and processes in isolation but to consider all relevant concepts collectively, ensuring that information technology effectively supports business processes with the highest quality standards.
Enterprise Architecture
Imagine this: In software engineering, we start by understanding business requirements and then develop a system to meet those needs. Enterprise Architecture (EA), however, takes a wider lens, considering the entire company rather than a single IT system. To illustrate, let’s compare EA to town planning. Just as every software system is made up of interrelated modules, a town consists of interconnected infrastructures. But EA introduces a new perspective.
Enterprise Architecture vs. Software Architecture
This town planning analogy is a staple in EA discussions. Think of a software architect as someone who designs individual houses or a cluster of them, much like a university campus. In contrast, an Enterprise Architect is akin to a town planner, responsible for the overarching infrastructure of a town or city, ensuring accessible streets, public transport, and water supply, and setting building regulations that house architects must follow.
Software architects focus on the specifics of a system: implementation details, project management. Meanwhile, the Enterprise Architect oversees a company’s processes and the collective operation of all software systems, akin to a town planner’s bird’s-eye view of the city, not the intricate details of each house.
In a large city, town planning may involve collaboration with district representatives, similar to how corporate IT could be segmented into domains like customer relations, production, and finance IT. Each domain is specialized, yet part of the broader corporate structure.
The Details Matter
The software architect’s role is deeply detailed, from the location of doors and windows to the color of walls. These are inconsequential to the town planner, whose concern is the city’s infrastructure. Similarly, the Enterprise Architect maintains a high-level perspective, distinct from the software architect’s detailed focus when crafting a software system.
Commonalities and Differences in Town Planning and EAM
Complex systems like a town or a corporate IT landscape share common ground: they are dynamic, expanding entities that must align with increasing infrastructure demands or business growth. Both involve living systems and require ongoing planning and adaptation.
However, software applications present unique challenges. They’re intangible and their interconnections often invisible, making it difficult to grasp their complexity or explain their dependencies. Moreover, IT’s role in business is often underestimated, seen as a mere support function rather than integral to business strategy.
Bridging Gaps and Taking Responsibility
The final hurdle is the business-IT divide. Software systems are used in business, yet business stakeholders frequently shirk responsibility for them. IT is tasked with maintenance and change management without true business ownership. Overcoming this requires a change in mindset, recognizing the business relevance of each IT system and establishing clear business ownership for decision-making.