9

Setting Up an Enterprise Architecture Practice

The success of a company’s growth prospects depend on its digital transformation. To make themselves more competitive and relevant to their customers, large companies, in particular, must complete their business transformation through technological change. While more technology-savvy competitors seize market share and customers, they want to seize digital growth opportunities. An enterprise architect’s role in transformation is crucial since they have visibility into the entire business process and are aware of how the IT landscape affects business outcomes.

As business changes constantly, enterprises need to easily assess the impact of these changes on the IT landscape, and how they will affect their operations, customer experiences, and their ability to grow. An overview of these issues can boost the transformation process. Enterprise architects ensure that IT is ready to run upcoming business transformational projects by maintaining a streamlined and agile IT landscape.

This chapter will cover the following topics:

• Enterprise architecture practice and the Center of Excellence
• The enterprise architecture approach
• The process and workflow within enterprise architecture practices
• Goals of enterprise architecture
• Benefits of enterprise architecture
• Enterprise architect role
• Enterprise architecture tools and software
• Enterprise architecture practices with roles
• Enterprise architecture practices with responsibilities
• Setting up the Architecture Board
• Operation of the Architecture Board
• Characterization in terms of enterprise segmentation
• Architectural tools and modeling languages
• Full collaboration between IT and business stakeholders
• Recommended steps for adopting an Enterprise Architect Management tool
• Initiating and evolving an enterprise architectures (EA) practice in organizations
• Developing digital skills

Enterprise architecture practice and the Center of Excellence

By creating an infrastructure used throughout the company, enterprise architects can map the current IT environment. Multiple perspectives can be used when performing the application inventory, such as the application life cycle, costs, deployments, exchange flows, and how they support the business. We add information to the inventory via the data collection and crowdsourcing process in addition to roles, processes, locations, and vendors. The outcome of these steps is capability maps that help fill operational gaps by reflecting the organization’s business capabilities. To conduct objective analysis, enterprise architects use the collected data, including key performance indicators (KPIs) such as life cycle, cost, risk, enabling technology, and vendor dependency.

Additionally, they are going to perform subjective analyses by giving stakeholders automated questionnaires to determine whether the applications they use are efficient, effective, and meet their business needs. Based on importance and value, enterprise architects consolidate scores and cross-reference KPIs. Getting the most critical applications first is imperative to ensuring that the most important resources and investments are invested into those applications.

The enterprise architecture approach

IT portfolios can be standardized so that enterprise architects can avoid obsolescence by using technology architecture management. Technologies are inventoried with vendor and life cycle information (release date, end of life, and so on) that’s been obtained from existing Customer Managed Databases and cleansed. A normalization tool can streamline technology names when there are multiple sources of information. A technology life cycle database and technology inventory may also be compiled from external libraries.

After that, they conduct the following procedures:

• Pick the technologies that will be evaluated as standards, based on feedback from developers, architects, and risk managers.
• Decide whether to rate the vendor based on its ability to support applications, its business capabilities, or its vendor dependency.
• Throughout the various stages of a technology’s life cycle, its status can be updated:
  • Envisioning: Currently, potential applications for the technology are being assessed.
  • Emerging: The technology is still under development. The technology has not been widely deployed yet.
  • Confirmed: The organization understands the technology and has full access to it.
  • Obsolete: Obsolete technology may pose risks. Once the technology has been evaluated, we can determine whether it is compliant with the company’s standards and put it in one of two categories:
    • Approved: Technologies that meet company policy and are considered standard
    • Permitted: Technologies approved by the company
  • Prohibited: Technologies prohibited by the company.

The first step to achieving business objectives is to establish clear goals. With support from business teams, enterprise architects can map current business capabilities and analyze how they may change. This helps you understand how a capability should develop in the future or whether it can address a new customer segment or align with the business strategy. Business architects use enterprise roadmaps and timetables to capture and measure current and future business needs. After that, the enterprise architects ensure that the future IT architecture supports business capabilities. By defining business capabilities based on a map of the current IT environment, they can develop a new IT architecture. When a company evolves to meet new challenges, capability maps identify what IT resources are required.

The keys to successful data governance are to define standard data governance processes, share best practices, and document data usage throughout the entire business process chain. Data that’s been collected, processed, and managed by a business is clarified and made easier with EAs. Business glossaries and semantic representations of an organization are developed by data architects or data stewards through the EA process. It is possible to create a data dictionary and model existing databases logically. In this process, the consultants discover data from existing sources or data lakes and extract metadata from them to rationalize it. Data dictionaries are then able to connect with business data. Architects can use this information to analyze the impact of a potential change by automating the linkage of data, which allows for business data lineage. Having a consistent representation of their business and technical data helps the company anticipate and manage continuous market changes. Additionally, companies can increase compliance with the following revised regulations by consolidating general data protection regulation (GDPR) requirements with EA, such as the California Consumer Privacy Act:

• EAs need to describe how personal data is processed in their applications so that GDPR impacts can be documented.
• Reusing applications developed by EAs support GDPR compliance officers (Data Protection Office) in documenting GDPR processing activities more easily.
• The DPO can access detailed information concerning existing GDPR processing activities by accessing business processes and applications. This information is often presented in the form of diagrams, flowcharts, or detailed descriptions.

