As this book is focused on the enterprise level, it is expected to provide a few core points to understand enterprise architecture easily.

In my personal experience, it was confusing to understand the role of an enterprise architect because people used to refer to so many architectural roles and terms, such as architect, solution architect, enterprise architect, data architect, blueprint, system diagram, and so on. My work experience clarified the underlying concepts and motivated me to write this section.

In general, the industry perception is that an IT architect role is to draw a few boxes with a few suggestions; the rest is with the development community. They feel that the architect role is quite easy, just drawing a diagram and not doing anything else. As said earlier, it is completely a perception of a few associates in the industry. This perception leads me to a different view about the architecture role:

However, my enterprise architect job has cleared this perception and I understand the true value of an enterprise architect.

In simple terms, an enterprise is nothing but human endeavor. The objective of an enterprise is where people are collaborating for a particular purpose supported by a platform. Let me explain with an example of an online e-commerce company. Employees of that company are people who work together to produce the firm's profits using their various platforms, such as infrastructure, software, equipment, building, and so on.

Enterprise has the structure/arrangements of all these pieces/components to build the complete organization. This is the exact place where enterprise architecture plays its key role. Every enterprise has an enterprise architect.

EA is a process of architecting that applies the discipline to produce the prescribed output components. This process needs experience, skill, discipline, and descriptions. Consider the following image, where EA anticipates the system in two key states:

Every enterprise needs an enterprise architect, this is not optional. Let me give a simple example. When you need a car for business activities, you have two choices, either drive yourself or rent a driver. Still, you will need the driving capability to operate the car. EA is pretty similar to this.

As depicted in the preceding diagram, EA anticipates the system in two key states, which are as follows:

• How it currently is
• How it will be in the future

Basically, they work on options/alternatives to move from the current to a future state of an enterprise system. In this process, Enterprise Architecture does the following:

• Creates the frameworks to manage the architecture
• Details the descriptions of the architecture
• Road maps to lay the best way to change/improve the architecture
• Defines constraints/opportunities
• Anticipates the costs and benefits
• Evaluates the risks and values

In this process of architecting, the system applies the discipline to produce the prescribed output components.

Enterprise Architecture is so special because of its holistic view of management and evolution of an enterprise holistically. It has a unique combination of specialist technologies, such as architecture frameworks and design pattern practices.

Such a special EA has the following key stakeholders/users in its ecosystem:

Though many organizations intervened without EAs, every firm has the strong belief that it is better to architect before creating any system. It is integrated in a coherent fashion with a proactively designed system instead of a random ad hoc and inconsistent mode.

In terms of business benefits, cost is the key factor in the meaning of Return on Investment (RoI). That is how the industry business is driven in this highly competitive IT world. EA has the opportunity to prove its value for its own stakeholders with three major benefits, ranging from tactical to strategic positions. They are as follows:

• Cost reduction by technology standardization
• Business Process Improvement (BPI)
• Strategic differentiation

In the grand scheme of cost saving strategy, technology standardization adds a lot of efficiency to create indirect benefits. Let me share my experience in this space. In one of my earlier legacy organizations, it was noticed that the variety of technologies and products were built to serve the business purpose due to historical acquisitions and mergers.

All businesses have processes; a few life examples are credit card processing, employee on-boarding, student enrollment, and so on. In this methodology, there are people involved with few steps for the particular system to get things done. During rapid business growth, the processes become chaotic, which leads to duplicate efforts across departments. In turn, stakeholders do not leverage the collaboration and cross learning.

BPI is an industry approach that is designed to support the enterprise for the realignment of the existing business operational process into the significantly improved process. It helps the enterprise to identify and adopt in a better way using industry tools and techniques.

BPI was originally designed to induce a drastic, game-changing effect on enterprise performance instead of bringing changes in incremental steps.

In the current, highly competitive market, Strategic Differentiation efforts make a firm create the perception in customers minds of receiving something of greater value than is offered by the competition. An effective differentiation strategy is the best tool to highlight a business's unique features and make it stand out from the crowd.

As the outcome of strategic differentiation, the business should realize the benefits of Enterprise Architecture investment. Also, it makes the business institute new ways of thinking to add new customer segments along with new major competitive strategies.

When I planned to switch my career to the architecture track, I had too many questions in mind. People were referring to so many titles in the industry, such as architect, solution architect, enterprise architect, data architect, infra architect, and so on that I didn't know where exactly do I needed to start and end. The industry had so many confusions to opt for. To understand it better, let me give my own work experience as the best use cases.

