Enterprise Technology Architecture: Perspectives, Development Process, and Organizational Concepts

Technology architecture (architecture) perspective or Enterprise Technology Architecture (ETA) defines reusable standards and guidelines for technology and product usage, describing how they interoperate and support other viewpoints (business and information).

Enterprise technology architecture should define component‑level recommendations and also specify which combinations or configurations of these technology components should be repeatedly implemented as technical patterns, and which should be reused as shared infrastructure (technical services).

Starting enterprise technology architecture development: Every EA viewpoint should begin by defining the future state—identifying requirements, establishing EA principles, and creating a future state model. Then define the current state architecture, perform gap analysis, and create a migration roadmap. All modeling work originates from the EA process, and practitioners must follow the process to generate models.

Enterprise technology architecture organization concepts: Technical domains group components based on technological or organizational similarity, e.g., common domains include networking and databases. While technical domain models are necessary, they are insufficient; planning requires an end‑to‑end view. Designers must express models that effectively convey application and shared service delivery goals, avoiding optimization of isolated components without mapping to application requirements.

Technical patterns help map business requirements to technical (infrastructure) design; a pattern represents a repeatable solution—a set of components required for a class of applications.

Technical services are reusable components delivered as single units (including processes and personnel) that are not mandatory for every application. They often consist of components from multiple domains, such as WAN, mainframe, analytics integration (data warehouse), and transaction integration (EAI, IEI). Frameworks like Java EE can also be considered technical services.

An example of a 3/N‑layer transaction pattern is shown in the diagram.