Technical Architecture Perspective and Enterprise Technology Architecture Overview

Technical Architecture Perspective

Technical architecture (architecture) from an enterprise viewpoint defines reusable standards and guidelines for technology and product usage, describing how they interoperate and support other viewpoints such as business and information.

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

Initiating Enterprise Technology Architecture Development

Any EA viewpoint should start by defining a future state—identifying requirements, establishing EA principles, and creating a future‑state model. Then the current state architecture is defined, a gap analysis performed, and a migration roadmap created.

Before any modeling work begins, recognize that all models are generated from the enterprise architecture (EA) process; EA practitioners and related roles must follow the process to produce models.

Enterprise Technology Architecture Organizational Concepts

Technical Domains : Traditional technical architecture methods group components into domains based on technical or organizational similarity. Related components can be grouped; common domains include networking and databases.

Figure 1

Although technical domain models are necessary and useful, they are not sufficient on their own. Technical planning requires an overall, end‑to‑end view. Designers (architects or engineers) must clearly express models that more effectively convey the goals of application and shared service delivery. A typical result of a domain‑centric approach is the optimization of a set of individual technical components without mapping the collective optimization to application requirements. Components from each domain are needed to define a complete end‑to‑end application.

Technical Patterns : Patterns help map business requirements to technical (infrastructure) design. A design or blueprint represents something that needs to be repeated—technical patterns specifically contain the entire class or set of components required for a successful application.

Technical Services : Services are components implemented and reused as single units (including processes and personnel) but are not required by every application. They often consist of components from multiple domains, though not always. Common technical services include WAN, mainframes, analytics integration (data warehouse), and transaction integration (EAI, IEI). Technical services can also directly support application services. Other reasonable component collection models exist, including frameworks such as Java EE; include them if useful.

The article also presents a 3‑N tier transaction pattern.

The article concludes with links to community groups, social media channels, and resources for further discussion on enterprise architecture and related technologies.