4

Available Frameworks for an Enterprise Architecture

In this chapter, we will explore common frameworks and use cases, and identify common potential risks and benefits of particular enterprise architecture (EA) approaches. We also will cover several types of risks and how to assess risk when implementing an EA.

Finally, we will consider tools available to assist in the EA journey and share examples of tools and services that can ease the migration of an existing system to an EA-ready system.

In this chapter, we will cover the following topics:

• Use cases for EA and objectives
• EA frameworks (EAFs) and methodologies
• Technology and risk management
• EA collaboration and reporting
• EA and digital transformation

Use cases for Enterprise Architecture with objectives

In the right hands, enterprise architects can assist their companies in navigating the digital transformation that could have substantial benefits for their organizations in the long run. This would enable their companies to ensure compliance with regulations. As an example, consider the General Data Protection Regulation (GDPR) of the European Union (EU).

A number of new rules have been imposed on the management of end users’ personal data by this regulation. A company that fails to comply with GDPR will be fined up to 20 million euros or 4% of its global annual turnover for the prior fiscal year. In order to demonstrate GDPR compliance, enterprise architects need to ensure that all relevant data is collected and presented in a clear and concise manner.

Business architects have the ability to add value in three specific areas: enabling growth, ensuring compliance, and reducing complexity. Organizations must continually innovate to stay competitive. It is common for organizations to struggle with implementing key information technology (IT) trends—such as microservices, the Internet of Things (IoT), and cloud migration—that carry the potential to increase their market share. In addition to accelerating time to market (TTM), creating new revenue streams, reducing hardware costs, and reducing costly complexity, these trends can be extremely valuable to companies. In the future, enterprise architects will be in a position to support their companies’ digital transformations, which—if done correctly—could result in reduced costs and greater profits.

The uninhibited growth of IT in the past few years has resulted in duplicated systems that bring along with them multiple drawbacks and overlapping capabilities. These systems generate inconsistent data that is overly complex. Enter enterprise architects. Their role is to tackle these problems head-on by providing a roadmap to manage and reduce complexity, which contributes directly to reducing costs.

As a top-level architect, an enterprise architect is responsible for EA design. Consequently, they have a broad scope of responsibilities. In EA, IT assets and business processes are mapped along with a set of guiding principles that help drive a continuous discussion about business strategy and how it can be expressed through IT.

A solutions architect is one level higher than an application architect, who is a specialist in a specific application. A solutions architect focuses on the solution, while an enterprise architect focuses on the organization as a whole. An application architect focuses on one function. These roles don’t interact with clients often, so they do not require much business experience. With experience, many solutions architects go on to become enterprise architects.

An effective EA that has strong foundations and is well aligned with the business objectives and technical strategy can offer great benefits to an organization. Some of the more specific objectives of an EA are listed here:

• Business operations:
  • Reduced cost of business operations
  • More agile organization and workflows
  • Shared business capabilities that can be accessed across the organization
  • Lower change management costs
  • Higher business productivity to ensure greater efficiency
• Digital transformation and IT operations:
  • Extended reach of the enterprise through enhanced digital capabilities
  • A harmonized environment is ensured by combining all enterprise components
  • Reduced expenses of software development, support, and maintenance
  • Higher portability ratio of applications
  • Convenient system and network management with an improved interoperability
  • Better communication regarding critical enterprise issues
  • Easy to upgrade system components
• Better IT investments:
  • Elimination of complex elements in the business and IT
  • Higher return on investment (ROI) for current business and IT networks
  • Easier outsourcing of business and IT solutions
  • New and lower-risk investments, accountability, and more effective outcomes
• Faster, simpler, and cheaper procurement:
  • Accessible information governing procurement in a coherent plan to simplify the process of making buying decisions
  • A faster procurement process to boost overall speed and flexibility while maintaining architectural coherence
  • Capability for multi-vendor open systems
  • Enhanced ability to secure more economic, IT, and business capabilities

The value of a system is more easily recognized where the need for it is higher. The same is the case with EA; it works most productively for large corporations that are struggling to simplify their highly complex IT environments. The business model that lacks varied capabilities produces a critical need for effective EA.

Nine most common EA use cases

Here are the nine most common use cases where an EA is the recommended solution for addressing challenges and leveraging opportunities.

Post-merger management

Multiple businesses can merge or come together to combine their services, in different circumstances. Smaller companies are acquired by bigger companies, financially struggling companies join up with more successful organizations, and successful best-of-breed companies are acquired by companies seeking to add capabilities to their product portfolios. These events are called mergers and acquisitions (M&A).

The post-merger phase can be complex, and it is crucial for all parties involved to work together, as this integration phase is no easy feat. All information about company policies, assets, capabilities, and more must be shared and understood. Applications, servers, business capabilities, employees, processes, and other artifacts must be carefully considered for what they provide pre- and post-merger.

On average, 70-90% of acquisitions fail. To ensure a smooth, seamless, and successful journey through the process, effective strategies for accelerating growth and scaling operations are essential.

Although many factors contribute to M&A not succeeding, one is that businesses pause operations to focus on integration. In the integration phase of a successful M&A initiative, EA enables key stakeholders, such as chief financial officers (CFOs) and chief operating officers (COOs), to make faster and more credible decisions.

M&A fail and consume unintended resources when the companies involved fail to successfully integrate or anticipate needed synergies. These challenges are huge from a technology standpoint. When multiple companies are concerned, the unification and transformation of technologies must occur without disrupting business as usual.

During a merger or acquisition, it is essential to ensure that the initial state of both IT landscapes is documented. This is where EA proves to be especially helpful in answering essential structural questions, such as the following:

• What infrastructure is in place for maintaining records at each company?
• How is company data stored and retrieved when required?
• Where does the company store its supporting documents?

Enterprise architects propose best-fit solutions from concrete data after considering these questions and finding answers.