There is a common belief that enterprise architects live in an ivory tower and that they are disconnected from reality and are unable to demonstrate the business value produced by EA. Nonetheless, enterprise architects play an important role in facilitating digital business transformation in today’s highly disruptive and agile environments.

As a business partner

The benefit of working with agile teams and being a true business partner is that the business partner can highlight trends and provide valuable insight for digital transformation. The enterprise architect makes strategic recommendations as a business partner. Assessing the potential of emerging technologies, assessing the impact of implementing business changes on IT systems, and setting up an entirely customized ecosystem are some of the tasks they perform. They demonstrate the value derived from the connections between people, processes, applications, and infrastructure in their role as a business partner.

The role of enterprise architects today includes doing the following:

• Often, organizations work in silos and lack an overall view as a result of organizational silos. They must bring a strategic vision to these organizations.
• Participate in business discussions to refine its needs, giving examples of how a business capability should evolve over the next 3 years, or whether the company is capable of addressing new customer segments.
• Contribute to a better IT roadmap that improves business effectiveness and efficiency while planning future IT investments in the enterprise.

As a technology trendspotter

Investing heavily in emerging technologies is one of the key indicators of a company’s competitiveness. In 2017, Forrester surveyed 105 international technology executives online. According to the survey, 86% of leading companies saw technology as the most influential factor in business strategy. As companies attempt to understand and analyze the impact of emerging and strategic technologies, enterprise architects play a key role. Digital business platforms are defined as a way to deliver value to the modern enterprise by these leaders, who take a hands-on approach.

Trendspotters are enterprise architects since they can see market trends and potential value in upcoming technologies. They primarily deal with new or emerging technologies or those that may disrupt the market. By using the technologies that will move their company ahead of competitors, they help business leaders and IT teams make better decisions. By combining IT capabilities and business strategies, enterprise architects also serve as pacesetters for business transformation.

As an active member of agile dev teams

In agile environments, development happens quickly, and the eleventh principle of the Agile Manifesto empowers agile teams to design whatever architecture is needed. It is known as emergent design in the SAFe framework. In addition, some development teams do not have an understanding of organizational business objectives, technical standards, or other architectural projects that are in progress. Using architectures designed by development teams can drive reworks and affect time to market.

An enterprise architect’s role as a member of an agile team includes doing the following:

• Sharing the intentional architecture with the development teams and identifying its limitations. Developing teams can then assist in correcting the intentional architecture.
• Using the SAFe framework, an architectural runway is created by combining emergent design and intentional architecture. As new epics are developed, enterprise architects must not only keep the architecture up to date but also support new epics.

As an influencer and leader

One of the most influential leaders in an organization is the enterprise architect. As change leaders, they leverage enterprise assets, explore new business opportunities, and leverage emerging technologies. Traditionally, EA has been viewed as a cost center that creates architecture just for the sake of architecture, resulting in a lot of wasteful spending. To move from being perceived as noisy to being truly influential, enterprise architects can take multiple steps to accelerate and elevate their value.

All companies need to approach digital transformation from a new perspective, absorbing best practices that have proven successful over the last few years. Furthermore, it prioritizes EA as a critical component of the business transformation and innovation process. To ensure the success of an organization’s digital transformation initiative, an enterprise architect must be employed. Enterprise architects analyze the impact of constant business changes to offer an integrated view of the impact of business digitization, IT strategic planning, data governance, and more.

Digital twin technology and artificial intelligence (AI) will provide new challenges for enterprise architects since both are expected to accelerate the process of digital transformation. Within this context, EA models will be enhanced (by data mining) by incorporating real data at the business and application levels. By analyzing the data, architects can identify the gaps between theoretical models and the real world and determine the most critical areas where systems can be improved or failed. To accelerate digital transformation, enterprise architects play a crucial role. These experts assist decision-makers in implementing strategic business planning, adopting emerging technologies, improving customer experience, and safeguarding data.

To build digital twins, you must start with a workspace that represents a single work site. A workspace holds all the resources (such as models and visual assets) needed to create the digital twin. Inside the workspace, you can create entities that represent digital replicas of their real-world systems. You can also specify custom relationships between the entities that will form a digital twin graph. Then, you must connect to data from various data stores and add equipment context to the stored data. AWS IoT TwinMaker makes it simple for you to bring this data together without creating another data store and without requiring you to reenter the schema information that already exists in your data stores. To provide context to the data present in the data stores, you can associate entities with built-in connectors to these diverse data stores, such as time-series sensor data in AWS IoT SiteWise, video data in Amazon Kinesis Video Streams, and document data in Amazon S3.

The process and workflow within enterprise architecture practices

The practice of enterprise architect is to analyze, design, plan, and implement enterprise strategies in a way that facilitates business success. Using architecture principles and practices, enterprise architects help companies structure their IT projects and policies to achieve business outcomes and stay current with market trends. This process is also referred to as enterprise architectural planning. EA emerged from various architectural manuscripts and business systems planning in the 1960s, according to the Enterprise Architecture Book of Knowledge (EABOK). During the 1980s, when the first computers were introduced into the workplace, the EA framework emerged to respond to the increase in business technology. Technology has grown rapidly, and companies have realized that they need a long-term strategy to support that growth.

