An EA role is really concerned with helping a firm realise some form of competitive advantage for the enterprise. The role interfaces with the C-Level, other Architects, key solution and IT SMEs and business and financial stakeholders. EAs are involved in all aspects of a firm’s business and technology alignment. In essence the IS and IT systems must be mapped to the business strategy and requirements, including regulatory and other constraints and the EA is an important actor to facilitate this alignment. An EA should follow TOGAF or a similar framework and be TOGAF certified.
Overview of the Architect layers and Roles
The Chief, Principal or Lead Architect is responsible for running the Architecture practice composed of other Architects, who have different roles to play within the Enterprise. This team operates as a team. An Enterprise Architect has a specific role. Sometimes in firms (quite often depending on the size), the ‘Chief Architect’ and the EA are the same role and person. If there is no Business Architect for example, that might also be folded into the Chief-EA Architect role.
Architects and Focus
EAs Key Goal: An Enterprise Architect is responsible for making sure that a company’s business strategy its business goals and objectives is supported by the enterprise IS and IT systems. This involves assisting with the creation and execution of the information technology architecture roadmap, working with domain architects to design roadmaps for all domains, and determining operational gaps and developing methods for improvement.
EA Role and tasks
- Developing and implementing enterprise principles and best practices based on the current estate and a target model, against known standards (NIST etc)
- Determining the viability of architecture related to organizational changes
- Evaluating applications for compliance with both enterprise and business standards
- Educating technology personnel on best practices in areas like governance models and frameworks
- Working with Solution Architects, SMEs, Management Business Owners, Other key stakeholders as necessary to support principles (enterprise, platform, project)
- Analysing current trends in the technology architecture field and providing recommendations
Bottom Line: The EA role is first and foremost a difficult blend of the business-strategic with a technical role, not necessarily a deep technical role, but embodied by someone who really understands technology and is comfortable interfacing with the business to map IS and IT to the business strategy and requirements.
The following table from TOGAF shows the complex nature of EA work and the different stakeholders involved.
TOGAFs Enterprise Architecture Skills table
(1= background, 4 is an expert)
Again, the above misses Security which should be added as a specific role with similar rankings to that of the EA Data architect.
What the EA is not
The EA is not a Solutions Architect (see below), a programmer, not a Terraform engineer, not a Test SME, not an Oracle SME, not a NoSQL expert, not a Python scripter, not a Network engineer and not an application or platform SME. These are different roles, different jobs and require different skills. Depending on the context and firm, an EA might well know a lot about these areas and be quite skilled. An EA might well have been a Java programmer and have a passionate opinion on the management of database credential access code a JSON parameter file, but there are engineers who are responsible for that. An EA would try to ensure that security standards, including not hard coding passwords into application configuration files, are followed.
Business-Solutions-Security-Data Architecture, Roles
Domains an EA covers
Enterprise architecture can be conceptually divided into different architectural layers:
- Business Architecture (level 1 above)
- Enterprise IT Architecture (level 1 above)
- Governance Architecture (level 1 above)
- Solutions Architecture
- Security Architecture
- Data Architecture
Table summarising Architecture-areas, tasks
| Architecture | Description | Tasks | ‘Lead’ Architect |
| Business | Business strategy, vision, what, why, who, end-users requirements and general business requirements, business process flows, business inputs and outputs. Goals, objectives, markets, market strategy. | Every project should have a business architecture and requirements document, signed off by the business and stakeholders. Stakeholders include business owners, BAs, regulatory agencies, Finance, stock owners, Directors and non-Technical management. | BA given to the EA |
| Enterprise | This is the end-to-end view of IT and how it supports the business process and maps to the business process. This view includes the technology, principles and end-to-end system documentation and diagrams. It also includes or links to detailed Solution Architectures, including application, databases, networking, data and security architectures. | Role described in this document above Tasks include reviews, signoffs, repositories and material and pattern reuse and controlling and understanding what is deployed and mapping to principles and objectives. HA, DR, Security, Data protection, Costs, Governance, and other pillars and principles, built, assessed, monitored including project roadmaps, enterprise roadmaps, target operating models | EA |
| Governance | Governance is a part of both the Business and Enterprise Architecture domains and is usually a cross functional management and SME process to control IT deployments and to control Business Requirements changes or demands on IT. | Approve and assess enterprise IT and business solutions, principles, map to best practices, understand what is deployed by whom, why and what the costs and implications are of projects and of what is deployed, management of stakeholders, new requirements, changing business objectives, regulatory changes and other impacts on IT and the business | EA |
| Solutions | Manages the design of the solutions, applications, databases, infrastructure, the relationships to the core business processes of the organisation, agile teams, delivery, hand over to operations | Similar to an EA but dedicated to a specific solution on a platform, or a specific implementation across platforms. It is not enterprise wide and should not include domain disciplines such as security or data architecting (at least not as a prime). | SA |
| Security | Enterprise wide at all levels of the OSI stack, mapped to NIST, OWASP and other standards, security configuration consistency with standards, testing | Enterprise-wide, project view of Security, best practices, centralisation of security configurations, configuration drift monitoring and remediation, integration with monitoring, logging, operations | Sec Arch with EA |
| Data | Responsible for the secure management of the logical and physical data assets and data management resources, customer data and data analytics | All data flows and usage architected, documented and understood, assess for business impact and potential, secured, managed, centralised, monitored | Data Arch with EA |