Application rationalization

Businesses are often focused on driving economic growth rather than aligning the IT landscape. Consequently, different applications are put in place at different points in time, based on needs or requests communicated from different departments.

Business leaders may not realize that having a sprawling IT ecosystem full of overlapping applications, varying life cycles, and redundant technologies often encounter multiple integration issues and inefficiencies that may affect the company’s operations at the enterprise level. In addition to increasing IT spending by hundreds of millions of dollars, a complex, rigid IT ecosystem also directly decreases the quality of service (QoS) and customer satisfaction.

EA provides an opportunity to review applications in use across the business, recognize and address integration failures, eliminate redundant applications, and streamline processes for reviewing and selecting applications in the future.

Integration architecture

Integration architecture (IA) is critical for valuable applications. Some applications are built from scratch, while others run on their preconfigured settings, and some others use a combination of the two.

Integration is a challenge, as the most valuable applications are those that work together to create seamless solutions, and every business has different needs. Retail and e-commerce applications need to integrate with inventory systems, human resources (HR) applications need to sync with calendars, marketing applications need to work with customer relationship management (CRM) programs, and so on.

Integration is defined by the complexities and dependencies of multiple applications running on multiple platforms in different locations, which makes the term simple integration a contradiction. Statistics suggest that 70% of all integration projects are unsuccessful. Technical difficulties or problems with the software are rarely responsible for these failures. The problems are caused by management problems, constantly changing software, ambiguous standards, and a lack of clarity in accountability.

EA provides a foundation and roadmap for integrations across an organization. It also defines resources and processes necessary to ensure that integration capabilities are considered, managed, and executed successfully.

Technology risk management

Risk management requires establishing a strategic view of an organization to understand possible challenges. Doing this requires an informed view of current products, processes, applications, and infrastructure, as well as an understanding of the risk and security aspects of each. Without knowing what the primary risks are, C-level teams cannot fulfill their management responsibilities. The ability to understand these relationships is essential in assessing the effects of business decisions.

Business analysts can use these tools to analyze enterprise risks associated with—for example—developing new products and initiatives, outsourcing business processes or IT systems, or assimilation of another organization after a merger. This will allow them to balance the enterprise’s risk propensity against potential consequences.

Furthermore, executives and operational management are rightly concerned about the spread of risks across the organization. Risks from one part of the organization can affect other parts of the organization. Consider the example of a system failure, break-in, power outage, fraud, or another mishap. How would these events affect critical business processes, services, clients, partners, and markets? By creating insights into these relationships and dependencies through EA, you are able to prevent or mitigate disasters in the future.