A modern-day EA strategy encompasses the entire organization, not just IT, to make sure the business is aligned with digital transformation strategies and technology growth. It is especially beneficial for businesses with legacy processes and applications to implement a digital transformation program such as EA since it merges them seamlessly.

Goals of enterprise architecture

Business requirements guide the organization’s EA. Among other things, they determine how information, business, and technology flow within the organization. Cloud computing, IoT, machine learning (ML), and other emerging trends such as these have become priorities for businesses attempting to stay on top of the latest technologies.

As per the EABOK, a comprehensive understanding of the interrelationships within an IT organization is gained by combining people, data, and technology. From the perspectives of the owner, designer, and builder, the process takes a comprehensive view of the entire enterprise. This framework does not rely on formal documentation; instead, it is designed to offer an enterprise view from a holistic perspective.

EAP strategies must take into account the latest developments in business processes, organizational structures, information systems, and technology. Standard language and best practices will also be covered, as well as how to integrate or eliminate processes in various parts of the organization. Business information should be reliable, timely, and as efficient as possible.

Benefits of enterprise architecture

In redesigning and reorganizing activities, especially in mergers or acquisitions, EA can help. Additionally, standardization and consolidation of processes promote more consistency within an organization. The most important benefits of EA, according to CompTIA, are as follows:

• Allowing IT and business units to collaborate more easily
• Making investments easier for businesses
• Facilitating long-term evaluation goals by evaluating existing architectures
• Setting up processes for evaluating and procuring technologies
• Increasing the level of understanding of the IT architecture outside of IT by giving all business units a comprehensive view
• Setting up benchmarks for benchmarking against other organizations or industry standards

A result of EA is a reduction of errors, system failures, and security breaches, as well as IT management. The technology can also make IT more accessible to other business units or enable businesses to navigate complex IT structures.

Enterprise architect role

A company’s architect typically reports to the chief information officer (CIO) or another IT manager. The job of a business analyst is to assess the alignment of business structures and processes to the company’s goals. An enterprise architect must also ensure structures and processes are agile and robust so that they can quickly adapt to changes and withstand major disruptions.

Data from PayScale indicates that the average salary for this role is $128,600 per year, with a salary range of $93,000 to $190,000 per year. CTOs, developers, software engineering directors, and CIOs are often acquired from enterprise architects. An enterprise architect needs at least 10 years of experience in IT or a related field, as well as an undergraduate degree in computer science, information technology, or a related field. PayScale reports that IT enterprise architects require the following hard skills:

• Service-oriented architecture (SOA)
• Enterprise application integration
• Cloud computing
• Software and systems architecture
• Enterprise solutions
• Strategy development
• IT and project management

Furthermore, you need to have a thorough understanding of computer systems, hard drives, mainframes, and other architecture technology. Communication, teamwork, problem-solving, critical thinking, and leadership are all soft skills enterprise architects need to possess.

Enterprise architecture tools and software

To plan EA, you’ll mostly use Excel and PowerPoint. Several popular options currently available on the market are based on Gartner Peer Insights:

• Orbus Software
• Sparx Systems
• Software AG
• Avolution
• Mega
• Erwin
• BiZZdesign
• Planview
• BOC Group

However, there is another set of tools and software suites that can help your business develop advanced EA strategies.

Enterprise architecture practices with roles

In architecture, architectural artifacts are documents that describe the state of an enterprise, a system, or a solution. System environments are the factors that determine all the external influences that have an impact on a system. The environmental factors that can affect a system include developmental, technological, economic, legal, governmental, ecological, and societal factors. A system, however, refers to a set of interconnected components that perform one or more predetermined functions.

Architects define architecture as the fundamental concepts or characteristics of a system. Architectural descriptions are work products that are used to convey information about an architecture; they consist of views and models that, together, describe the architecture. Stakeholders, on the other hand, consist of individuals, teams, or organizations that have an interest in a given system.

The term concerns refers to one or more stakeholders who are interested in a system. Any aspect of a system’s development, operation, or functioning, including performance, reliability, security, distribution, and evolvability, may be considered a concern or a determinant of its acceptability. Taking a system architecture view is like representing a system from the view of a specific set of concerns. A system architecture model represents what a system is like. Architecture models represent subjects of interest. As a simplified representation of a subject, a model presents the subject matter at a smaller scale.

One or more architecture models may be created by an architect as part of capturing or representing the design of system architecture. As a result, an architecture view will consist of elements of one or more models, chosen in such a way as to demonstrate that the concerns of one or more stakeholders are being appropriately addressed in the design of the system architecture. Generally, an architecture view is an architecture specification of conventions for an architectural view to be implemented. This kind of architectural view can be referred to as a definition or schema. To address a particular concern (or set of concerns) about a system of interest, it establishes conventions for constructing, interpreting, and using an architecture view.

Model kinds establish a type of modeling convention. Models may be viewed through an architecture viewpoint; an architecture view may include several models. The Reference Library portion of the Architecture Repository contains a collection of specifications for architecture viewpoints:

• Viewpoints that determine what you see, from what vantage point or perspective
• An architecture view is always specific to the architecture that it depicts and can be stored in libraries for reuse; a viewpoint is generic and can be stored in libraries for reuse
• It’s at least implicitly described by an architecture viewpoint associated with every architecture view

Be aware that concern and requirement are not synonymous. They describe different things. Some stakeholders may have a concern/an interest in system reliability. Architecture viewpoints should be associated with concerns to ensure that these concerns will be addressed in some way by the architectural models. Architects who only select a structural architecture viewpoint, for example, are almost certainly not considering reliability issues, because a structural model cannot represent these problems. There may be many different stakeholder requirements within that concern; there may be different requirements of different classes of users in terms of the system’s capabilities.

An Architecture Board overseeing the implementation of the strategy is essential to a successful Architecture Governance strategy. Typically, this group comprises executives responsible for reviewing and maintaining the overall architecture, as well as a representative of all the key stakeholders. The majority of architecture boards in larger organizations are made up of representatives at least two tiers deep – that is, local (domain experts' line responsibility) and global (organization-wide responsibility). A board will be established in such situations with identifiable and articulated duties:

• Responsibility and ability to make decisions
• Limitations on authority and remit

Enterprise architecture practices with responsibilities

The following goals are typically entrusted to the Architecture Board:

• Establishing the basis for all architecture-related decisions
• Maintaining consistency across sub-architectures
• Setting targets for reusing components
• Creating a flexible EA to leverage new technologies and meet changing business requirements
• Ensuring that compliance with the architecture is enforced
• Initiating a maturity level improvement of the architecture discipline in the organization
• Ensuring that architecture-based development is implemented
• Enhancing the visibility of escalation capabilities for out-of-bounds decisions

The following responsibilities should be addressed from an operational standpoint:

• Monitoring and controlling all aspects of the Architecture Contract
• Holding regular meetings
• Managing and implementing the architectures in an effective and consistent manner
• Resolving escalated ambiguities, issues, or disputes
• Assisting with information, advice, and guidance
• Implementing a technology strategy and objectives, ensuring compliance with architectures, and granting dispensations as necessary
• Considering changes in policies that are requested and granted for similar dispensations, such as new service types
• Obliging with the Architecture Contract implementation team to publish all information relevant to implementation under controlled conditions and make it available to authorized parties
• Verifying the reported service levels and cost savings

Moreover, the Architecture Board is responsible for the following from a governance perspective:

• Developing usable materials and activities for governance
• Establishing a formal system for the acceptance and approval of architectures through consensus and the authorized publication of architectures
• Ensuring effective implementation of the architecture by providing a fundamental control mechanism
• Implementing EA and linking it to the strategic objectives of the business, based on the architectural strategy and objectives embodied therein
• Dispensations or policy updates may be needed to realign the architecture and planning activities

In the process of detailing requirements, concerns are the starting point. The requirements are what represent concerns in the architecture. It is a good idea to have SMART requirements (that is, specific metrics).

Setting up the Architecture Board

The CIO (or another senior executive) is often the executive sponsor of the initial architecture effort in most companies. Sponsoring bodies have more influence, however, when it comes to garnering corporate support. An Architecture Board is the sponsoring body here, but the title isn’t important. The strategic architecture and all of its sub-architectures are reviewed and maintained by this executive-level group.

Triggers

Typically, an Architecture Board is established in response to one or more of the following:

• The new CIO
• Acquisitions or mergers
• Considering switching to a more advanced form of computing
• Recognizing the lack of alignment of IT with the business
• Technology as a means of achieving a competitive advantage
• Implementation of the EA program
• Rapid growth or significant business changes
• Cross-functional requirements for complex solutions

Within the enterprise, the Architecture Board sponsors the architecture, but the Architecture Board itself requires an executive sponsor at the highest levels of the corporation. Architecture projects must be committed to during the planning process and through maintenance. In some companies, architecture planning fails because executive participation and encouragement are lacking.

In many cases, the Board of Directors of a company is overlooked as a potential source of Architecture Board members. Such individuals are often knowledgeable about a business’s operations and competitors. They are an important part of validating the alignment of IT strategies to business objectives since they influence the business vision and objectives.

Size of the Architecture Board

We recommend that an Architecture Board includes four to five permanent members (10 at the most). It may be possible for the Architecture Board to rotate its membership over time, with decision-making privileges and responsibilities transferring from one senior manager to another, to keep the Architecture Board to a reasonable size. Some members of the Architecture Board may find that time constraints prevent them from participating actively for a prolonged period.

The Architecture Board must, however, maintain continuity to prevent the corporate architecture from diverging from one idea to the next. Rotation can be ensured by setting a term for each member and having the term expire at different times. An Architecture Board may need to be re-chartered during the ongoing architecture effort following the initial effort. If needed, the architecture compliance review process is updated or changed by the executive sponsor after reviewing the work of the Architecture Board.

Board structure

A generic organizational framework provided by the TOGAF Architecture Governance Framework positions the Architecture Board in the context of the broader enterprise governance structure. In addition to identifying the major organizational groups and responsibilities, it also outlines their relationships with each other. Adaptations of this model may be necessary, depending on the structure and form of the organization.

Taking into account the size and form of the organization, as well as the IT function implementation, is essential. By taking the overall governance environment into account, you can form the basis of designing the Architecture Board structure. An important concept to consider is worldwide ownership and local implementation, and the integration of new technologies and concepts from various areas.

As an organization, the Architecture Board should be structured according to its structure. There may be more complex architecture governance structures needed than the TOGAF Architecture Governance Framework outlines. An organization would need to put an IT governance process in place that combines the corporate structure and capabilities already in place. It typically includes a global governance board, local governance board, design authorities, and working parties.

Operation of the Architecture Board

In this section, we will describe the Architecture Board primarily from the perspective of governance.

General

Meetings regarding the Architecture Board need to have clear objectives, topics, and actions. The Control Objectives for Information and Related Technologies (COBIT) framework, as an example, explains best practices for board meetings. During these meetings, key decisions will be made regarding the following:

• Producing quality governance materials and activities
• Providing a formal mechanism for acceptance through consensus and authorization
• Implementing a control mechanism that ensures the architectures are implemented successfully
• Linking architecture implementations with organizational strategy and objectives (business and IT) and maintaining this link
• Dispensations or policy updates may be needed to realign with the contract in the event of divergence from it

Moreover, the agenda of a meeting regarding the Architecture Board contains clearly defined topics and the required actions.

Preparation

Each participant should be familiar with the contents of the agenda and all supporting paperwork, such as dispensation requests, performance management reports, and more. Individuals who have assigned actions are responsible for reporting on progress against those actions. Attendance and availability at Architecture Board meetings must be confirmed by each individual.

Agenda

Agendas for Architecture Board meetings are outlined in this section. The items on the agenda are all described based on their contents.

Minutes of the previous meetings

The minutes of previous Architecture Board meetings are a standard organizational protocol that provides details about past meetings.

Requests for change

Change requests under this heading typically relate to architecture and principle amendments. The business control may also include blocking voice traffic to premium members, such as weather reports, and controlling access to certain websites. The Architecture Contract defines authority levels and parameters within which changes can be requested.

Dispensations

As a mechanism for requesting changes to existing contracts, principles, and structures, dispensations are used. The agency also operates outside of normal operating parameters, such as having a subsidiary excluded from service provisioning, requesting unusual service levels for special business reasons, or deploying non-standard technology or products to support specific business initiatives.

Dispensations are granted for a set period and must comply with certain operational criteria and a set of identified services. Compensations are not granted indefinitely but serve as an alternative way of ensuring that levels of service are met, as well as allowing for flexibility in the implementation and timing of payments. Time-bound dispensations will trigger architecture compliance because of their time-bound nature.

Compliance assessments

The organization assesses compliance against service-level agreements (SLAs), operational-level agreements (OLAs), and the required architecture refreshes. Based on the criteria specified in the TOGAF Architecture Governance Framework, the assessments will either be accepted or rejected. Assessment reports will contain detailed information about the architecture.

Dispute resolution

In the Architectural Compliance assessments and dispensation, disputes that have not been resolved through Architecture Compliance and dispensation processes are documented.

Architecture strategy and direction documentation

Only the global Architecture Board will formulate the architecture strategies, directions, and priorities. Standard architectural documentation should be produced.

Actions assigned

An overview of actions assigned at previous Architecture Board meetings is provided in this report. During Architecture Board meetings, actions are assigned to a tracker, which is used to keep tabs on their status and document how they are progressing:

• Reference
• Priority
• Action description
• Action owner
• Action details
• Date raised
• Due date
• Status
• Type
• Resolution date

Contract documentation management

The architecture documentation is formally accepted here for subsequent publication, updated, and changed.

Any other business (AOB)

This includes issues that fall outside of any of the aforementioned stages. They should be raised at the beginning of the meeting, regardless of whether they are included in the agenda. It is the responsibility of Architecture Governance to manage supporting documentation.

Scheduling meetings

Dates for all meetings should be published in detail. The enterprise architect is a visionary, coach, team leader, liaison between tech and business, and an expert in their field.

Enterprise architect job description

Achieving a complete architecture requires the architect to adequately respond to all the pertinent concerns of its stakeholders. They must ensure that all perspectives are connected, reconcile the conflicting interests of key stakeholders, and indicate the trade-offs made to do so. A key component of the enterprise architect’s role is to decide which architectural views to develop. It is imperative to limit the choice to practical factors, as well as to the principle of fitness-for-purpose. As an enterprise architect, your role is more similar to a city planner than a building architect. Rather than defining the enterprise architect’s work as a well-designed building or set of buildings, it is more appropriate to describe the community architect’s work as a planned community.

An enterprise architect does not create the technical vision of an enterprise, but rather develops and articulates the technical vision in consultation with executives of the enterprise and formulates the strategy to realize that vision. Business plans are always connected to this plan, and design decisions also follow the business plans. This ensures design decisions are not circumvented for tactical convenience since the enterprise architect’s strategic plan is linked to the Enterprise Architecture Governance process.

For implementation teams and application development teams, enterprise architects document design decisions.

Throughout the entire process, an architect assists the customer in understanding their needs versus what they want, translating those needs into capabilities that are verified to meet their requirements. In addition, the architect may present each customer with different models that demonstrate how those needs could be met, thus making them indispensable to the consultative sales process. An architect cannot be a builder, and they must remain abstract enough to not hinder implementation.

Hence, the architect’s role may be summarized as follows:

• Understand and interpret requirements

This involves information gathering, listening, influencing, consensus building, synthesizing ideas into actionable requirements, speaking those ideas to others, identifying use or purpose, constraints, risks, and so on. In addition to discovering and documenting the customer’s business scenarios that drive the solution, the architect contributes to the solution’s concept design process.

• Create a useful model

This involves taking the requirements and formulating effective models of the solutions, augmenting the models as needed to address all of the circumstances, and communicating the ideas in multiple ways through the models.

In terms of architecture, the architect is responsible for maintaining the vision of the offering and preserving architectural integrity. Additionally, the architect ensures that leverage opportunities are identified and that they are realized by leveraging building blocks as a liaison between the functional groups. Architects build and maintain these models to guide work within or outside the organization and to understand the domain of development work. An architect must understand all the business components to represent the organization’s architecture.

• Validate, refine, and expand the model

The model should be revised and further defined, using subject matter experts if needed, to increase flexibility and to ensure it is based closely on current and expected requirements. Architects should also consider the value of any enhancements that arise from fieldwork and include them in architecture models where appropriate.

• Manage the architecture

The models should be regularly updated to display changes, additions, and alterations as necessary. They must assist with discussions and decisions about the program’s architecture. Architects represent change as an agent for implementing the architecture. Through this process, the architect ensures that information about the customer, architecture, and technical aspects among organizations is shared continuously.

Characterization in terms of enterprise segmentation

In certain scenarios, additional architects may be required to support the architecture effort due to the complexity of a solution. All categories of architects do the tasks outlined previously as well. An enterprise, enterprise solution, and solution architect team can come together to accomplish the task. Depending on the phases of the development process, each member may have a specific focus, if not a specific role and responsibility. If it is deemed necessary to organize an architectural team, a lead enterprise architect must be assigned to manage and lead the team, as follows:

• The enterprise architect is responsible for applying architecture design and documentation to both the technical and landscape reference models. In most cases, the enterprise architect leads a team of segment architects and/or solutions architects to implement a particular program. The focus of the enterprise architect is on the enterprise-level business functions required.
• The segment architect documents and designs specific business problems of organizations. They combine detailed technical solutions with the overall architectural landscape, relying on the output from all other architects. The segment architect is responsible for scoping enterprise-level business solutions across multiple domains, including finance, human resources, and sales.
• Solutions architects are responsible for designing and documenting systems at various levels, such as management and security. By shielding the enterprise/segment architect from unnecessary details of systems, technology, and products, solutions architects might benefit enterprise/segment architects. The solution architect deals with system technologies. For example, a component of an enterprise data warehousing solution would fall under this focus.

Skills and experience in producing designs

Designing complex systems requires the skills of enterprise architects. In addition to discovering and analyzing requirements, it involves identifying and assessing solution alternatives, selecting technologies, and configuring designs.

Extensive technical breadth with technical depth in one or more disciplines

Having experience in the IT industry is an important qualification for an enterprise architect. In addition, the team will be able to develop and deploy applications, as well as design and maintain the infrastructure for complex application environments. In today’s IT environment, heterogeneity is the norm, which means experienced enterprise architects must be able to work across multiple platforms, from traditional mainframes to distributed systems. At the end of their careers, enterprise architects will possess expertise in at least one field that they are considered to be subject matter experts in.

Method-driven approach to execution

The TOGAF Architecture Development Method (ADM) is among the most recognized design methods used by enterprise architects. Enterprise architects should be knowledgeable about more than one design method and should be able to accurately adapt parts of those methods to the circumstances in which they find themselves. An enterprise architect demonstrates this in their repeated use of more than one design method when they’re creating their design work. To use methodologies proficiently, you must know which parts of methods to use and which not to use in a given situation.

Full project scope experience

The role of the enterprise architect is to design the project and hand it off to the implementation team, but it is vital to have experience with developing, testing, implementing, and supporting all stages of the project. Enterprise architects will benefit from this range of experience as it will help them use the notion of system implementation that is practical and fit for purpose. As an enterprise architect, experience with full project scope should lead to greater design decisions, and ultimately, better-informed decisions regarding tradeoffs.

Leadership

For an enterprise architect to succeed, communication and teamwork are essential. To be successful at this job, you need both good technical skills and leadership qualities. IT management and clients should regard enterprise architects as leaders in the enterprise.

Personal and professional skills

Communication and relationship skills are essential for the enterprise architect. The enterprise architect is responsible for communicating complex technical information, including those without technical training, to all stakeholders of the project. The role also requires excellent communication and negotiation skills. To keep projects on track, enterprise architects must work closely with project managers to make timely decisions.

Skills and experience in one or more industries

The enterprise architect can gather requirements more easily and more effectively if they have expertise in the industry. A good enterprise architect should understand how a company’s business processes interact with the processes of peers in the same industry. As well as spotting key trends and identifying flawed processes, they should be able to provide IT groups with the capability to lead enterprises, not just to respond to requests. A business architect’s role is to be a strategic technology leader.

Architectural tools and modeling languages

Enterprise architecture tools aimed at helping organizations thrive in the future are designed to help them succeed. The following enterprise architecture tool features will help your business goals align with IT when selecting the best solution for your team and company.

Fast time-to-value

Enterprise Asset Management (EAM) tool adoption, and how quickly it produces value for an organization, determines the success of an EA strategy. An organization has to wait 3 to 6 months for results when using legacy tools, as well as have a lot of customizations made to them. Although modern EAM software is more intuitive and yields much faster results, it has a learning curve. There are several features of EAM tools that set them apart from legacy products:

• In today’s EAM world, out-of-the-box and ready-to-use products provide strong data models based on industry best practices and they are easy to understand.
• Intuitive user interfaces require little training and customization, and they’re ideal for launching products across organizational silos.
• Costs are based on how many applications are stored in the repository, rather than how many users use the service. Multi-user access and cross-institutional collaboration are the benefits of this concept.

Best practices and a flexible data model enable them to be easily configured without requiring extensive initial configuration. Also, the model can be adapted as they go, allowing them to gain valuable insights early on.

Full collaboration between IT and business stakeholders

Legacy EAM tools typically require a background in IT and are thus out of reach for those who do not possess a computer science degree. However, modern EAM tools are designed for a variety of users, have an intuitive interface, and let anyone understand the data models. Also, this means that enterprise architects aren’t isolated in an ivory tower, but are part of the daily activities of all business functions. By making modern EAM tools more user-friendly, a broader range of users can access them, thereby increasing data diversity.

Here are the characteristics that matter most:

• Using application owners and subject matter experts as crowdsource EA resources
• Optimizing the impact of IT on business outcomes through a unified language
• Providing easy access to information relevant to business needs by customizing information displayed for individual stakeholders

However, there are certain challenges that companies face in their EA efforts. The biggest one is to initially locate and gather meaningful data and find a way to keep it up to date.

Automated data discovery and report generation

Automated synchronization and seamless integration are built into EAM tools. Low-code integration capabilities allow them to integrate seamlessly into the modern IT4IT ecosystem. Due to the explosive growth of SaaS applications and vendors, it is not at all surprising that enterprises, and specifically their IT departments, rely on automated Software-as-a-Service (SaaS) discovery to assure full visibility of all applications. To optimize usage, keep proper entitlements, eliminate waste, and control cloud costs, this transparency is essential.

Additionally, many EAM vendors offer a marketplace where technology partners and users can exchange custom-made reports. EAM tools provide three distinct advantages in terms of automation and integration, as follows:

• API integrations that are low-code and seamlessly integrated into the IT4IT ecosystem
• Discovering SaaS, Platform-as-a-Service (PaaS), and Infrastructure-as-a-Service (IaaS) automatically
• Through online ecosystems, EAM enables automatic reports and diagrams

Integrated platform for corporate IT and product IT

A modern EAM tool is built with complementary links to other products so that it functions as an integrated platform and helps increase visibility in a dynamic work environment. As a result, EAM tools do not rely on legacy EA systems but are compatible with SaaS and value stream management solutions; they meet the needs of both corporate IT and product IT through their convergence.

EAM tools can be viewed differently within each tool to help organizations predict, plan, and execute transformation initiatives that give companies a competitive edge. The following are three final traits of an EAM tool:

• An understanding of the present state of the IT architecture and the capacity for road mapping the desired future state
• Collaboration across functional lines and repurposing IT assets
• Flexibility to keep up with new technologies and maintain control

Recommended steps for adopting an Enterprise Architect Management tool

It takes various steps to ensure successful integration and maximum benefit for EA tools and EAM tools in general. Here, we have outlined five steps that you and your team should follow before, during, and after the adoption of EA:

1. Understand the benefits of EAM tools: Aside from reducing your cloud spending and potential security risks for sensitive data, EAM tools can help find and eliminate unmanaged IT applications. You can find the right solution to fit your EA strategy once you understand the benefits modern EAM tools have to offer.
2. Choose an EAM tool based on your EA program: You need to ensure that the EAM tool you opt for helps you achieve your IT and business objectives. An application portfolio management program, technology risk management program, or a business transformation program could be a part of these efforts.
3. Assess the needs of stakeholders: You should evaluate how EA can bridge knowledge gaps between stakeholders since you do not want to create another IT silo. The tool is intended to improve workflows and foster cross-departmental collaboration. Access to data and independent analysis should be available to stakeholders. In addition, quality assurance mechanisms will make the data more accurate.
4. Review the data model of prospective EAM tools: You should examine the data models of your prospective EAM tools. Adapting it to fit your current terminology and attributes and assigning authorization roles should be straightforward.
5. Measure the onboarding process against goals: After selecting an EAM solution that meets your current as well as foreseeable needs, onboarding can begin. To make progress, set goals and measure your progress as you go.

Moreover, you can use these tools to measure your onboarding success using the desired method and keep track of the progress through data mapping, imports, workspace reviews, and KPIs.

Initiating and evolving an EA practice in organizations

To manage the complexity of constant change and to align organizations toward a single goal, EA is widely applied as a planning and governance technique.

EA for the enterprise, not just the architects

When it comes to convincing business leaders that EA is valuable, there is no big secret. Demonstrate how stakeholder decisions are impacted by greater availability and quality of data. Think of your stakeholders’ questions as you plan your EA capabilities.

Start with real business problems

Traditional EA has a reputation for being too expensive and technical, causing widespread perceptions that it hinders business growth. Business challenges must be addressed by your EA initiatives to succeed. We must consider how we frame the EA’s value in terms of business performance.

Build decisions on data, not opinion

In addition to traditional, complex tools that only a few can understand, EA still depends on traditional tools that only a few can interpret. Ensure that your data is accurate, then prioritize which metrics are most important, and develop data visualizations that can aid your stakeholders in understanding it.

Governance is good, collaboration is better

Collaboration and alignment between stakeholders are encouraged by open data. Retrospective governance can also be reduced due to open data. To achieve our EA strategic goals, we must address the question of stakeholder engagement.

Turn data into insight into action

Data insights play a major role, but action is most significant. You can make sense of disparate information by constructing metrics based on EA data. Smart business decisions can be made as a result. To move forward, address this question of whether or not a digital twin of your organization using current tools can be created or other options need to be considered.

The future is a work in progress

It is impossible to predict the future. Consequently, your EA functionality must assist in rapidly and accurately adopting the strategy within your business. Here, automation is essential – by automating your future models, you can build many more quickly.

Here’s what you need to know: is your mindset flexible enough to encourage flexibility?

Build scalability in EA

Data estates can grow exponentially – and that’s one thing you can count on. Scalable EAs, processes, and services are essential. This is the key question you will need to answer: does your EA tool automatically scale as your estate grows?

Embrace collaboration and demonstrate value for the EA’s efforts to succeed. It is important that stakeholders from all parts of the enterprise participate in your efforts – and that they benefit from them. Inform stakeholders about the expectations they should have and how to use the data to make strategic decisions more effectively.

To achieve a goal or to deliver the desired outcome, today’s EA focuses on customizing and optimizing business capabilities. As enterprise architects, we can transform organizations to invest in the right capabilities, which can be viewed as a portfolio of business capabilities. With the advent of outcome-based architecture, organizations have become more aware of the effects of digital transformation and have created novel ways of keeping ahead of the digital curve to keep competitive. This shift from traditional to digital EA has been accomplished through the use of these novel approaches.

It seems that EA trends are also shifting in favor of creating communities of domain experts, as opposed to a designated EA team. A platform that allows multiple businesses and IT teams in an organization to collaborate, have discussions, and consider different architectural views and approaches is crucial for achieving EA. The role of EA has changed as people are becoming more agile, and governance has grown to be an increasingly significant aspect of EA. Traditionally, the EA would have only been used for project teams and solutions and would have been governed by an EA board. Because EA has become a central part of a company’s culture, a digital EA promotes collaboration through a flexible governance model.

Static documentation in the traditional form of EA deliverables was difficult to maintain and update due to its instability. Digital EA has evolved to become a live repository that can be updated and maintained over time as a central point of truth that can lead to enterprise agility. Innovation management also plays a crucial role in fostering an organization’s innovation culture through digital EA. The focus here is on changes that are disruptive or iterative. Digital EA must have a well-managed innovation process for it to become a digital change driver.

Developing digital skills

According to organizations, the development of the digital skills of employees is one of the most pressing issues of the current era. When organizations decide to implement EA, they typically just relocate their people from one area to another without understanding that not everyone can act and think like an architect. EA is social by nature, not merely an intellectual endeavor. Architectures are difficult to understand from a purely abstract perspective. Even though EA is not new and is in its nascent stage, it still brings several concepts that are difficult for stakeholders to comprehend. Toward achieving trust, the EA effort must be understood by both organizations. People will doubt the value of EA if they have become tech-savvy because their ability to deliver value is already limited.

Poor communication in traditional EA today can also lead to strong resistance to new initiatives in an organization. The EA message must be communicated clearly and concisely for all stakeholders to understand and eventually expand the discussion. To manage the artifact life cycle and relationships among all entities within an organization, organizations approaching digital EA adoption should consider investing in digital EA tools and repositories. EA through a digital EA acknowledges the impact of digital transformation and strives to maintain the organization at the forefront of the digital era. In addition to differences in technology, digital teams differ fundamentally from traditional teams in terms of culture, practices, platforms, and domains.

Summary

Business is constantly evolving, and businesses must be able to assess the impact of these changes on the IT landscape, as well as how these changes will impact their operations, customer experiences, and ability to grow. Taking a closer look at these issues can help improve the transformation process. Additionally, enterprise architects keep a streamlined and agile IT environment so that IT can run upcoming business transformation projects. In light of that, this chapter shed light on how crucial EA enablement readiness is and what steps organizations can take to facilitate it. Along the way, we also determined and provided a base that helps us understand the process and flow of establishing EA practice. Identifying owners and the workflow for each of the owners, along with roles and responsibilities, were covered in this chapter. Our primary focus remains on explaining EA modeling languages in more detail.

In the next chapter, we will review and summarize all nine chapters of this book and provide use cases as well.