A Note on This Article

This article was originally written in 2011, at a time when Enterprise Architecture frameworks were proliferating and organizations were struggling to make sense of them. The five-aspect model described here remains the foundation of our ITA&S-F Framework today. Technology references have been updated where appropriate to reflect current standards.

What is Enterprise Architecture?

Despite decades of frameworks, methodologies, and industry debate, Enterprise Architecture remains one of the most misunderstood disciplines in IT. Frameworks such as TOGAF, IAF, NGOSS, FEAF, TEAF, Zachman, MDA, C4ISR, and many others have each attempted to define it — and at the same time, specialized disciplines such as BI, SOA, ITIL, BPM, SOX, and COBIT have each staked their own territory. The question is whether all of these can be brought under a single coherent framework so that all people and initiatives are aligned. They can.

The Five Architectural Aspects

When examining most EA frameworks, a common set of architectural aspects emerges. Some frameworks cover more than others, but there is a meaningful level of alignment across them. The confusion arises not from the frameworks themselves but from the difficulty of being both a specialist and a generalist simultaneously — and from the tendency of each discipline to define its own universe.

Setting aside framework debates for a moment, the five core architectural aspects are:

  • Business Process — describes what the organization does: its functions and processes. BPM, ITIL, and industry models such as eTOM all operate at this level
  • Data — what the organization stores. Data becomes information when it is processed to produce meaning — and producing information is the domain of Business Intelligence
  • Application — what organizations buy or build. Applications must be mapped to business processes to remain streamlined, governed, and under control
  • Integration — loosely coupled applications are essential to a sustainable architecture. Integration requires a framework built on SOA principles, API-first design, and increasingly, Event-Driven Architecture
  • Technology — the infrastructure on which everything runs: cloud and hybrid environments, containerization, storage, networking, and IT center optimization (originally described in terms of on-premise hardware and virtualization — updated to reflect current cloud-native and hybrid realities)

Requirements That Cut Across All Aspects

To these five aspects, four categories of requirements apply across the board:

  • Regulatory Requirements — laws and regulations that must be respected, including SOX, PIPEDA, GDPR, Law 25 (Quebec), HIPAA, and others (originally a shorter list — expanded to reflect the current regulatory landscape)
  • Security Requirements — confidentiality, access control, alignment of roles with permissions, and compliance with security principles
  • Application Requirements — what users need applications to do, captured through Use Cases or Agile artifacts
  • Business Intelligence Requirements — the metrics and indicators users need to manage business functions effectively

From Aspects and Requirements to IT Strategy

Using Architecture Principles — defined and agreed upon at the outset — together with these requirements, it becomes possible to describe a coherent IT Strategy covering all five aspects. That strategy is made of:

  • Architecture Vision
  • EA Targets and related EA Roadmaps
  • Merger & Acquisition Migration Plans
  • Implementation Governance
  • Change Management

Choosing a Framework

Our framework draws deliberately from TOGAF, FEAF, NGOSS, and IAF — each contributing something the others lack. IAF does not make Integration an explicit aspect. NGOSS does, but does not adequately cover Technology. FEAF recognizes Integration through its Service Component Reference Model and covers all aspects well, but removes Applications as an explicit category — a gap we believe matters, since organizations still acquire commercial software and must actively manage and minimize their application portfolios. IAF usefully recognizes that Governance and Security cut across all aspects, and introduces the Why / What / How / With What hierarchy — similar in spirit to Zachman.

The key point is that framework selection should be driven by pragmatic fit, not theoretical purity. For a Telecom organization, NGOSS is a natural starting point — simply ensure the Technology aspect is explicitly added to complete the five-aspect model. Any framework can be complemented with elements from others.

COBIT

One discipline not yet covered in the above is COBIT — the Control Objectives for Information and related Technology. Developed by ISACA and the IT Governance Institute, COBIT provides managers, auditors, and IT users with a set of accepted measures, indicators, processes, and best practices for maximizing the value of IT investments and establishing appropriate IT governance and control. COBIT fits naturally within the EA framework described here and can be implemented across all five aspects.

The Bridge to Today

The five-aspect model described in this article remains the foundation of the ITA&S-F Framework we use today. What has changed is the technology layer — Integration now encompasses Event-Driven Architecture and real-time data platforms alongside SOA and APIs; Technology now spans cloud-native and hybrid environments; and Regulatory Requirements have expanded dramatically with GDPR, Law 25, and AI governance frameworks on the horizon. The aspects themselves, however, are as relevant today as they were when John Zachman first introduced them — and it is worth noting that James Martin’s Information Strategy Planning methodology, developed in the same era, was equally grounded in these same fundamental aspects.