Technology is essential to the success of organizations in all industries. Any technology carries some inherent cyber risks, which can be found in innumerable forms. The most common, yet preventable, situations resulting in data breaches are caused by IT outages, legacy applications, and their supporting infrastructures. Based on IBM’s Cost of a Data Breach Report 2021 (https://www.ibm.com/security/data-breach), the average cost of a security breach is $4.24 million United States dollars (USD) globally. The average cost of a breach in the US is much higher, at $9.05 million per incident. An attack on an organization’s cybersecurity system can have a significant impact on its financial standing, customer retention, and brand reputation.

There are probably over a million different types of technology products offered by the 20 largest technology vendors alone. Their components change every day, and the need to monitor new versions as life cycle information changes is an important element of IT management. Outdated components need to be upgraded based on these changes.

There are many risks associated with maintaining obsolete technology, including the following:

• The technology doesn’t support the business
• Higher complexity
• Security vulnerabilities
• Compliance issues
• Lack of skill and support from vendors
• Lower IT flexibility

Technology products undergo about 2,500 information changes daily. Keeping track of all of it would be impossible to do manually.

Data compliance

Compliance with data privacy laws and regulations is how organizations show they follow formal standards and procedures for ensuring sensitive data is protected from loss, theft, corruption, and misuse. Organizing, managing, and storing data requires compliance with regulations that organizations must follow to avoid financial, legal, and other penalties that could be levied against the business and/or individuals who lead it.

Various industries, governments, states, countries, and even continents have varying regulations regarding data compliance. The three elements an organization must focus on when it comes to data compliance relate to data, actions, and penalties. Regulations identify the type of data that should be protected and actions that must be taken to protect that data. If an organization doesn’t comply with these actions, regulations outline the consequences.

The cost of compliance is steep, but the penalties for non-compliance are even higher. Under GDPR, for example, any organization processing the personal information of EU citizens must comply with GDPR regardless of where their business is located. As with many regulatory mandates, GDPR offers many advantages, such as requirements for data standardization that will benefit organizations and their transactions with other businesses. For most organizations, data compliance has affected their approach to data management.

Standards governance

EAs and other architectures are managed and controlled by architecture governance at an enterprise level. Architecture governance normally operates within a hierarchy of governance structures and not in isolation. It works in the larger enterprise, such as corporate governance, technology governance, IT governance, and architecture governance, and can include all of the distinct architectural domains with their own disciplines and processes.

The enterprise may have multiple levels of governance—global, regional, and local—over its life cycle. Large corporations can benefit from standardized IT: they can reduce training time, cut maintenance and support costs, have better bargaining power with vendors, and improve communication.

It is common to combine standardization with centralization, a process by which an IT department gains more control over hardware and software purchases, because every new piece of software equipment added to the IT arsenal will require installation, maintenance, personnel training, repairs, patches, upgrades, and so on. Standardization can be disadvantageous, as technologies change very rapidly, and processes need to be updated when technology changes. Businesses also use alternative concepts, such as radical agility, to prevent stifling innovation across the enterprise.

Monoliths to microservices

Many businesses are being forced to rethink their architecture as digitalization accelerates rapidly. Customers expect companies to make their products available on as many digital channels as possible to meet their constantly increasing expectations. Multinational corporations have grown to become monoliths over time, as they develop very complex structures that make it difficult to perform swift or timely changes.

It is not sufficient to apply scale to individual elements of an architecture; the entire application must be prepared for scale. Introducing microservices architecture into software development can reduce application throughput times. Since microservices can be built and deployed independently, not only do they enhance productivity and flexibility, but they also increase the resiliency of applications. Teams can build microservices from the ground up or decompose legacy monolithic applications into microservices. They enable cloud-native development, whether they’re deployed on-premises or in the cloud.

A reputation for complexity surrounds microservices. Furthermore, not every monolith is well suited for being converted to a set of microservices. In order to determine when and where microservices are useful, enterprise architects play a crucial role. Furthermore, they lay the groundwork for a cultural shift that is required for microservices to succeed.

When it comes to legacy issues and missing information, companies that have adopted microservices still face the same challenges as those that haven’t adopted them. As a result of microservices, monoliths can be broken down, enabling rapid changes, short release times, and team autonomy. Software releases created with microservices are deployed up to five times faster than those created without them.

Cloud transformation

The process of moving data, applications, networks, and infrastructure to a cloud environment is known as cloud transformation. Moreover, the cloud in all its forms—including on-demand environments, smart development, and artificial intelligence (AI)—is a technology to be harnessed. The cloud may seem like the perfect solution if legacy technology, processes, and infrastructure are preventing an organization from achieving a desired competitive advantage. There are many big consulting firms that can help teams design their cloud transformation strategy. Although many steps and guides are provided to help teams make the transition, in the end, it’s really all about moving applications to the virtual world.

Defining and analyzing changes executed toward the achievement of organizational goals forms the basis of EA, so organizations applying an EA approach are likely aligned with their goals.

With the availability of cloud computing, new service-driven business models have been developed that drive product and service value. A number of benefits are associated with cloud computing, such as cost savings, efficiency improvements, shorter development cycle times, and faster TTM. In addition to improving asset utilization, reducing operational expenses, and redefining the relationship between IT staff and management, moving to the cloud can help companies dramatically cut costs.

As business and IT strategies are increasingly influenced by the cloud, a roadmap from legacy to cloud needs to be implemented by enterprise architects. Achieving cloud transformation success is challenging due to complex business environments and rapidly changing infrastructure. A successful transition to the cloud requires a number of organizational, operational, and technical modifications. Several factors influence cloud adoption along the way, including budget limitations, the need for exponential scale, and increasing complexity in corporate policies and regulations.

IoT architecture

Digital transformation is driving an increase in the need for enterprise architects to manage the growing complexity of IT. Consumers find IoT-powered smart devices useful or convenient for their lives. For example, a fuel monitor that dispatches a fuel truck when a propane tank meter registers below a certain percentage can save time that would have been spent monitoring the meter manually and calling the fuel company to schedule a refill. Similarly, enterprise architects should consider how IoT can benefit their organizations.

EA can integrate IoT in three generic ways, as outlined here:

• In the first case, you can choose to rely on the services provided by the device manufacturer. Exporting and importing files are the two main methods of transferring data between existing corporate systems, while custom application programming interface (API) connections can be used to transfer data automatically.
• In a second option, an IoT value chain can be built by implementing separate services for data storage, data communication, data analytics, and data integration. While this approach can be quite a challenge, many IoT applications will be handled more successfully using this method.
• A third option would be to connect IoT devices directly to enterprise management systems, such as Systems Applications Product (SAP), or build an in-house intermediate application to achieve this goal.

With IoT, companies can launch products faster, get big data insights in real time, create new services and business models, and reduce costs. However, security and privacy risks, a lack of standard oversight, and the integration of IoT devices all pose significant challenges.

EAFs and methodologies

EAFs provide guidelines for creating and using EAs that describe a model of a system’s architecture. Tools and approaches are provided to facilitate enterprise architects’ work to optimize different architecture domains across the enterprise. They integrate disparate, fragmented manual and automated processes into an environment that is responsive to change and supported by the implementation of business strategies.

EAFs determine how organizations can most effectively achieve their current and future business goals. While EAFs have evolved over the last five decades, there are a few that have been developed and improved over time and are still in use today.

The Open Group Architecture Framework

The initial development of The Open Group Architecture Framework (TOGAF) took place in 1995. Newer editions or models offered improved iterations and theories, as was usual at the time in the field of EA. TOGAF was heavily influenced by the US Department of Defense’s (DoD’s) own EAF, called the Technical Architecture Framework for Information Management (TAFIM).

TAFIM was abandoned by the US DoD within a few years of TOGAF’s introduction. Today, over 20 years later, it continues to be a worldwide success. Organizing IT efforts cross-departmentally, and aligning IT initiatives with business goals is a part of TOGAF, as are other common IT management frameworks.

Before an EA project begins, TOGAF helps businesses define and organize requirements, keeping the project moving efficiently and with few errors. This framework aims to help enterprises organize and address all critical business and strategic needs through four objectives, as outlined here:

• Use a common language among users, from key stakeholders to team members. As a result, everyone will understand the framework, content, and goals in the same way, and communication barriers can be addressed or removed.
• Achieve EA freedom by avoiding proprietary solutions—a combination of tools, processes, and unique capabilities businesses develop or acquire to gain a competitive edge. TOGAF is free, as long as it is being used internally and not for commercial purposes.
• Save time and money by utilizing resources more efficiently.
• ROI must be measurable.

A common EA subset consists of four domains, as outlined here, and the TOGAF standard is designed to support all of them:

• Organization, governance, and key business processes are defined by the business architecture.
• In an organization’s data architecture, data assets and data management resources are described logically and physically.
• Application architectures describe how applications are going to be deployed, their actions, and their interactions with the core business processes of an organization.
• Technology architecture is a set of logical requirements for deploying business, data, and application services. It includes IT infrastructure, middleware, networks, communications, processing, standards, and so on.

TOGAF provides a proven and repeatable Architecture Development Method (ADM). Architects establish an architecture framework, develop architecture content, transition architectures, and guide their realization. These activities are executed within an iterative cycle of continuous architecture definition and realization, which enables organizations to transform their businesses in a controlled manner while meeting business goals and opportunities.

An ADM includes the following phases:

• During the preliminary phase, activities such as customization of TOGAF and the definition of architecture principles are considered in the preparation and initiation of the architecture capability creation:
  1. Architecture vision is the first phase of the architecture development cycle. In this phase, organizations identify key stakeholders, detail the architecture vision, and explain how to obtain approval to move forward with architecture development.
  2. The business architecture is developed to support the agreed-upon architecture vision.
  3. Information systems architectures are created to describe how these architectures will support the architecture vision.
  4. Technology architecture is designed to support the architecture vision.
  5. Opportunities and solutions are identified for initial implementation, and delivery vehicles are identified.
  6. A detailed implementation and migration plan is finalized.
  7. Implementation governance sets up the execution plan and accountability structure for the project.
  8. Procedures for managing changes to the new architecture are established.
• The final phase is also a continuous and ongoing activity, to examine how requirements are managed throughout the architecture development life cycle.

An architect implementing an ADM will generate a number of outputs as a result of their work, including process flow diagrams (PFDs), architectural requirements, project plans, and project compliance assessments. An ADM provides a framework for the definition, structure, and presentation of major work products organized according to TOGAF architecture.

The following three categories describe the type of architectural work product within the context of use by an architecture content framework:

• Deliverables are work products that are contractually specified and, in turn, reviewed, agreed upon, and approved by the stakeholders. A project’s deliverables consist of documents that are archived at project completion or moved into an architecture repository as a reference model, a standard, or a snapshot of the architecture landscape at a specific time.
• Artifacts are architectural products that describe a certain aspect of architecture. In general, artifacts fall into three categories: catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things). A use-case diagram, a business interaction matrix, and a requirements catalog serve as examples. The architecture repository will store the artifacts of an architectural deliverable.
• In an enterprise capability, a building block represents a part of the enterprise capability that may be reused in combination with other parts to construct architectures and solutions. The level of detail of building blocks can depend on the stage of the architecture development process. Early in the process, building blocks can simply consist of names or outlines. In the future, a building block can be decomposed into multiple supporting building blocks, along with detailed specifications.

