Enterprise Architecture Framework

Enterprise Architecture is a discipline that provides a holistic and integrated view of an organisation’s strategy, processes, information, and technology. This enterprise approach enables the alignment of various components of the business to work cohesively towards common goals. Within the Enterprise Architecture Framework, ‘enterprise’ can be understood in two key contexts:

• The broad spectrum of the enterprise, inclusive of all people, processes, and technology
• A particular domain within the enterprise, such as a specific business unit or functional area.

In both scenarios, the architecture spans multiple of systems and encompasses numerous departments within the organisation. When the objective is to create a cohesive network that includes the extended enterprise, it involves not only the internal divisions but also external entities such as partners, suppliers, and customers.

The aim of enterprise architecture as a framework is to optimise the often-fragmented legacy of processes across the enterprise (both manual and automated) into an integrated and secure environment that is responsive to changes and supportive of the delivery of the business strategy.

This section provides a reference framework to governing bodies and top management of regulated and critical sector entities to establish ‘due diligence’ on the use of IT in their respective entities. It describes the Enterprise Architecture Framework (EAF) at two levels, viz:

• Enterprise Business Architecture Framework (EBAF).
• Enterprise Technology Architecture Framework (ETAF).

The business architecture context is about how the organisation delivers value to its stakeholders. The technology architecture frameworks are about using technology to support the business mission, goals, objectives, and functions.

Enterprise Business Architecture Framework

Overview

The Enterprise Business Architecture Framework (EBAF) presents an end-to-end methodology that strategically aligns an organisation’s goals with its operational activities. Serving as an architectural blueprint, it guides leaders in shaping the processes, systems, and data flows central to the enterprise’s functioning. By integrating various components of business—ranging from customer interactions to technological infrastructure—EBAF aims to create an environment that is both streamlined and agile, fostering a business structure that is efficient and swiftly responsive to evolving demands.

At its core, the purpose of EBAF is to provide a structured yet flexible means for articulating and implementing a business’s architecture that resonates with its strategic imperatives. This involves offering clear guidance for continuous improvement of operational processes, aligning every business move with strategic goals. Beyond merely enhancing operational effectiveness, the framework serves as a catalyst to reduce process redundancies and drive enterprise-wide efficiency, ensuring that all actions taken are deliberate and goal-oriented.

Incorporating a strong emphasis on security, EBAF also propels organisations to proactively address potential risks and integrate robust security measures into their business architecture. This security-minded approach is essential in safeguarding critical information and systems, ensuring resilience against threats, and maintaining trust with stakeholders. To reinforce business resilience and foster innovation, EBAF pursuits with compliance and governance, permitting the safe exploration of new technologies and practices within a secure architectural landscape. Effectively, EBAF not only ensures that organisations meet regulatory requirements but also establish a secure foundation for growth and transformation.

The Business Ecosystem

The business ecosystem of an entity describes its environment in terms of its functions and activities in relation to and with the participation of other entities and national bodies. The business ecosystem of an entity can also be described in terms of the use of IT in the provisioning and consumption of business services, the underlying business processes and information flows between the entity and its users, customers, partners, service providers and national bodies.

Business ecosystem of regulated and critical sector entities in Indian context is pictorially shown here.

Enterprise Technology Architecture Framework

The federated digital ecosystem of a CSE is manifested through an information infrastructure that runs the business, industrial and operational processes. Most of the currently available technical literature and knowledge focuses on differentiating the characteristics and technical architectures of IT, OT, IIoT and Information Security systems and networks. In contrast, this documentation attempts to synergise and harmonise the differentiated concepts and frameworks into a common representation that can help in better communication amongst the business, non-technical and technical stakeholders, both within and outside the organisations.

The enterprise technology architecture framework outlined in this section offers a unified reference for top and senior management of organisations and national nodal bodies. It is designed to facilitate informed decision-making on leveraging technology to achieve desired business results, establish best practices, and provide comprehensive guidance on functional, performance, operational, managerial, and security considerations. It may be noted that the word “technology” here refers specifically to IT, OT, and Information Security related technology, as well as IIoT technology used for physical access control and monitoring (e.g., smart cards, biometrics, CCTVs etc).

Concepts

Requirements for use of Technology

The enterprise technology architecture framework of organisations should address the following requirements so that IT and OT are used efficiently, effectively, safely and securely:

• Functional: Deliver the business and industrial objectives through functions, processes, operations, and services.

• Quality: Deliver the required quality of systems and software.

• Performance: Deliver required performance of the functions and processes.

• Trustworthiness: Assurance that the functionality is implemented and configured correctly and is operating as intended.

• Cybersecurity: There are no weaknesses and vulnerabilities in hardware/ firmware/ software that could be exploited by malicious actors to cause harm.

• Confidentiality: The information and data are handled as per its security classification.

• Integrity: The data and processes are trustable.

• Availability: The functions and performance are available to the users at required levels of availability. 

• Safety: Specific to OT and IIoT, the assurance that the operational processes are safe for humans and the environment.

• Privacy: Privacy of individuals and organisations is maintained, with regard to sensitive and private information.

• Supply chain: Assurance that the entire supply chain is secure and not exploitable for causing harm.

• Management: People, process, and technology governance, which oversees and assures that the above parameters are consistently achieved throughout the life cycle.

• Ecosystem: The organisation’s digital infrastructure does not cause harm to other organisations that are part of the federated digital ecosystem.

Architectural Principles

The IT, OT and IS infrastructure implementation is based upon a common set of engineering and architectural principles, namely:

• Segmentation: Zoning of assets, network, and resources (security by design, security in implementation).

• Multi-layered security: Implementing a layered security cover to achieve defence in depth.

• Reliability: Ability to assure a required level of functionality and performance in normal circumstances.

• Robustness: Ability to deliver a minimum level of functionality and performance in the face of adversity.

• Resilience: Ability to prevent the degradation of functions, performance, and trustworthiness; ability to minimise the impact of degradation (if it occurs) and ability to quickly recover from a degraded condition to the normal condition.

Patterns of a CSE’s Information Infrastructure

Almost all CSEs implement their information (IT, OT and IS) infrastructure through separate projects. Typical elements of an CSE’s information infrastructure, its operation, management, and use are described below:

• A common information infrastructure across the entity, whose elements include hardware and software (end-user devices, mail, web, and portal servers), network and security systems, and information services (email, portal, common user applications, databases etc). The in-store and in-use assets are usually managed through ERP/ ITAM/ ITOM/ CMDB platforms.

• The common information infrastructure is managed through pan-organisation IT Operations/ Service management (ITOM/ ITSM) and Information Security management systems (ISMS).

• The platforms have their own IT infrastructure, viz, devices and runtime platforms to carry out IT and IS management functions related to asset configurations, availability and performance, patches and upgrades, compliance to hardening baselines, identity and access, authentication and authorisation, systems and network management, security management, logs and audit trails (evidence management), vulnerability and compliance management, security incident and event management (SIEM), incident response management, (IR, EDR/ XDR, SOAR), analytics etc. 

• Devices, systems, platforms, networks, security, applications, and databases of critical processes are usually segregated into secure logical or physical (air-gapped) high-trust zones.

• Air-gapped high-trust zones would typically have their own management systems, while non-air-gapped high-trust zones may be managed through the pan-organisation management systems.

• Integration of the security related components of physical infrastructure, viz physical access control (biometrics and smart cards), physical surveillance (CCTV networks) and management of critical non-IT asset dependencies (BIMS, UPS, Generators etc) of data centres.

• Workforce required to operate, manage, and secure the information infrastructure.

• Users, both humans and machines, who access the information infrastructure for i) consuming services, ii) carrying out system administration and management, or iii) providing service, such as technical support or customer service.

A generic deployment is pictorially represented below. It depicts the computer resources and management/ operational platforms of an entity’s IT/ OT/ IIoT infrastructure. The terms ‘non-critical’ and ‘critical’ are only indicative of how entities classify their processes and thereby, the underlying IT/ OT/ IIoT infrastructure of the processes.

The “levels” in the diagram represent the functional aspect of the infrastructure components, as tabulated below.

Terms and Definitions

The following terms and definitions are used in this document to describe an entity’s enterprise-wide information infrastructure in a generalised manner.

• Resources: These are the physical and logical assets that are in-use by an entity or user for computing, storage, networking and other IT, OT and IS functions. It corresponds to the term “Computer Resource” in the IT Act 2000 (revised 2008).

• Data Centre premises: a generic term to describe a geographical site, which hosts the computing, storage, internal networking, and other resources that an entity uses to deliver business services and carry out its business functions and operations. Server rooms are equivalent to micro data centres.