In the IT industry, two higher-level architects are named as follows:

• Solution architect (SA)
• Enterprise architect (EA)

In my view, Enterprise Architecture is a much broader discipline than Solution Architecture, with the sum of Business Architecture, Application Architecture, Data Architecture, and Technology Architecture. It will be covered in detail in the subsequent section:

SA is focused on a specific solution and addresses the technological details that are compiled to the standards, roadmaps, and strategic objectives of the business. In comparison with SA, EA is a more senior level. In general, EA takes a strategic, inclusive, and long term view of goals, opportunities, and challenges facing the company. However, SA is assigned to a particular project/program in an enterprise to ensure technical integrity and consistency of the solution at every stage of its life cycle.

Let me explain the working experiences of two different roles--EA and SA. When I played the SA role for an Internet based telephony system, my role was to build tools, such as code generation, automation, and so on around the existing telephony system. It needed the skill set of the Microsoft platform technology and telephony domain to understand the existing system in a better way and then provide better solutions to improve the productivity and performance of the existing ecosystem. I was not really involved in the enterprise-level decision making process. Basically, I was pretty much like an individual contributor to building effective and efficient solutions to improvise the current system.

As the second job, let me share my experience in the EA role for a leading financial company. The job was to build the enterprise data hub using emerging big data technology.

If we plot EA versus SA graphically, EA needs higher degree of strategy focus and technology breath, as depicted in the following image:

In terms of roles and responsibilities, EA and SA differ in their scope. Basically, the SA scope is limited within a project team and the expected delivery is to make the system quality of the solution for the business. At the same time, the EA scope is beyond SA by identifying or envisioning the future state of an organization.

With the degree of experience, expertise, responsibility, and much more. EA is superior to SA. EA has the vision of end-to-end broader system knowledge; but SA is bound to a specific problem statement. In terms of enterprise role, EA role is pretty close to Chief Architect, whereas SA is at the Senior Architect level.

In the real-world scenario, the Enterprise Architecture Framework (EAF) inspires software development processes in the industry. It is essential to fulfill the mission of the associated enterprise.

In a nutshell, EA serves as the blueprint for the system and the project that develops it. An EAF can describe the underlying infrastructure, thus providing the groundwork for the hardware, software, and networks to work together.

With the usage of EAF, the organization will be in a situation to understand and analyze the weaknesses or inconsistencies to be identified and addressed. As per the fundamentals of computing, a framework is often a layered structure indicating what kind of programs can or should be built, and how they will interrelate.

To my knowledge, there are a few established EAFs available in the industry today. Some of them were developed for a very specific area, whereas others have a broader coverage with complete functionality.

In my view, there are two common types of EAFs used in the industry, which are as follows:

• General Purpose Framework
• Domain Specific Framework

As the name describes, these frameworks are designed by being agnostic to any specific implementation. They have no specific business drivers in terms of an enterprise specific scenario, but rather, they are capability based. Some of the well-known general purpose EA Frameworks are TOGAF and Zachman.

As self-described, these frameworks are derived from the common EA effort, in turn referred to as domain specific. By design, they are derived with a predefined set of business conditions and concerns because they may have originated from an Enterprise Architecture team or process improvement effort. On rolling out to the industry, these frameworks are mostly driven by government agencies or other geographies.

Based on the types of industry of the EA Frameworks, the type charter is depicted as follows:

By design, the EA Framework provides a conceptual framework to explain the following:

• How the key terms are related to each other conceptually for architectural description
• The following are the number of scenarios for the enterprise architectural activities during the software life cycle:
  • Evolutionary system
  • Existing architecture
  • Architectural evaluation
• The role of the stakeholders in the creation and use of an architecture description

In this book, we will cover the foundations of two commonly known, general purpose EA Frameworks, which are as follows:

• TOGAF
• Zachman Framework

We will look into their details after the layers of Enterprise Architecture section as follows:

In 1992, Steven H. Spewak defined Enterprise Architecture Planning (EAP) as the process of defining architectures for the use of information in support of the business and the plan for implementing those architectures.

In highly distributed computing, a layered architecture is recommended for a simple reason--to allocate the different responsibilities of the system to the respective layers. With the same principle, Enterprise Architecture is built on the same layer design concept. It is inspired with the idea to execute the relevant processes and services of the layer and its related components. Take a look at the following image:

As defined in the preceding image, each layer, namely Business, Data, Application, and Technology, is designed to delegate its execution to the underlying layer. It means that the top layer, Business, is coarse-grained level, whereas the bottom layer, Technology, is a fine-grained level.

Business Architecture is nothing but a blueprint of the enterprise. It helps you understand the organization and supports you to align the long-term strategic objectives and short-term tactical demands. Basically, it is the bridge between enterprise strategy and business functionality, as depicted in the following image:

As shown in the preceding image, Business Architecture has three dimensions at its core--Strategy, Operation, and Technology. The success factors of a Business Architecture are directly proportional to the business transformation, using strategy, a stable platform via technology, and exhibited excellence in the business operation.

In essence, the key aspect of the represented business by Business Architecture is tabulated as follows:

Business Architecture is directly based on business strategy. By design, it is the foundation for subsequent architectures, where it is detailed into various aspects and disciplines of the business.

In my view, an ideal business architect delivers the framework of services and artifacts, which enables customers to rapidly deliver quantifiable business value with realistic, technology enabled, business solutions.

Data Architecture is the key contract between the business and technology in an enterprise. I experienced the value of Data Architecture during my tenure of the Enterprise Data Hub development initiative.

Data Architecture is designed in such a way that the real business data is handled smoothly across the layers of the enterprise architecture. It plays the key role/artifact to develop and implement governance supporting the enterprise data strategy. It collaborates/connects with the various enterprise objects, such as hardware, applications, networks, tools, technology choices, and data.

To support a variety of the commonly used enterprise applications and business improvement activities, the framework/layers of the Data Architecture is designed as follows:

As depicted in the preceding image, Data Architecture has three layers of components based on its operational strategy, namely Strategic, Tactical, and Operational. As self-described, most of the ground-level operations are executed in the lower components--Enterprise Application Integration (EAI), Business Intelligence (BI), and System Rationalization. Data is tactically architecture at the middle layer using the BPI program. The top layer of Data Architecture is getting involved in the Data Strategy of the underlying enterprise.

Let me illustrate with a real life example to easily understand enterprise data architecture. Our business use case is to build the inventory management system of a production factory. Consider the following image:

As depicted in the preceding image, the inventory management workflow is aimed towards the process of supervising and controlling stock items for the production in an efficient way. Let's get into the details of Data Architecture with this example.

In operation level, raw material information is fed into the inventory core system (Warehouse) in different formats/sources. EAI (tools such as Informatica) is the core component to ingest the incoming source data in a clean/expected layout. Rationalization is the process of extraction of the master data from the various systems of record of both internal and external systems. After processing, to produce the cleansed raw data using EAI and Rationalization in Warehouse, the BI layer takes the execution responsibilities. BI analyzes the enterprise's raw data from the various sources of the system.

Therefore, the lower operational layer of Data Architecture deals with the processing of inventory data from end to end, ranging from raw material to shipping the finished products. Thus, the operational layer cuts across the entire phase of the business.

The next tactical layer BPI is used to improve the existing business operation to accomplish significant improvement in production. In our use case, let's say the raw materials are sourced from various locations around the globe. In doing the various analysis methodologies, the BPI system can come up with an efficient way of sourcing the raw materials for the inventory. Of course, the existing raw data is essential for any prediction/analysis. Effective BPI generates promising results operational efficiency and customer focus, which in turn improves the productivity and profitability of the business.

By definition, enterprise data strategy is the comprehensive vision and actionable foundation for an organization's ability to harness data-related or data-dependent capability. To emphasize the importance of Data Strategy, let me share an interesting answer by Bill Gates of Microsoft. When he was asked a question--"What is the most important asset of your company?" he replied--"Data". In our use case, by doing Data Strategy of the inventory system, it drives the business to be a customer-centric data driven culture. In general, legacy systems produce data silos that will get in the way of understanding customers. This is a big challenge; without a Data Strategy, it is next to impossible for any inventory system. Due to the characteristic of relevancy, which is contextual to the organization, evolutionary, and expected to change on a regular basis, enterprise data strategy is essential to build the comprehensive strategies necessary to make a real difference for the organization.

In general, software application is designed to meet an organizational need in reality mode. As the business model is quite common in a similar industry, it obviously expects the software application to build with the common architecture to satisfy the business requirements of an enterprise. As a result, Application Architecture is built in a generic way to create the business system, which is required to meet the specific requirements of the business.