Architectures and solutions can be considered building blocks, as detailed here:

• As per architecture building blocks (ABBs), an enterprise may require a customer services capability, which can be supported by many solution building blocks (SBBs), such as processes, data, and application software.
• In SBBs, there are components that implement the required capability; for example, a network is an artifact that can be described with complementary artifacts and then used to implement enterprise solutions.

An architect implementing an ADM will generate a number of deliverables, maintaining them in an architecture repository. The ADM provides a framework for the definition, structure, and presentation of major work products in the architecture.

No two organizations are the same, so it is important to be able to customize the approach to meet each organization’s specific needs. The Enterprise Continuum allows enterprise architects to map a tailored approach.

Enterprise Continuum

As part of the TOGAF standard, there is the concept of the Enterprise Continuum, which sets the broader context for an architect and explains how generic solutions can be adapted and tailored to meet the unique requirements of each organization.

The Enterprise Continuum is part of the architecture repository, a method of classifying architecture and solution artifacts as they change from generic foundation architectures into organization-specific architectures. The Enterprise Continuum includes the concepts of Architecture Continuum and Solutions Continuum.

Making work products available to individuals and teams across an organization is a critical aspect of EA and ensures consistency across an EA team.

Architecture repository

By using an architecture repository, the TOGAF standard supports the Enterprise Continuum by storing different types of architectural output, created by the ADM, at different abstraction levels. In this way, stakeholders and practitioners at different levels can communicate and collaborate. In developing an organization-specific architecture, architects are encouraged to leverage all other relevant architectural resources and assets available in the Enterprise Continuum and architecture repository.

A TOGAF architecture delivery model is an organization’s process life cycle based on a governance framework that operates on multiple levels within an organization and produces outputs that reside in an architecture repository. Enterprise Continuum models provide a useful context for analyzing architectural models. They depict building blocks, their relationships, and the constraints and requirements associated with the development cycle.

Here are the major elements of an architecture repository:

• The architecture metamodel is a set of tools designed to tailor an architecture framework and content for use within specific organizations.
• Governance of the architecture repository is supported by the architecture capability through parameters, structures, and processes.
• The architecture landscape represents assets deployed across the enterprise at various levels of abstraction to satisfy the architecture objectives of the enterprise.
• New architectures must comply with the Standards Information Base (SIB). They may include industry standards, selected products and services from suppliers, or service sharing already in place within the organization.
• To support the creation of new EAs, the reference library provides guidelines, templates, patterns, and other forms of reference material.
• An enterprise governance log records governance activity across the organization.
• The repository of architecture requirements provides the architecture board with a view of all authorized architecture requirements.
• The solutions landscape represents architecturally the SBBs that have been planned or deployed by an enterprise to support the architecture landscape.

The architecture repository builds the capability for the organization to implement, support, and repeat new EAs at scale.

Establishing and maintaining an EA capability

For architectural activities to be effective within an organization, it is imperative to establish organizational structures, roles, responsibilities, skills, and processes that promote architecture as a business capability.

When an EA process is operating at maturity, business capabilities and operations are tracked, and the resource pool and professional development are aligned with roles and responsibilities required under the architecture.

One of the most effective frameworks that are widely used in EA is the Zachman Framework, which is used for identifying and tracking critical elements of an organization’s people and processes that support EA.

Zachman Framework for EA