• User premises: a generic term to describe a geographical site, which hosts the computing, storage, internal networking, and other resources that are used by users (human and machine) to connect to the data centres to access services. Users may be consumers of service, systems administrators, or providers of service. The providers of service include technical support and customer service teams etc.

• Data Centre constituents: a generic term to describe the different constituents of a typical data centre, such as the property on which the data centre is built, the data centre facility, non-IT and IT constituents within the data centre and connectivity from/to the data centre. Typically, each of the constituents are evaluated when strategic decisions are taken regarding the data centres.

• Network Infrastructure Resources: the in-use network infrastructure resources can be described on the basis of the following characteristics:

  • Communication media: copper, optical fibre (OFC), power line carrier communication (PLCC), Optical Power Ground Wire (OPGW) on power transmission lines, HF/ VHF/ UHF, microwave, and satellite links.

  - WAN communication protocols: PDH, SONET/ SDH, Metro Ethernet, xDSL, AON/PON, MPLS, IP, power sector communication protocols like IEC 60870 and 61850 series/ DNP/ Modbus/ RTU, OSGP, Low Power Wide Area (LPWA), GPRS, 4G, 5G.

  • Network topologies: point to point, point to multipoint star, mesh, or bus topology.

  • Network device functions: transmission, switching, routing, element and network management, network security etc.

• Network Provider infrastructure: a generic term to describe one or many geographical sites, which hosts the network infrastructure resources that lies outside of the data centre and user premises. The network infrastructure is owned by a network provider entity (TSP, ISP). The data centre and user premises use customer premises equipment (CPEs) to connect to the network provider infrastructure. The CPEs themselves may be customer-owned or provider-owned.

• Zone: a generic term zone is defined as a grouping of logical or physical assets that share common security requirements based on factors such as criticality and consequence. This definition has been generalised in this document to describe groups of in-use IT, OT and IS resources within data centre or user premises, the physical or logical grouping being done as per functional, operational, management or security requirements.

• Perimeter: a physical or logical boundary wall between two zones, which also has access controls (gates) for ingress into and egress out of the zones. Physical access control is relevant for premises, while logical access controls are relevant for systems and networks.  

• Conduit: a generic term conduit is defined as grouping of assets dedicated exclusively to communications and which share the same security requirements. In this document it describes the communication channels connecting the zones and also the tunnels through the perimeter that separates two zones. Examples of the latter are VPN tunnels and data diode.

Ontology of Tags for Enterprise Information Infrastructure

Governing bodies, top and senior management and the technical heads in entities are provided with a common vocabulary to represent the use of IT within the entity. The ontology for tagging an enterprise’s information infrastructure has three tag-groups, viz resource categorisation tag group, hierarchical level tag group and trust level tag group.

The ontology is technologically agnostic so that it can understood by both business and technical persons. The tags are meant to be used in architecture diagrams and presentations of business and technical management to describe the use of IT, both for their internal decision processes and for communication with external entities. The tagging enables non-technical personnel to assimilate the context and participate in decision-making.

Resource Categorisation Tags

The resource categorisation tags help the stakeholders to represent the ownership and control that an entity has over its information infrastructure elements. The following tags are in this group:

1. Resource zones - central (S) or end-user (U).
2. In-use resources purpose and use – functional (FS, FU) or governance/ management/ administration (GS, GU).
3. Connectivity zones (V).
4. Data centre ownership (SA, SB, SC, SD).
5. Connectivity ownership (VA, VB, VC, VD).
6. Connectivity purpose and use (XA, XB, XC, XD).
7. End user resource ownership (UA, UB, UC, UD).
8. End user role (NU, OU).
9. Control over human workforce (WA, WB, WC, WD).
10. Services (DC, IS, OS, TS, SS, FM).
11. Service ownership (JA, JB, JC, JD).
12. Data centre segmentation (ML1 to ML4).
13. Cloud services segmentation (YL0 to YL4)

Sample Use Case for Resource Categorization Tags

Scenario:

A CSE wants to implement a new Enterprise Architecture Framework (EAF) to streamline its IT infrastructure, operations, and governance.

Challenge:

The organisation’s resources are diverse and distributed across various departments, zones, and functions. The complexity of managing these resources often leads to inefficiencies, lack of clarity in ownership, and difficulty in governance. There is an immediate need for a system that can simplify the categorisation and understanding of these resources for all relevant stakeholders, while also supporting the implementation of the new EAF.

Solution:

To address this challenge, the organisation decides to employ a set of resource categorization tags within their EAF. These tags act as labels that allow for easy identification and categorisation of resources, helping stakeholders to better understand the purpose, ownership, governance and threat modelling of each resource within the enterprise infrastructure.

Implementation:

• Resource Zones Tags: Tags like ‘Central (S)’ for shared resources and ‘End-User (U)’ for individual user-specific resources simplify the location and accessibility of resource classification for stakeholders.

• Purpose and Use Tags: Tags such as ‘functional (FS, FU)’ for operational resources and ‘governance/management/administration (GS, GU)’ for resources related to the oversight and control efficiently distinguish between the functional aspects of resources and their governance.

• Connectivity and Ownership Tags: Tags like ‘Connectivity zones (V)’ and ‘Data centre ownership (SA, SB, SC, SD)’ offer clarity on the connective infrastructure and its proprietors, expediting responsibility allocation and incident resolution. Similarly, ‘Connectivity ownership (VA, VB, VC, VD)’ and ‘End user resource ownership (UA, UB, UC, UD)’ tags provide precise ownership details.

• Purpose Specific Tags: With the inclusion of ‘Connectivity purpose and use (XA, XB, XC, XD)’ and ‘End user role (NU, OU)’ tags, the utility function and user role associated with the resources are effortlessly communicated, ensuring right access and use.

• Workforce and Services Tags: Tags regarding ‘Control over human workforce (WA, WB, WC, WD)’ denote the degree of control and structure within the workforce, while ‘Services (DC, IS, OS, TS, SS, FM)’ and ‘Service ownership (JA, JB, JC, JD)’ deliver insights regarding the service allocation and control, amplifying the operational management.

• Segmentation Tags: Finally, tags related to ‘Data centre segmentation (ML1 to ML4)’ and ‘Cloud services segmentation (YL0 to YL4)’ offer clear distinctions within data management and cloud service levels, promoting effective and secured data governance.

Benefits:

• Clarity and Control: The tags provide clear direction on resource governance, enabling stakeholders to make informed decisions regarding the resources they oversee.

• Streamlined Infrastructure Management: The use of tags streamlines the complexity associated with managing an extensive array of resources.

• Effective Governance: With tags categorising resources based on their purpose and governance, it becomes easier to enforce policies and maintain compliance.

• Enhanced Stakeholder Communication: Tags serve as a common language simplifying communication between technical and non-technical stakeholders regarding resource management.

• Agile Resource Allocation: Tags enable agile and accurate resource allocation, matching resources to needs more effectively.

An illustrative use of resource categorisation tags is given below.

Hierarchical Level Tags

The hierarchical level tags are designed to have a common classification of the information infrastructure into well-defined hierarchical zones. Appropriate trust levels can be assigned to the zones. This will help the project design and engineering teams, procurement, and provisioning teams, IT and information security operations management teams and the service providers in better risk analysis and allocation of various resources. The following tags are in this group:

1. Central resource hierarchy of zones (HL0 to HL5).
2. Perimeter zones between hierarchical zones (PHL1 to PHL4.5).
3. Perimeter zones in data centre segments (PM1 to PM4).
4. Perimeter zones in cloud environment (PYL0 to PYL4).

Sample Use Case for Hierarchical Level Tags

Scenario:

An organisation is in the process of adopting a new Enterprise Architecture Framework (EAF) to bolster its IT and OT infrastructure’s efficiency, security, and governance. A key challenge they face in this deployment is managing the complexity and diversity of their information infrastructure, which includes various hierarchical zones, data centre segments, and cloud environments.

Challenge:

Project design and engineering teams, alongside procurement, provisioning, IT and OT operations management, and service providers, struggle with conducting effective risk analysis and resource allocation due to the intricate nature of the infrastructure layout and the varying levels of trust associated with each zone. The IT and OT teams must also be able to converge onto a common representation of their respective hierarchies.

Solution:

In addressing these challenges, the organisation opts to implement hierarchical level tags within their EAF. These tags help to classify the information infrastructure into hierarchical zones with assigned trust levels. This tagging enables the stakeholders to clearly segment the IT and OT resources, aiding in threat modelling, risk analysis and the strategic allocation of resources across zones.