By definition, Application Architecture specifies the leveraging technologies. Technologies are easily used to implement information systems, such as data, processes, and interfaces. On top of that, Application Architecture describes the details of the internal components and the way they interact to build the complete information system.

In terms of the engineering principle, Application Architecture exhibits the execution steps and methods in the model of the system blueprint into the reality of the leveraging enterprise.

Applications are generally categorized in the following listed types, along with their related characteristics. The categorization is based on the nature of the business process:

Irrespective of the preceding types of application, Application Architecture is designed into the logical groupings of the software components. These logical layers help you differentiate between the different kinds of tasks performed by the components. In turn, the system is easier to support the design principle of reusability across the platform.

Each layer can be implemented as a large scale component running on a separate server. It is the most commonly used web-based architectural model in the industry. As a common practice, six layers are designed in the Application Architecture of the industry, which are as follows:

• End User Layer: This is an individual who uses the product after it is fully developed and marketed. This layer is around the usage pattern of the end user. As a result of rapid technology growth in recent times, the End User Layer is essential to build for desktop, web, mobile, pad, and so on.
• Presentation Layer: This contains the end user oriented functionality responsible for managing user interaction with the core system. In general, it consists of components that provide a common bridge between the end user and core business logic encapsulated in the business layer. Presentation Layer consists of UI components to render the user output and UI processor for local processing.
• Server Layer: This implements the core functionality of the target system by encapsulating the relevant business logic. In modern design, this layer consists of components, some of which may expose service interfaces that other callers can use. It is termed as the heart of the system.
• Access Layer: This layer is a bridge between the core business/server layer and the persisted store layer. It is designed using the best access pattern and practices of the enterprise architecture. It has two key components, namely the Data Access Component (DAC) and Service Gateway (SG). DAC allows programmers to have a uniform and comprehensive way of developing applications that can access almost any data store. The SG component encapsulates the low-level details of communicating with a service by means of service interfaces. Moreover, SG provides an ideal location to provide common features, such as asynchronous invocation, caching, and error handling.
• Persistence Layer: As the application data is persisted in this layer, it provides access to data hosted within the boundaries of the system and data exposed by other networked systems. By design, data is accessed through services in modern Application Architecture.
• External Layer: This layer is designed to expose the functionality of the application as the services to the external customer. API is the popular term in the industry, through which business services are exposed externally to earn the profit by sharing the best services.

In conclusion, Applications Architecture is the art and science of ensuring the suite of enterprise applications to create the composite architecture with the characteristics of scalability, reliability, availability, and manageability.

Technology/Infrastructure architecture principles are defined in collaboration with operational staff. It is the duty of the application architect to correct any wrong assumptions that the team might make with regard to enterprise infra architecture. Traditionally, it covers the servers, desktops, storage, network, and so on.

In the current distortive and emerging technology world, collaboration is the key for success. On connecting and cooperating with various groups, it is easy to adapt into the latest trends instead of reinventing the wheel again on our own. Technology Architecture is highly influenced by this principle.

On playing the enterprise architect role, my experience educated me to insist on a high degree of collaboration with other types of architects in the system. It is expected to have a closer working experience with a solution architect to roll out the implementation of the specific technology and platform as part of the role. In fact, architecture is not at all specifically associated with a particular release of the software. If so, then it is probably not considered architecture:

As depicted in the preceding image, Technology Architecture layers start from the Network layers of LAN, WAN, or Remote Access. On top of the Network layer, the Security principles are laid with Identity, Isolation, and Permission models. Storage layer is designed on top of Network and Security layers. Platform resides on top of the Storage layer and is the foundation for any type of software application, which reaches/touches the end customer. Take a look at the following model:

The Open System Interconnection (OSI) model is an interesting area in Technology Architecture. It defines a networking framework to implement protocols in seven layers. As the lower/deep technical details, control is passed from one layer to the next, starting from the Application Layer to the bottom most Physical Layer of bits. The communication passes over the channel to the next station and back up the hierarchy.

Technology Architecture deals with these various layers and its essentials.

TOGAF is one of the well-known leading Enterprise Architecture Frameworks used in the industry. As per the common goal, TOGAF is leveraged to make the enterprise for implementing and improving business efficiency. As the name stands, TOGAF insists the industry's architecture standard using the consistent methods, processes, and communication with the group of Enterprise Architecture professionals. In turn, the openness culture supports architecture practitioners to avoid the industry pain of proprietary lock mode.