John Zachman introduced his framework for information systems architecture in 1987. The Zachman Framework applies the understanding that the same complex item can be described for different purposes in different ways, using different kinds of descriptions.

An architectural artifact is organized using the Zachman Framework—a design document, specification, or model addressing both the target audience of the artifact (for example, business owners and system builders), as well as the specific issue being addressed (for example, data and functionality).

The Zachman Framework is based on a two-dimensional (2D) model used for arranging artifacts in the architecture industry. In building architecture, the first dimension refers to the players involved. Construction of physical buildings—for instance—may involve several players or stakeholders, including the owner who pays the bills, the contractor who manages the design, and a zoning board that ensures building codes are followed.

Different architectures are prepared for each player by the architect and comprehensive information is demanded by all players, but what constitutes completeness varies for each player. In addition to the building’s functionality and aesthetics, the owner is interested in a detailed description.

Construction materials and the construction processes are of particular interest to the builder. There is no concern over where the wall studs are placed, or which nails or shingles are used. Certain practices are observed—for example, one practice might be to build a house with bedroom windows aligned with the sun in the morning, regardless of where the sun rises in the morning.

In terms of a specific artifact organization, the second defining aspect is the descriptive focus of that artifact: the what, where, when, who, and why of the project. The second dimension exists independently of the first dimension. Neither the builder nor the owner should be unaware of what, but what the owner knows may differ from what the builder knows. Who asks the question will determine the answer.

The Zachman Framework suggests that the same complex item can be described for different purposes differently, using different descriptions. Any complex object, such as manufactured goods, can be completely described using Zachman’s 36 categories, made up of six columns and six rows and taking the form of a 2D matrix.

Included in the Zachman Framework are these perspectives of the system:

• Planner’s View (Scope Contexts): Describes the organization’s purpose and strategy and provides a basis for the other views
• Owner’s View (Business Concepts): A view of the organization that shows where automation can be applied
• Designer’s View (System Logic): This view describes how the system will meet the information needs of the organization
• Implementer’s View (Technology Physics): How production constraints will be met as part of the implementation of this system
• Sub-Constructor’s View (Component Assembles): This view shows details specific to an implementation of a specific system element
• User’s View (Operations Classes): This view enables the user to observe the system’s operation

Another EAF emerged in response to US legislation designed to improve the way the federal government acquires, uses, and disposes of IT.

Federal Enterprise Architecture Framework

In response to the Clinger-Cohen Act of 1996, chief information officers (CIOs) established the Federal Enterprise Architecture Framework (FEAF) in 1999. The FEAF allows federal agencies and other government agencies to share processes and information.

An architecture can be categorized according to FEAF categories of business, data, applications, and technology architectures, as explained in more detail here:

• Business architecture defines what is done, who did it, how it was done, and when and why it was done
• Data architecture determines the information used by the agency to do business
• Application architecture is a collection of all IT resources, such as computers and software that process the data according to business rules
• Technology architecture comprises the technology that facilitates the previously mentioned phases

Federal EA (FEA) is the method or the architectural result of implementing that methodology for a specific enterprise. In terms of how it can apply to companies in the private sector, FEA is viewed from a methodology perspective.

Although there is a lot more to FEA than its reference models, five of them can be referred to as part of FEA, one representing each activity area—business, service, components, technical, and data.

The FEA process

The FEA process focuses on developing a segment architecture for an overall enterprise subset, as follows:

• Analyze the segment’s architecture to determine a simple but concise vision that relates to the segment’s organizational structure
• Establish an architecture target for the segment, define goals, develop design alternatives, and set the EA for the segment that includes business, data, services, and technology architectures
• Justify the investment and determine the ROI
• Establish milestones and performance measures for assessing the success of the project, including a plan and task list

FEA integrates strategic, business, and technology management as part of organization design and performance improvement.

Yet another EAF was developed by Gartner, a firm that provides analysis, research, and strategy services for organizations.

Gartner’s EAF

As organizations plan for the future, Gartner’s EAF is designed to influence and support their decisions. It focuses on a constant state of adaptation. This model is used to assess the enterprise’s present state, identify appropriate investments in technology and procedures to achieve the desired future state, manage the enterprise during the transition, and plan investments for the future.

This framework brings together three constituents: business owners, information specialists, and technology implementers. Success depends on how well an organization can unify these three groups behind a shared vision that drives business value. The key to success is to drive profitability, not check off items on a process matrix. According to Gartner, EA must focus on where an organization is going rather than on where it is now.

An organization has the opportunity to clearly articulate the nature, scope, and impact of the EA changes being made by creating an EA vision. A business, technical, information, and solutions architecture for an enterprise can be considered as soon as the organization establishes this common vision for the future.

Those changes must be prioritized according to the business value they will bring. EA involves creating the best possible template or platform to maximize the use of IT systems. There is no inherent antagonistic relationship between the four frameworks analyzed here. Every one of them serves a different purpose and has unique pros and cons.

Benefits of each EAF

Through the Zachman Framework, classification and organization are addressed. The TOGAF model is the best to employ if the process is the problem. FEAF is a good framework for analyzing the most highly complex and interconnected enterprises. The Gartner EAF is the most effective way to start if vision is the main problem. To evaluate these frameworks based on how they address an organization’s unique needs and circumstances, it is essential to possess a thorough understanding of the organization.

TOGAF is marketed as an EA methodology and framework, and it is distinct from the Zachman Framework in that it provides implementation guidelines for creating artifacts. It places a greater emphasis on methodology and process. The TOGAF Certification Program has gained traction among enterprise architects, most of whom strive to become TOGAF-accredited.

TOGAF has two important components for defining a common language: the content framework describes the set of key artifacts produced for supporting architecture, while the Technical Reference Model (TRM) provides a model and taxonomy for generic platform services.

Technology and risk management