Implementation:

• Central Resource Hierarchy Tags: Tags ranging from ‘Central resource hierarchy of zones (HL0 to HL5)’ clearly delineate the core infrastructure zones, establishing a graded structure of trust and access controls that escalate with each hierarchy level.

• Perimeter Zone Tags: ‘Perimeter zones between hierarchical zones (PHL1 to PHL4.5)’ tags facilitate a distinct border identification between hierarchical zones, serving as checkpoints for security assessments and transitions in trust levels.

• Data Centre and Cloud Perimeter Tags: Tags like ‘perimeter zones in data centre segments (PM1 to PM4)’ and ‘perimeter zones in cloud environment (PYL0 to PYL4)’ categorize resources within data centres and cloud segments. These tags help stakeholder teams evaluate and address specific security concerns more accurately within these venues based on the designated trust levels.

Benefits:

• Improved Risk Management: Hierarchical tags aid in identifying and managing potential risks associated with the varying zones, thus enhancing the overall security posture.

• Streamlined Resource Deployment: The tags create an organized structure that simplifies the understanding of where resources reside and their respective trust levels.

• Informed Decision-Making: Teams gain insights into infrastructure vulnerabilities and strengths, enabling them to make more strategic decisions about resource deployment and protection.

• Effective Collaboration: A common classification system assists diverse teams in synchronizing their efforts, thus facilitating collaboration, and reducing inconsistencies.

• Enhanced Security Profiles: Each resource carries a clear security profile through tagging, accommodating tailored security measures.

An illustrative use of resource categorisation tags is given below.

Trust Level Tags

The trust level tags represent the level of trust that can be assigned to a zone. This will help the project design and engineering teams, IT and information security operations management teams and the service providers to design, implement, operate and manage zoning, segmentation and zero trust architecture. The following tags are in this group:

‒         Trust level (TL0 to TL5)

Sampe Use Case for Trust Level Tags

Overview:

An organization plans to implement zero trust in its enterprise IT. Stakeholders include IT architects, security officers, network administrators, and management teams who must understand and enforce the security policies, zoning and segmentation within the organization’s operations effectively.

Challenge:

Varied levels of data sensitivity and diverse IT systems across the enterprise create a complex security landscape that requires a clear and uniform approach to managing trust and control levels. Stakeholders require a reliable method for identifying, at a glance, the security trust levels and enforcement strength for each zone to correctly implement and adhere to security policies, controls, and compliance requirements.

Solution:

Trust level tags serve as a simple and effective way to categorise and label the components of the organisation’s resource and connectivity zones based on defined security policies and the level of control the entity has or requires. These tags help stakeholders instantly recognise the importance and sensitivity of each zone, ultimately guiding their risk management and policy enforcement actions.

Implementation:

• Defining Trust Levels: Categorise and define security trust levels ranging from TL0 to TL5. Establish criteria for each level based on the level of control the entity has/ can have over the zone

• Evaluating and Tagging Resource Zones: Assess each resource zone within the organisation and determine the appropriate trust level. Apply the respective trust level tag to systems, databases, and networks accordingly.

• Evaluating and Tagging Connectivity Zones: Analyse network segments and connectivity frameworks for security enforcement capability and requirements. Assign trust level tags that match their security policy framework.

• Incorporating into EAF documentation: Update all related architecture diagrams, policies, and procedural documents with the applied trust level tags to create a standard reference across the organisation, ensuring coherence and mutual understanding among all stakeholders responsible for zero trust.

Benefits:

• Enhanced Risk Management: Trust levels guide stakeholders toward adequately securing each zone according to its criticality and the organization’s risk tolerance.

• Clear Communication: The standardized tagging system reduces complexity and eases the communication of security and compliance statuses across departments and teams.

• Streamlined Policy Enforcement: Clearly identified trust levels support consistent application of security measures and rapid adjustment to evolving threats.

• Efficient Compliance Monitoring: Tags make it easier to monitor adherence to internal and external compliance standards, enabling swift corrective measures as needed.

• Optimized Security Investments: By identifying zones with higher trust levels, the organization can prioritize security investments and focus resources where they are most impactful.

An illustrative use of trust level tags in a business ecosystem diagram is given below. The trust level tags can be similarly used in a federated digital ecosystem diagram.