TOGAF's first version was developed during mid-1990s and continuously maintained by it based on experience and exposure from the United States Department of Defense, namely Technical Architecture Framework for Information Management (TAFIM). Later, the forum started releasing successive versions based on the fundamental blocks. Consider the following image:

The preceding image is a view of the timeline for the growth of TOGAF until the latest version, 9.1. This illustrates the long maturation cycle.

As TOGAF has become more mature, the time period between publications has also increased.

TOGAF's core components construct the strong fundamentals of this open architecture framework. It is depicted in the following diagram:

The preceding diagram shows the structure in a graphical overview format calling out the main components, which are briefed as follows:

Architecture Development Method (ADM) is a kind of circular flow chart aimed to building an enterprise-level architecture. It has a set of resources and the related governance to support the enterprise applications development.

The Architecture Content Framework uses the following three categories to describe the type of architectural work product within the context of use:

• Deliverables
• Artifacts
• Building blocks

Deliverables are the output of the project to be agreed and signed off by the enterprise stakeholders. Artifacts are represented as the content of the architectural repository of the firm. Building blocks are commonly represented as the reusable components of the enterprise platform.

As we know, architecture repository contains the enterprise designs, policies, framework, and so on. Enterprise Continuum is the method or mode to classify the repository content.

TOGAF 9 provides an Architecture Capability Framework that is a set of reference materials and guidelines to establish an architecture function or capability within an organization.

TOGAF is highly adopted/used in the industry. The following statistical points make them pretty clear:

• More than 150k downloads
• Individual certifications near 60k, with foundation of 18k and certified of 42k
• Around 400 corporate members of TOGAF
• Over 60k TOGAF series books shipped
• Association of enterprise architects membership at more than 75k

The continental wide usage of TOGAF is depicted in the right-hand diagram, whereas the top-10 countries is on the left-hand side:

In the space of Enterprise Architecture, Zachman Framework is the veteran being the initial member. It was the brainchild of John Zachman during the year 1987. In the system journal of IBM, he released this technical paper in the name of--A framework for information systems architecture.

By design, Zachman Framework has the logical structure, which is intended to make the comprehensive illustration of an information technology enterprise. In fact, it exhibits the multiple perspectives and categorization of the business artifacts.

In 1987, John Zachman published a different approach to the elements of system development. Instead of representing the process as a series of steps, he organized it around the points of view taken by the various players of an enterprise.

In the history of Enterprise Architecture evolution, the Zachman Framework is the early-bird player, as depicted in the following image:

On analyzing the history, Zachman originally defined his IT taxonomy using the building domain/industry as an analogy. Interestingly, architectural artifacts are implicitly designed using a two-dimensional matrix in the building domain.

In a subsequent paper with Sowa, Zachman proposed a different strategy of six descriptive namely data, function, network, people, time, and motivation, and six player perspectives, namely planner, owner, designer, builder, subcontractor, and enterprise

By design, the Zachman Framework is represented in a 6 x 6 matrix, as depicted in the next image. On noticing, the table's column represents the interrogatives of the communication channel, namely What, How, Where, Who, When, and Why. At the same time, the row represents the philosophical concepts of reification, namely scope, model, design, build, and configuration.

The details of the Zachman Framework are clearly drawn in the following diagram:

With the support of the appropriate artifacts in every cell, it is pretty much very simple to depict the sufficient amount of detail. Zachman provided the following rules to assist the reader in understanding the system of the enterprise applications. Fundamentally, it contains six major rules, which are as follows:

1. The columns have no order
2. Each column has a simple, basic model
3. The basic model of each column must be unique
4. Each row represents a distinct perspective
5. Each cell is unique
6. Combining the cells in one row forms a complete model

After 26 years at IBM, John founded Zachman International as a company dedicated to the research and advancement of the state of the art in Enterprise Architecture by his principle. It helps the industry adopt his framework in a massive way, from a scientific perspective.

As the best practice in the industry, Enterprise Architecture is expected to have the responsibility to perform strategic steps in alignment with business vision. EA has few strong fundamental blocks, namely agility, durability, efficiency, and effectiveness.

EA is the discipline of addressing business needs with people, process, and technology, with the definition of the purpose, intent, and structure of any system.

In the next chapter, we will discuss the most commonly used fundamental design patterns and practices, being It is getting used on to build Enterprise Application across the industry.