A risk management program’s goal is to identify preventive and control measures to mitigate risks associated with specific activities and valuable assets. Many risk management efforts are narrowly focused, functionally driven, and disjointed. Therefore, each risk activity uses its own language, metric, and customs, leading to a fragmented view of risks. There is an inability to anticipate, control, or manage interdependent risks when there are no connections between risks and no holistic view of risk. Aiming to address the interoperability and standardization challenges in risk management, this book proposes a coordinated approach involving risk management, governance, and EA. It helps map and trace identified risks back to enterprise artifacts modeled within the EA, supporting an organization’s strategic priorities. While we are at it, let us shed some light on two levels of risks that need to be addressed, as follows:

• Initial level of risk: Prior to determining and implementing mitigating actions, categorize the risks
• Residual level of risk: Identifying and categorizing risks after mitigation

Risk management steps

There are several key steps involved in risk management, which we can cover now.

Risk classification

Any EA activity involves risk, and the ADM does as well. Risk classification is useful from a management perspective so that mitigation can be executed as quickly as possible. Among the ways that risks are classified is with respect to the impact on the organization, meaning that certain levels of governance are required for risks with particular impacts. In addition to time (schedule), cost (budget), and scope risks, others might include those related to client relationships, contracts, technology, scope, complexity, and environment (corporate).

The management of risks can also be delegated by identifying domains of the architecture. While classifying risks as business, information, applications, and technology is useful, corporate EA directorates should consider adopting or extending organizationally specific ways of expressing risk, rather than modifying them. At the end of the day, EA risks are corporate risks and should be classified and appropriately managed in a similar manner, or even more so.

Risk identification

There will be a great deal of risk involved with maturity and transformation readiness assessments. Determine a strategy to address the risks during the transformation, then identify the risks.

For specific factors associated with architecture delivery, Capability Maturity Models (CMMs) may be used to first identify baseline and target states and then identify actions needed to achieve the target state. If the target state is not achieved, risks can be discovered. It is important to complete risk documentation as part of a risk management plan, for which templates are available in certain project management methodologies, such as the Project Management Book of Knowledge (PMBOK) and Projects IN Controlled Environments 2 (PRINCE2), as well as with some government methodologies.

It is usually incorporated into these methodologies to execute contingency planning, track and evaluate levels of risk, react to changing risk levels, and document, report, and communicate risks to stakeholders.

Initial risk assessment

In order to identify risks, it is necessary to classify them according to their frequency and effect based on scales used within the organization. Putting together an initial risk assessment combines effect and frequency.

Measurement of effect and frequency does not come with any hard-and-fast rules. However, guidelines are based upon existing risk management best practices. The effect could be assessed using the following example criteria:

• Catastrophic infers financial losses that are critical enough to cause the organization to fail.
• Critical determines a loss of productivity and no ROI in the IT systems. It affects more than one line of business (LOB).
• Marginal indicates a small financial loss in the LOB and a lower ROI in the IT department.
• Negligible infers a relatively minor impact on the ability of an organization to deliver services or products.

The frequency can be indicated as Frequent, Likely, Occasional, Seldom, or Unlikely. In general, a potential plan for assessing corporate impact can include these categories of risk:

• Extremely High Risk (E): The transformation is likely to fail and with severe consequences
• High Risk (H): Significant parts of the transformation effort are likely to fail and result in the failure to achieve some goals
• Moderate Risk (M): Failure of some transformation efforts will jeopardize the success of some goals
• Low Risk (L): Some goals will not be achieved in their entirety

Organizations can assess the impact of these risks using a common structure for corporate risk impact assessment, as illustrated here:

Figure 4.1 – When assessing risk, organizations can use this assessment chart as they consider and rank risk related to their EAs

There are many approaches for risk mitigation and assessment that organizations can use, including residual, monitoring, and governance risk.

Risk mitigation and residual risk assessment

A risk mitigation strategy includes identifying, planning, and taking action to reduce risk to a manageable level. It could be as simple as monitoring, accepting, or assuming the risk, or it could be as complex as a business continuity plan (BCP) requiring complete redundancy (with all the associated cost, scope, and time implications).

The risk assessment must be done systematically and pragmatically due to its implications. As high-impact risks are mitigated in order of frequency, each risk has to be addressed separately.

Conduct residual risk assessment

After the mitigation effort has been identified for each risk, re-evaluate its effects and frequency, as well as recalculate the impacts to determine whether the mitigation has made a significant difference. Resource-intensive mitigation efforts are often necessary, and a large expenditure for little or no residual risk should be questioned. Residual risk refers to risk left over after the initial risk has been mitigated.

Risk monitoring and governance

IT governance frameworks—and, possibly, corporate governance—may approve residual risks, as well as business acceptance of residual risks. In order to ensure that the enterprise is addressing residual risk rather than initial risk, the execution of mitigating actions must be carefully monitored after acceptance of the residual risks.

In Phase G, also known as implementation governance, where risk monitoring takes place, risk identification and mitigation assessment worksheets are maintained as governance artifacts. By implementing governance, you will be able to identify critical risks that haven’t been mitigated. You may need to repeat an ADM cycle for these issues.

One of the final considerations when implementing EA is how to understand, implement, and manage collaboration and reporting to track the effects of change.

Business owners should assess their susceptibility; that way, data breaches and IT outages caused by vulnerabilities can be prevented by taking precautions against them. Some of the most promising technologies have emerged in the past few years, including cloud computing, AI, IoT, and blockchain.

If it is unclear how EA works, stakeholders will not support it. In the absence of stakeholder participation, EA programs often end up in a massive failure. As a result, management may question the value of EA artifacts because they are not being used in projects. Before starting EA programs, all stakeholders must be educated and made aware of EA’s value.

The ivory tower enterprise architect approach suggests that your chances of getting buy-in from most stakeholders are highly unlikely. Rather than imposing content on an organization, an enterprise architect leads the EA process. The architecture board represents the key stakeholders in the architecture and governs its implementation.

