The architects of the company must be effective.

The acronym EA in the context of enterprise architecture can mean several things:

Enterprise Architecture (EA) Enterprise architecture, the practice of designing, planning, and managing the overall structure and operation of an organization, including aligning technologies, processes, and people with the organization’s business goals and strategy.
Enterprise Architect (EA) — an architect of the enterprise, a specialist engaged in the development and implementation of the enterprise architecture, responsible for the analysis, design, implementation and support of IT systems and infrastructure in accordance with the business needs of the organization.
Enterprise Architecture Framework (EAF) An enterprise architecture framework, a set of guidelines, methods and templates for developing and maintaining an enterprise architecture, examples include TOGAF (The Open Group Architecture Framework), Zachman Framework, and FEAF (Federal Enterprise Architecture Framework).

Depending on the context, the acronym EA may refer to one of these concepts or a combination of them.

IT and business leaders expect enterprise architecture (EA) to help achieve success.

EA appeared to solve two problems:

Systemic complexity. Organizations spend a lot of money building IT systems.
Poor business coherence. It’s been a challenge for organizations to make IT systems fit their business needs, and these problems are still relevant today, so if a company wants to solve them, it needs EA.

EA helps move to an enterprise-wide future state architecture. Even if the stakeholder group (their concerns, perspectives, and views) is specific to the business direction or geographic area, EA may be required if the impact is significant or transformational.

* An enterprise architecture roadmap is a document that describes the objectives, key milestones, target dates and project managers, which is created at the beginning of a project and serves as a basis for developing detailed plans and schedules. Roadmaps are especially useful in projects with multiple workgroups, as they allow all participants to see the overall picture of the project and monitor its implementation.

EA is quick to find the optimal solution at a given point in time, balancing trade-offs. EA isn’t looking for the best solution for months. But EA can use roadmaps to gradually and iteratively record progress toward the «best» solution.

If the problem area covers organizational structure, business processes, data/information, product supplier roadmap, project portfolio management, IT management (cost, complexity, technical debt, risk management), etc., then EA is the best way to implement these solutions.

EA does not always offer new or revolutionary solutions. EA can be applied even to initiatives to leverage existing investments with optimization, improvement of service or decommissioning of the system. EA also aims to reduce complexity and meet the needs of businesses throughout the Planning-Build-Operation IT value chain.

Once an EA-friendly environment has been created, enterprise architects primarily manage the technology strategy and its implementation in relation to business objectives.

This means that they provide a roadmap and make sure that the solutions are in line with its recommendations, and the roadmap is a roadmap for moving from the current state to the future, and it has four main sections:

the current state of the Solution-Business-Opportunities matrix;
a future state matrix that includes key use cases, scenarios, requirements of different stakeholder groups;
gaps between current and future states;
Reference architectures that provide technical guidance to address gaps in the transition from the current state to the future.

These sections help the architects of the enterprise manage the transition from the current state to the future, but for the developers of these four sections, architecture, design and coding have certain boundaries, and aspects such as security, data flow, integration details are specific to each project, and they must be taken into account in the design phase based on reference architectures.

Before starting an enterprise architecture (EA) project, make sure you consider the following points.

If stakeholders (business and IT) do not have a clear idea of where they want to go, then EA may be useless. Enterprise architects can help define goals, but EA itself does not create a vision, it only provides it.

EA is not just an IT project; it requires close collaboration between business and IT to successfully implement solutions and systems, so enterprise architects need access to top management in both IT and business, and if there are multiple levels of hierarchy between architects and management, then EA’s effectiveness is reduced by bureaucracy and inefficiency.

If the risks of adopting new technologies are low, or if the solution is easy to implement, then EA may not be necessary. It’s like using a sledgehammer to crack a nut.

EA strives for the future state gradually and in advance, and just analyzing the current state without the intention of moving to the future is a waste of time.

EA responds effectively to business needs through communication. Frameworks such as TOGAF, FEAF, and Zachman help align business and IT interests. If these frameworks are not used to inform the future state, then they are of little use.

Today, it is no longer enough for companies to simply want to implement EA, it has become a necessity for those who want to simplify the system and improve business service. Modern tools and platforms simplify programming, but also add complexity in the early stages of the software development lifecycle, requiring a robust architecture for important use cases, scenarios and requirements.

The need for EA does not depend on the size of the company, but on how the company plans to use technology for its needs. An effective EA can be a great tool for integrating strategic planning, project management and services. However, if EA does not work properly, it can lead to a drain on the company’s resources.

EA is not an end in itself, but a means to an end, and ultimately the result should be reliable, workable software developed by IT that leverages the quality of business data.