A Note on This Article

This article was originally written around 2005–2006, when project success rates and EA leadership responsibilities were being formally studied and debated. The statistics cited reflect research from that period. The core arguments, however, have only grown stronger — if anything, the complexity of modern IT environments has made Enterprise Architecture leadership more critical, not less. Technology references have been updated where appropriate to reflect current standards; original references are noted where relevant for historical context.

Responsibilities of the Enterprise Architecture Lead

IT project success — defined as on time, on budget, and delivering the agreed functionality — was measured at just 34% in 2005. That figure does not account for adherence to architecture standards, which would push it lower still. Success rates decline sharply as project size increases: above $3 million, success rates fall into the low 20s. These numbers explain why an Enterprise Architecture Center of Excellence (CoE) is established more frequently than other CoEs — including Project Management, Process Standardization, and BI Competency Centers (BICC).

According to the CIO Council, approximately 80% of Enterprise Architecture Leaders report directly to the CIO. The responsibilities of a Director or VP of Architecture are substantial and span strategy, standards, governance, and business alignment.

1. Define the EA Foundation

Establish Architecture Principles, adopt an Architecture Framework, and define an Enterprise Architecture Mission Statement with SMART objectives — Specific, Measurable, Attainable, Realistic, and Timely.

2. Define an Enterprise-Wide Architecture Vision

The vision must be adopted and shared across Business Units and Shared Services. It should address the reduction of IT Total Cost of Ownership through:

  • Reduction and optimization of the number of applications and databases
  • Elimination of silo datamarts
  • Reduction and optimization of IT infrastructure
  • Elimination of tightly coupled applications
  • Standardization on tools and technologies
  • Reduction of the number of IT suppliers — enabling better volume-based discount agreements
  • Adoption of MDM, BPM, modern integration patterns, and other relevant approaches (originally ESB and CIM — now increasingly addressed through Event-Driven Architecture and canonical data models)
  • Process standardization
  • Optimization of IT staffing — eliminating the need for specialists in overlapping but redundant technologies
  • Better alignment with and support of business requirements

3. Define IT Architecture Standards

Standards should cover modeling approaches, metadata management, cloud and containerization platforms (originally J2EE / .NET — updated to reflect current cloud-native, API-first, and container-based standards), DBMS, development environments, BPM tools, BI and analytics tools, and hardware platforms including storage, servers, networks, and configuration management.

4. Define Roadmaps and Migration Plans

Roadmaps translate the Architecture Vision into an actionable sequence of projects, typically over a three-year horizon. Key requirements:

  • Roadmaps must be adopted and shared across Business Units
  • Projects in the first year must be included in the corporate and BU budget
  • Target Architecture must cover all architecture dimensions — processes, data, applications, integration, and technology — including regulatory and security requirements
  • At the end of the day, the business and IT want to know which applications to:
    • Decommission
    • Acquire
    • Invest in and extend

5. Define an Architecture Governance Process

Governance ensures that all architects — Solution, Data, Integration, API and Event, Java, Technology, Business Process, and BI — remain aligned with the Architecture Vision, roadmaps, and adopted standards. (Originally this list included SOA Architect; this role has largely evolved into API and Event-Driven Architecture ownership.) Governance should also align with other business improvement practices such as Six Sigma.

6. Manage and Develop the Architecture Team

Actively manage the skills, growth, and productivity of the architecture practice. An EA group that does not continuously develop its capabilities will quickly fall behind the pace of business and technology change.

7. Report on EA Business Value

Regularly report to Business Units on the business value delivered by the EA group — in terms of cost reduction, risk mitigation, delivery speed, and strategic alignment. An EA practice that cannot demonstrate its value will not retain its mandate.

The Bridge to Today

The responsibilities described here remain largely unchanged — but the context has shifted dramatically. Cloud-native architectures, real-time data platforms, AI integration, and Event-Driven Architecture have expanded the scope of what EA must govern. The EA Leader of today must understand not only application portfolios and integration patterns, but also data governance, AI use cases, and the event fabric that connects modern enterprises in real time. This is precisely the integrated view that the ITA&S-F Framework and our current platform suite are designed to support.