A chief architect who is an ineffective leader may understand EA well, but with a lack of management skills, even a good organizational structure and staffing levels cannot overcome critical issues. As a result, there is a lack of progress or a confusing architectural design. Ideally, the role of a lead architect should be filled by an individual with strong soft skills—such as enthusiasm, communication, and passion—in addition to being well respected and strategically minded.

Not establishing effective governance early on will have a devastating impact later on. All information related to architecture management, contracts, and implementation must be identified, managed, audited, and disseminated through governance processes. In the absence of governance processes, people are at risk of developing their own working styles, and no monitoring and audit tools to guide architectural design will be available. Enterprise architects should resist the temptation to set governance processes after more architecture content is available and instead, should develop governance and content at the same time.

Communication problems might not seem like a big issue but can lead to some serious misunderstandings within an enterprise. A program’s success often depends on good and continuous communication of its value and progress.

In some organizations, EA focuses mainly on technology, which has a much narrower scope than technical architecture. Business, information, and solutions architectures are all included in EA. It is possible for non-technical people to make technical decisions, while enterprise architects become too reactive and tactical when technology and business goals do not align.

Do the baseline current-state architecture first. Program goals will determine whether or not this is a risk. When an EA is being used to merge companies or for the creation of a new enterprise vision and strategic goals, this baseline architecture should not be used. Prescriptive guidance is provided in EA, but it is absent from current-state architecture. As a consequence, EA value will not be delivered on time and good future-state architecture will not be created.

EA collaboration and reporting

Through EA tools, organizations can determine both the need for and the impact of change. Integrated modeling captures the relationships and interactions between partners, operating models, capabilities, individuals, processes, information, applications, and technologies within and between an ecosystem. Those systems serve as central repositories for capturing data and metadata about the artifacts an enterprise cares about and the processes associated with them.

These artifacts are represented by models that define relationships between them, as well as help to describe and shape the future of the enterprise. EA tools help IT and the company as a whole make better investment decisions. In combination with operational performance data, models can improve business outcomes and help build and operate digital platforms more effectively.

Many organizations take the approach of engaging the assistance of EA service experts. One such organization is International Brands Limited (IBL) Group, a world-class conglomerate that manages a diverse portfolio of companies across consumer retail, healthcare, pharmaceuticals, distribution, and e-commerce. Brands on IBL Group’s client list include Johnson & Johnson, Red Bull, Mars, and Kellogg’s.

IBL was on a mission-critical SAP data migration journey. IBL leadership wanted to make the business more agile, achieve cost efficiencies, and improve stakeholder management. Downtimes were causing delays in delivery and loss of revenue. At risk were relationships with their customers and supply chain partners.

The team enlisted the assistance of NorthBay Solutions, an Amazon Web Services (AWS) Premier Partner, to guide its team through the data migration. The consulting team analyzed requirements, created a detailed roadmap, and developed a plan to migrate groups of servers in waves.

The work with NorthBay Solutions allowed IBL to realize a 30% improvement in performance, without any increase in total cost of ownership (TCO) after migrating to AWS.

What are the features of EA software?

Timelines allow users to plan, strategize, and execute long-term projects. They also make it easier for users to identify various phases and keep track of their progress. A roadmap displays strategies—along with the various relevant resources, departments, and assets—visually. In addition, they can assist with tracking progress and monitoring standards as projects are implemented.

In addition to analytics, users will also be provided with tools to analyze productivity, resource usage, and standards compliance. Planning for the future and strategizing for the task and project in question can be improved with this information. Furthermore, collaboration is the act of collaborating on tasks and projects within a platform. Next comes asset management, which refers to a tool for managing all of an organization’s assets and resources.

Budget hierarchies describe how elements of a budget structure are linked. A reporting structure can be defined and managed by administrators, along with access rights for each report. Also, the developing models of business systems are based on standards.

Managing the workspace, supporting colleagues, enabling collaboration, and building confidence within your most complex projects is the approach for Sparx Systems. In addition to TOGAF and Zachman, the platform supports several industry standards for the design and implementation of IT software and business systems. As an added benefit, Sparx Systems’ Enterprise Architect tool is cloud-based and allows global collaboration, model simulation, and complete traceability from requirements to deployment.

Sparx Systems makes its Enterprise Architect solution available in four different editions that are tailored to different scenarios. Organizations, groups, and individuals use the software to model and manage complex information. Visually connecting structures and behaviors allows organizations to build a coherent, verifiable model of what is or what will be.

Specifically, the Sparx solution has tools built into Enterprise Architect that can help teams manage complexity, as follows:

• Diagrams to represent business and strategic concepts
• Reusable model patterns and domain-specific profiles
• Tracking and version management
• Secure access based on roles to allow the right people to participate

Organizations can formally capture and track requirements from design to build to deployment and identify whether proposed changes have an impact on initial requirements, using an impact analysis to build the right system. The built-in requirements management features in Sparx Enterprise Architect can be used to define a requirement model, track system requirements, report requirements, and analyze proposed changes.

As a result of Sparx Enterprise Architect’s highly crafted patterns and reusable model structures, it will expedite your development work and help you achieve accurate and stunning models that leverage a strong and proven foundation. You can reduce noise by focusing on one modeling challenge at a time. Push other technologies and tools into the background as you concentrate on business analysis, strategy, or software design.

EA and digital transformation

Businesses have always benefited from strategic planning. However, with the urgency of digital transformation and the complexity of these initiatives, such planning has become even more critical. This complex technology is connected with the business context through EA to drive desirable business outcomes.

Different organizations have varied meanings of digital transformation that include technology trends such as the shift to cloud services, the adoption of AI and machine learning (ML), advanced analytics and big data infrastructure, the emergence of IoT, the rise of robotic process automation (RPA), and more.

