The business ecosystem has become more and more complicated over time. Over the years, change has continued to be a constant, and businesses have increased in agility in order to better equip themselves for survival. Change in the business environment has generally come in the following forms:
Technological change that has revolutionized operations and introduced new business models
Increased competition from start-ups and legacy companies alike
Greater customer expectations
Changes in regulatory landscape
These factors have created complexity in the business ecosystem that must be navigated accordingly. For instance, there is no way your business can be certain how regulations may change in the next five years, but your business can make decisions today that will ensure that it will be flexible and agile enough to navigate those changes. Maintaining the ability to adapt to new business demands will not only ensure an enterprise’s survival but can ultimately lead to a competitive advantage.
As mentioned, there is no way to predict most of the changes an enterprise will encounter; however, Enterprise Architecture enables your business to be agile enough to adapt to a changing environment. From the onset, building the right technological infrastructure to support an enterprise’s business needs is crucial. Consider the following scenario.
Your business may purchase software to address a specific need at a particular point in time. Over time, business needs will change. Your business should be flexible enough to change in accordance with new business needs, which may mean replacing that software. This transition should occur without significantly affecting the existing Enterprise Architecture if the enterprise’s business processes have been designed to be solution-agnostic. Unfortunately, if the architecture that was used to select that software was lacking or nonexistent, it’s likely going to be a difficult process filled with patch work. This is the fundamental issue with legacy systems.
In the 1960s, intentional information systems planning was introduced to incorporate strategy into the design of information systems and has since evolved to address different challenges. One particular challenge presented itself in the 1990s. At the time, siloed IT systems meant that integration and interoperability were major issues. Businesses wanted their systems to cut across these silos, share information, and achieve holistic integration. Information systems planning facilitated this by considering end-to-end data flows between departments and determining management information requirements in the context of the entire business. Solution architects began to adopt a structured approach to design solutions that accommodated growth and innovation in order to address changing business needs.
Over time, the same approach of building an IT landscape equipped for change has been expanded to the entire enterprise. With the rise in adoption of middleware and Service-Oriented Architecture putting an end to siloed IT systems, the focus changed to the business and IT alignment, enabling the businesses as a whole to adapt to change in a coherent manner. Information technology can now be classified as a change enabler by being flexible enough to offer the capabilities required by changing business needs. The concept of Enterprise Architecture has developed into a multiperspective view of business processes, business objectives, data, systems, and IT infrastructure.
Enterprise Architecture is a globally recognized discipline with its own standards, frameworks, and best practices. It is important to note that even though a business may not specifically utilize EA to build their business, the business will still have an architecture, whether it has been consciously designed or not. As we shall explore in this book, an enterprise’s architecture consists of components such as its people, technology, and business capabilities within the context of how they relate to each other in attaining strategic goals.
Insight into the components that form your enterprise and the relationships between these components
Articulating an enterprise’s desired future state to drive your enterprise’s business strategy
Defining steps, standards, and guidelines required to transition toward a desired future state of your enterprise
A basis for the control, overseeing, and management of change
Providing a reliable reference to support management decision making
An agile Enterprise Architecture allows businesses to apply changes to processes and capabilities rapidly. The right architecture defines the present and desired future states of an enterprise while facilitating the transition to that future state. This book will explore what Enterprise Architecture is, its value, and its application to equip you with the knowledge to navigate business change and complexity. The book starts off by laying a standard foundation of Enterprise Architecture (EA) before focusing on SAP Enterprise Architecture and SAP Enterprise Architecture Designer specifically.
EA has evolved from only consisting of technological systems but now includes the goals, makeup, and running of your business. The next section seeks to further articulate the definition of EA.
Defining Enterprise Architecture
Enterprise architecture is the process by which an organization standardizes and organizes IT infrastructure to align with its business vision and strategic goals.
Enterprise architecture is a process of consciously leading how an enterprise adapts to change by conceptualizing and overseeing the transition toward a desired future business state.
An illustration of the gap between business needs and I T capabilities and how enterprise architecture comes in to bridge the gap.
Aligning IT capabilities to business needs
Building a physical structure is similar to building an enterprise. Building any kind of physical structure without a blueprint will likely lead to the wrong result and wasteful expenditure. Enterprise Architecture acts as a blueprint that offers a clear direction and reference point that allows you to manage your enterprise and its resources effectively.
Clarity to understand relationships between organizational components
Agility to adapt to change
Foresight to recognize opportunities
A road map to facilitate the transition to a desired future step
Improved planning, decision-making, and solution implementation
EA has multiple definitions because businesses utilize it with different end goals in mind and experience different benefits from it. Each organization will define EA according to what they hope to achieve by utilizing it. The key to understanding EA across multiple contexts is by defining the words that make up EA, “Enterprise” and “Architecture.”
What Is an Enterprise?
Simply put, an enterprise is any human endeavor – people collaborating together for a common purpose, supported by a platform. These people may be organized as a company or a project team. The supporting platform may include buildings, equipment, and information technology. Through the sharing of information, an enterprise performs related and collaborative activities toward achieving a common goal. The word enterprise generally gives the idea that we are referring to large corporate organizations, which is not always the case as an enterprise can be an organization of any size. Private companies, government agencies, nonprofit organizations, or a business unit within a large organization can be seen as an enterprise. This is because even an individual business unit has its own goals, business processes, skills and resources, and IT capabilities that support it.
An enterprise consists of multiple components that must all be taken into consideration within the context of the enterprise’s strategic goals. Achieving this requires the design of a balanced and integrated enterprise built upon the conscious decisions of its leaders. An enterprise depends on the optimal collaboration of its people, their competencies, business processes, IT, products and services, and its environment to meet business goals. This is the point at which we begin to see a structure forming.
What Is an Architecture?
An architecture is comprised of models and visual descriptions that represent the structure of an enterprise. In short, just as an architect builds a house according to a blueprint, an architect is required to build an enterprise according to a set of specifications that will result in achieving the business vision. Some confusion may arise around the fact that architecture is both the act and the result of analysis, design, and implementation. In the context of EA, analysis, documentation, and modelling are all processes within architecture, while the end product, “an architecture,” is the depiction of the composition and processes of the enterprise.
As mentioned in the introduction, the architecture of an enterprise exists whether or not it is acknowledged by the enterprise. Enterprises consist of processes, employees, locations, data, applications, and technology. The structure and the arrangement of all these components is the architecture of the enterprise. All of these components will interact in some way to create a structure that ultimately becomes your enterprise’s architecture. EA allows this to become a conscious process, one managed according to specific frameworks, standards, and best practices. The “enterprise” view is strategic and encompasses your whole organization, while its “architecture” provides a formal and best practice approach to building the enterprise.
The combination of the two words, “Enterprise” and “Architecture,” produces a clearer picture.
The Big Picture
Enterprise architecture offers a blueprint of the enterprise on a holistic level, and it becomes clear that seemingly independent components are actually interdependent. This is contrary to the modular or system-centric approaches utilized in past analysis techniques. It is a way of thinking about the structure of an enterprise that provides a specific approach of describing and understanding the structure of an enterprise. The end result is an enterprise-wide view of the enterprise structure which in turn exposes the limitations and constraints of the enterprise. This big picture view of an enterprise is what positions EA as an instrument to articulate the future while being the plan of transition toward that same future.
A blueprint that articulates how your enterprise utilizes IT resources and capabilities in reaching its strategic goals is a crucial point of departure. Every business has goals it wishes to achieve and a way it wishes to operate. This in turn creates business needs that must be met for the business to operate toward meeting its strategic goals. IT plays a crucial role in meeting business needs while also being an enabler for change. A business’s strategic goals and operating model have to be aligned with its IT capabilities and infrastructure.
An illustration of integrated governance includes strategic planning surrounded by risk, project, operation, resource, and enterprise management.
Integrated governance
Figure 1-2 displays common management practices undertaken by a business. EA should ideally be implemented as a management practice backed by executive endorsement. As EA is an enterprise-wide endeavor, it takes all other management practices into account when articulating the state of the business.
The big picture of EA should serve as a reference point, both as a plan and a map – as a plan in the sense that it captures the enterprise’s design, processes, and goals and as a map by providing the direction, next steps, standards, and best practices to be followed in going about bringing the enterprise to life. A single reference such as this eliminates the chances for the duplication of work as it is clear who is who and what is what in the grand scheme of things. The enterprise establishes a state of synergy and progresses in unison.
EA includes several core elements that contribute to its successful implementation. The following sections introduce these core elements that are also unpacked throughout the book.
Core Elements
EA framework
EA methodology
Current architecture
Future architecture
EA management plan
EA artifacts
Best practices
The following sections will introduce each of these elements to provide an idea of what EA comprises.
EA Framework
An Enterprise Architecture framework is a description of how to develop and utilize an Enterprise Architecture. An Enterprise Architecture Framework is comprised of standards, practices, templates, and guidelines to be followed in producing and utilizing the resultant Enterprise Architecture. It structures the thinking of the architectural team by dividing the Enterprise Architecture into domains. It determines the breadth of the complete architecture and how the various sub-architecture levels relate.
It assists architects to understand how a business’s systems and assets are logically structured and connected. This in turn supports holistic design decisions on all the domains of the architecture.
The specific manner in which the EA Framework distinguishes, collects, and organizes the domains results in a conceptual collection of “views” of an enterprise. This is particularly handy in the case of large and complex enterprises as the benefits of framework adoption typically become more apparent as the complexity and diversity of the architecture increases. EA frameworks are important tools for enterprises that are undergoing digital transformation initiatives. Enterprise modelling software tools such as SAP Enterprise Architecture Designer can make implementation and management of a framework easier.
The elements of your EA Framework provide a sense of direction that is split into three areas:
Architecture description – This defines the documentation process of your enterprise from multiple viewpoints. The point of the different viewpoints is to accommodate all stakeholders and also to ensure that the possible effects of any decision can be considered from every angle. To successfully implement an Enterprise Architecture framework, each enterprise stakeholder should be able to understand the architecture from their own viewpoint within the organization.
Design method – This describes the processes that enterprise architects must adopt to model the Enterprise Architecture. This may be broken down into phases with each process having its goals, inputs, stages, and outputs.
Team structure – This is a guideline on how the team of your enterprise architects must be structured and governed. It further details the level of competency, experience, and training needed. The framework should document skills gaps so training can be conducted.
Ultimately, an EA Framework serves as the perfect starting point by providing tools, techniques, and procedures that equip enterprise architects to get the most out of different architecture domains and integrate processes to create an agile environment that can undergo change while still meeting strategic goals.
Business Architecture
Application Architecture
Data Architecture
Infrastructure Architecture
See Figure 1-3. Please note that the naming conventions of these domains may differ according to the EA framework being utilized.
Business Architecture
Business architecture captures how a business operates and communicates how IT supports the business. It aligns technology strategy to business strategy, business capabilities, and value chains. The business architecture can be used to develop business/technology road maps, design future technology architecture to adapt to change, or design operating models. Business Architecture articulates the reason the organization exists and includes its objectives, goals, strategic thinking, capabilities, and organizational structure.
Application Architecture
Application Architecture provides fit-for-purpose and easy-to-use applications to support the business operations detailed in the business architecture. It primarily deals with user interfaces, integrations, and workflows. What is key is the data consumed and produced by applications rather than their internal structure. An application architecture details the functionality of applications utilized in your business and how they relate.
Data Architecture
Applications need data to work, and the data architecture connects enterprise data and makes it consumable. Data Architecture includes rules, standards, policies, and models that determine the nature of the data to be collected, the manner in which it is stored and leveraged by your business. A data architecture describes the data structure utilized by your business applications and business processes.
NB* You may find that some EA frameworks have the data and application domain as one combined information system layer. This book details each domain separately in an aim to provide a more precise and granular description of the domains.
Infrastructure Architecture
This refers to the underlying infrastructure required to run the business – the nuts and bolts, so to speak. It describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. The type of network topology, servers, client computers, IOT devices, and databases must be considered in relation to the objectives of the business architecture.
EA offers a comprehensive view of all these four domains, and after this brief overview, it should be clear how the coordination of these four domains results in IT and business alignment. Each domain has its own goals, objectives, standards, and processes, but they must all work toward achieving the enterprise’s strategic goals.
Additional Domains
As EA has grown as a discipline, different frameworks have been developed that include additional domains beyond the core domains mentioned thus far. One of particular interest is the security architecture because of more people working from home, the proliferation of the Internet of Things devices, and the increase in cybersecurity threats.
Security Architecture
A cycle diagram presents the interrelation between the architectural domains of business, data, infrastructure, and application.
Enterprise Architecture domains
Demarcating the enterprise into different domains reduces the complexity of dealing with large enterprises especially.
EA Methodology
A methodology is a structured and systematic collection of approaches used to establish and maintain the Enterprise Architecture program. A methodology explicitly directs an architect’s thinking toward the desired outcome along with supporting why that line of thought should be taken. It tells us what steps to take, in what order, and how to perform those steps.
Current Architecture
The current-state architecture represents where the organization is today and possibly how it got there. This is commonly referred to as the “as-is” view. It gives insight into the resources, processes, activities, skillsets, charts, diagrams, manuals, goals, and objectives (among other artifacts) that the enterprise currently has. These items are referred to as artifacts in the EA context. At a granular level, there is a view of this for a particular line of business or segment. The current architecture must be analyzed, designed, and documented in the same manner as the future architecture so that gaps in performance between the two can be clearly seen.
An accurate picture of the current architecture is critical because it forms the basis of project planning and investment decision making. When used in combination with the future architecture, it’s easier to evaluate existing architecture against long-term goals.
Future Architecture
The future architecture is a vision of how your business intends on leveraging its IT capabilities to support business operations at a specific time in the future.
Business objectives
Optimize performance by closing an existing performance gap and achieving operational targets
Support business strategies (new and existing)
Support operational requirements (new and existing)
Digital transformation
This process of articulating the future must be coordinated and make strategic (business direction), tactical (business processes), and operational (technology) considerations that will result in the achievement of the new business goals.
In combination, the current and future architectures enable the development of a clear road map that will guide you in your transition from the current state to a future state. It is recommended that this road map include transient states to ensure that there are always tangible deliverables and goals to be met. Furthermore, this ensures that you stay on course and on time. Executing incrementally in accordance with predetermined checkpoints ensures that you are always aware of whether things are running efficiently or not. More importantly, you can tell whether the intended architecture is what you are actually likely to achieve.
The next step is to establish how the EA process will be governed. Clear and efficient governance procedures are critical in establishing the control required to guide the EA process toward desired outcomes.
EA Management Plan (EA Governance)
The EA management plan documents how EA will be governed and controlled. It translates the architectural requirements of your enterprise into digestible standards, actionable activities, and guidelines in the development of an Enterprise Architecture. Thus, the EA management plan serves as a reference document required to maintain a level of excellence in EA. For instance, the standards woven into the EA management plan include both business and technology standards that cover all domains of the EA. They include local standards, international standards, and industry standards. Internally, EA can be used to produce new standards for the enterprise.
The EA management plan may be broken down into corporate governance, IT governance, and architecture governance to contextualize governance procedures and their significance to the EA process. The EA management plan also contains information that supports EA management decision making such as an overview of the current and future state, the existing performance gaps, EA goals, available resources, and a sequencing plan.
The EA management plan is what they call a living document in the sense that it evolves over time and must continually be referenced. The EA management plan must be updated on predetermined dates or after important cycles or iterations to reflect accurate, relevant, and current information. Efficient version control of the EA management plan is crucial in ensuring that all stakeholders are on the same page. It is the focal point of utilizing EA in management.
Best Practices
These are procedures that have been proven effective in executing the discipline of Enterprise Architecture. They help manage Enterprise Architecture and have been established through trial and error. Following best practices results in business benefits such as more predictable outcomes. Examples are recommendations such as utilizing the business strategy as the starting point of EA or creating an EA charter. Best practices are expanded on in great length later in this book.
EA Artifacts
The core elements highlighted so far result in various models and documentation that represent the enterprise-wide big picture. It is important that all of these products are stored in a central location available to all relevant stakeholders to support the EA practice.
EA artifacts are documents that provide descriptions of the state of the enterprise and include documents such as business plans, workflows, network descriptions, and more in addition to the core elements that have been mentioned. They are cornerstones of an EA practice and improve the communication and collaboration between stakeholders. Artifacts are stored in what is called the EA repository. The EA repository is a central storage space for EA artifacts that various EA stakeholders can access.
To conclude the section on core elements, here is a summary of how all of these core elements come together.
The EA framework provides a structured approach to establishing the EA practice and guides the thinking adopted by the enterprise architects. It demarcates the enterprise as several domains typically including the Business Architecture, Data Architecture, Application Architecture, and Infrastructure Architecture. The EA methodology specifically details the activities and steps to be taken in each phase of the EA process along with the EA artifacts that must be produced in each phase.
The current architecture offers an “as-is” view that serves as the starting point for the enterprise’s transition into a future state. The “to-be” view is articulated in terms of the future architecture. The gap analysis determines suitable options available to transition the business enterprise from the current to the future state while making the best use of available resources. The EA management plan provides continual governance through guiding the business in planning and controlling various EA activities. Best practices are tried and tested ways of carrying out EA activities that are likely to lead to desired outcomes if they are adopted effectively.
Thus far, this book has looked at EA as a practice. The following section expands on the role of an EA practitioner, in other words, an Enterprise Architect.
What Does an Enterprise Architect Do?
An enterprise architect ensures that a business leverages its resources, technologies and skills to reach its business outcomes by guiding and overseeing the business's transition to a desired future state.
An enterprise architect provides strategic architecture vision and direction by leading architecture transformations and organizational change. For instance, after conducting a gap analysis, the enterprise architect must put together the migration plan to determine how these gaps will be filled. EA is not about executing the changes but about overseeing them. Enterprise architects do this by determining standards that must be followed by project teams. Enterprise architects must govern the change activities and ensure that the plan will actually achieve what the enterprise needs.
Ensuring IT capabilities match business needs
Establishing architecture and process governance
Communicating goals, metrics, and value across the organization
Analyzing existing capabilities
Establishing a road map to a future state
Supporting planning and decision-making activities by providing analysis
Defining the structure of the EA repository
Leverage technology to reduce manual processes and increase efficiency
Better control costs within the organization, particularly technology and infrastructure
Gain better control of data across the organization to eliminate redundancy and increase accuracy
Increase competitive advantage and market share and increase customer base
Should the business utilize a cloud-based infrastructure?
Should the business build, buy, or leverage managed services?
Which system should the business migrate first?
Does the business already have the technology to facilitate its goals or is an upgrade required?
The preceding goals, questions, and their answers must be linked to a plan of action that the enterprise architect is responsible for putting together. This plan has to be broken down into a phased approach that makes the best use of available resources. The output of an EA’s work is the overall executive strategy into an implementable work plan.
An enterprise architect must always have an in-depth understanding of the environment they’re working in order to plan the use of time, resources, and skills accordingly. This will further assist in managing the expectation of stakeholders because the enterprise architect has an understanding of what is possible and realistic. A wide range of experience and exposure to different technological solutions across multiple business departments enables the enterprise architect to maintain an enterprise-wide view.
Establishing an Effective EA Practice
- 1.
Ensure the availability of competent resources to lead and govern architecture development within clearly defined roles and responsibilities.
- 2.
Select a proven and agile implementation methodology that will be adhered to by the entire enterprise.
- 3.
Best practices, standards, and guidelines must be readily available to all stakeholders, and there must be a system to monitor compliance.
- 4.
Manage the EA repository effectively.
- 5.
EA management should be part of an integrated governance model.
The Value of Enterprise Architecture
The value of Enterprise Architecture is seen from the perspective of the problems it addresses. Most of these problems stem from changes in the business environment. Most recently, the COVID-19 pandemic has sent shockwaves across the business world. Businesses that were already further along in their Enterprise Architecture journey were able to adapt rapidly after new complexities were introduced. With the growing work-from-anywhere culture, EA is no longer confined to the walls of corporate buildings. People, processes, and technologies meet business needs wherever business is done, which includes the home, the train, and coffee shop. Only agile organizations equipped for sudden change navigated these complexities successfully.
Enterprise Architecture allows the business to look at possible solutions and business requirements in the context of its strategic goals. We must always determine what we want to achieve first, then combine it with the relevant business processes and technology. This ensures that the business is considering the entire enterprise in its decision making and enables it to build an agile enterprise that can adapt rapidly in accordance with those decisions. Doing the reverse would result in a bottom-up, system-level approach which has historically been the cause of great financial loss as the enterprise continually changes its processes to accommodate legacy systems. System-level views may be sufficient for smaller organizations but are found wanting in the case of larger businesses.
EA is also valuable in terms of supporting management practices by providing insight into the enterprise at a holistic level. For example, it gives visibility into available resources and how they have been used. Decisions can then be made on how best to optimize those resources. This also forms the basis for the review of internal projects and initiatives. Management policies can be implemented upon the foundation of the insight provided by EA. The policies are built to support the transition to the desired future state as per the EA.
The value of Enterprise Architecture will be further expanded upon in the course of this book as more complex concepts become digestible.
Summary
This chapter served to provide a brief overview of EA suitable for readers from all backgrounds including readers new to EA. EA allows an organization to move in unison toward a shared business vision. It is a reference point that serves as a guide in how the organization should make decisions and manage processes in order to achieve its goals. Enterprise architecture is both a profession and a description of an expected result of practicing that profession.
EA has an enterprise-wide look of your systems that is within the context of your strategic goals. We can deduce what has to be done through analysis and design, how to do it (methodology/best practice), to what level it should be done (standards), and how to control the process (management program). An enterprise architect ensures that a company leverages its resources, technologies, and skills to reach its business outcomes by guiding and overseeing your enterprise’s transition to a desired future state. They are responsible for documenting and overseeing the transition toward a desired future state.
Alignment of IT capabilities and business needs
Cost reduction in operational expenses
Leveraging your enterprise’s technology assets at the highest level
Improving IT capabilities and capacity
Integration of new technologies
As a management program
As a documentation program
The following chapters will expand on the ideas and concepts introduced in this chapter, with Chapter 2 expanding on the strategic role of Enterprise Architecture.