In business and organizations, digital transformation is defined as the ability to effectively leverage the challenges and opportunities of mixed digital technologies in a strategic and prioritized manner in response to current and future shifts in society. Organizations can react faster to market changes by transforming; this allows them to be as flexible and dynamic as possible. Financial services are an example of one industry where it has become a competitive necessity.

The cloud offers businesses the ability to deploy software-as-a-service (SaaS), RPA, and AI at a rapid pace. Because many projects need to move at a much faster pace, digital transformation changes everything for enterprise architects and enterprise project management offices (EPMOs). As with the print press and the internet, this digital revolution can be compared to the invention of the printing press. All enterprises are questioning business models, technology has gained importance in the process, and enterprises are faced with new challenges on almost every next move in this era of collaboration.

What does digital transformation mean for enterprises?

Everyone is affected by the digital revolution, hence companies must find new ways to collaborate to succeed in these times. Digital transformation happens at its own pace, and it cannot be viewed as a one-size-fits-all process. Enterprises maintain their own unique IT legacy systems and processes, and they are subject to different external regulatory requirements and market pressures. Successful enterprises treat the transformation as an ongoing process because industry maturity affects the path to digital excellence. A variety of strategies and paces are used in this process in order to address business needs.

For enterprises of all sizes, technology is gaining importance as business models are being questioned. Despite the move from the periphery to the center of enterprises, knowledge is still dispersed. Because of a lack of transparency, local decisions are made disregarding the implications of those decisions for the organization as a whole. Digital transformation is more likely to fail when it is centrally managed, which makes it crucial for enterprises to make distributed knowledge available across the board.

Successfully implementing digital transformation with EA

As a general rule, digital transformation is extremely complex, individual, and very expensive. The first step to implementing frameworks—which often fail—is to understand and then improve your business data, as well as your IT infrastructure. Your EA can be determined and filled with sufficient data once you have completed this step.

To better understand the application that matters most for a business and the evolving trend regarding this application, we must know to address the basics, finding the right people in the business who can give the right definition of an application and the business individually as well as together. Then, use their answers on IT as a beginning point and find a simple model to create transparency on this view.

Managing application portfolios in such a situation is extremely helpful. You will be able to develop a first-shot classification of user groups and business capabilities after having gathered first sight into how IT applications are viewed from the business side. Combining a high-level assessment of the business criticality report and the functional and technical fit of the business with the application can prove effective. It becomes an invaluable tool for the business and IT to spot improvement opportunities quickly.

Dealing with operational issues

As soon as you begin working on a strategic project, an operational question distracts you. EAs know all too well the challenges of staying current with the latest operating systems, responding to urgent requests for business support from unknown groups, and cutting costs by eliminating redundancies. Identify these issues proactively to avoid distractions before they become a problem. You are distracted because you don’t know which applications are affected by an operating system or major database update. When you know which major technology is used by your top business applications—omit any details—you can take proactively calculated decisions.

Business support requests usually come from out of nowhere; however, having compiled your application portfolio landscape, you will be in the driver’s seat. Specifically, try to get an assessment of which user groups and capabilities your business deems most vital, and focus on the problems surrounding those groups. The application portfolio landscape contains all the information you need and use to deal with traditional requests for cost-cutting. All you need to do is pinpoint low-hanging fruit before your competitors do. As soon as you have penned down the key applications, the most pressing improvements, and taken care of any operational concerns, it is time to get serious about data and how it drives your business. Typically, this is accomplished at two different levels of granularity. The key data objects that drive the business are of primary importance at the business level. Nothing more can be said than that the needs of your stakeholders should be your top priority. Concentrate on their value to your company, and they will form the coalition you desperately need.

Following the creation of the first business value, EAs are able to look further into the future because of the level of trust between peers and management. Providing the enterprise with ways to implement target architectures is their responsibility. Nonetheless, they need to keep in mind that focusing on creating business value and high-quality data is imperative to avoid fallacy.

At the end of this chapter, we conclude that despite the fact that EA has often been put forward to help businesses innovate and transform, it has traditionally been focused on standardizing processes and integrating technology rather than continuously adapting to change. The new digital environment requires more adaptive conceptualizations of EA in order to achieve the desired impact. Digital transformation has implications for EA, as we explored. Existing approaches to EA address integration and coherence within an organization, but they often fall short when it comes to the complexities associated with digital ecosystems. In a digital environment, we postulate that adaptive capabilities are needed that transcend the concept of dynamic capabilities.

Summary

The role of enterprise architects is to take on these problems head-on by providing a roadmap to manage and reduce complexity, which contributes directly to reducing costs. Enterprise architects ensure that IT is aligned with business goals and standards.

Within an EA, the primary objective is to ensure a reduced cost of business operation, an agile organization and workflow, shared business capabilities and access across the organization, and more. In the light of these goals, enterprise architects fit best in multiple use cases such as mergers, integrations, risk assessment, management, and so on. The EA also includes governing principles that discuss how business strategy can be realized through IT implementation.

In the absence of stakeholder participation, EA programs often end up being a massive failure. EA often focuses only on technology, which has a much narrower scope than technical architecture. Business, information, and solutions architectures are all included in EA.

Lastly, digital transformation is defined as the ability to effectively leverage the challenges and opportunities of mixed digital technologies. Business organizations handle this in a strategic and prioritized manner in response to current and future shifts in society.

Successful enterprises treat digital transformation as an ongoing process because industry maturity affects the path to digital excellence. Conclusively, the new digital environment requires more adaptive conceptualizations of EA in order to achieve the desired impact. Digital transformation has implications for EA.

In the next chapter, we will cover prescriptive guidance from AWS on migration to the cloud. We will cover how to identify business objectives for cloud migration, a review framework, readiness assessment phases, and adoption and delivery frameworks.