Cross Functional Services 

Cross Functional Services

Cross Functional services are those that apply across silos (towers, streams or whatever other synonym may be applied). Communications technologies may be siloed for a range of reasons such as:

• traditional terminologies such as WAN, SAN, telephony, videoconferencing, fixed, desktop, printing etc,
• service capabilities and product portfolios of vendors and service providers, or
• trends - cloud, big data, virtualisation.

A taxonomy is one means to breakdown isolated silos by identifying the relationships between otherwise siloed technologies and viewing them in terms of a common purpose.

Other activities apply across technologies, and the key aspects are set out here in terms of industry-accepted frameworks. These frameworks address the key aspects of designing, implementing, operating and improving ICT services. They are largely complementary, generic and adaptable. The frameworks referenced here are not the only frameworks used for these topics, but they are commonly deployed and accepted as best practice:

1. Monitoring and Control: FCAPS. Network management functional model defined by ITU-T and ISO. It partitions the network management into five functional areas. FCAPS can be seen as the predecessor of the newer FAB (fulfillment, assurance, billing) model defined in eTOM. The eTOM (enhanced Telecom Operations Map), published by the TM Forum, is a guidebook that defines the most widely used and accepted standard for business processes in the information, communications and entertainment industries.
2. Security: SABSA. A model and a methodology for developing risk-driven enterprise information security architectures and for delivering security infrastructure solutions that support critical business initiatives.
3. Service Management: ITIL. A set of good practices for ICT service management that focuses on aligning ICT services with the needs of business. ITIL provides the umbrella for Cross Functional Services where Monitoring and Control, Security/Compliance Management and Project Management frameworks provide more practice-specific detailed inputs to the ITIL processes.
4. Project Management: PMBOK. A set of standard terminology and guidelines for project management.

Monitoring and Control

Monitoring and Control, alternatively 'Network Management' is an architecture practice in its own right, with a number of vendor tools providing a range of capabilities to manage multiple elements of a network and provide correlation engines and dashboards. In line with Enterprise Architecture principles, a system is designed, configured or chosen based in its ability to service an organisations's business requirements not rverese engineered based on the management tools available. However, where a system performs or supports business-critical functions, the ability to monitor and manage its health (availability), utilisation (capacity) and security is a key input to the system design.

One perspective, from the Burton Groups' Network Management Architecture and Platforms research is that the management capabilities needed by a network management system can be clustered into seven interrelated groups:

1. Topology, configuration, and asset management
2. Data gathering and preliminary processing
3. Incident detection and handling, including workflow management
4. Root cause analysis
5. Operations support systems (system modeling, capacity management, provisioning, accounting, statistical treatments, and reporting)
6. Data management requirements
7. Security

The FCAPS ISO Telecommunications Management Network model breaks Monitoring & Control into:

1. Fault management
2. Configuration management
3. Accounting management
4. Performance management
5. Security management

Whatever model or reference framework may be considered, the point is that the driver is the value of any system to an organisations functions, the service levels and performance measures applied should reflect the relative values of systems to the organisation and the systems should ne monitored and managed accordingly.

Security

While Security forms a component of Monitoring and Control, it is such an all-pervasive and critical aspect that needs to be considered on its own - as an element of Monitoring & Control, but as a specific discipline. Security can be considered to be comprised of:

• Security infrastructure, and
• Security management practices.

Security infrastructure typically includes components such as firewalls, RADIUS and AAA devices and proxy servers.

The components of Security Management are:

1. Security Risk Management
2. Security Architecture
3. Security Certification
4. Security Accreditation
5. Security Policy
6. Security Documentation
7. Security Compliance
8. Security Audit, and
9. Security Incident Event Management.

SABSA is a six-layer model covering all four parts of the IT lifecycle: Strategy, Design, Implementation and Management & Operations. It aligns with the cyclical models of TOGSF and ITIL. "SABSA is a model and a methodology for developing risk-driven enterprise information security architectures and for delivering security infrastructure solutions that support critical business initiatives."
"The primary characteristic of the SABSA model is that everything must be derived from an analysis of the business requirements for security, especially those in which security has an enabling function through which new business opportunities can be developed and exploited."

Service Management

A primary element of ITIL3 is Service Design. ITIL applies to the Operational environment, whereas an Enterprise Architecture Reference Model will apply to the pre-implementation environment. The TOGAF ADM and ITIL are both cyclical in their construction. ITIL also addresses Service Transition and Service Operations as core elements, which align or cover aspects of Phase F, Phase H and Requirements Management of the TOGAF ADM.

Based on the circumstances, it is probably reasonable to see ITIL Service Management as one component of architecture when considering whole-of-business scenarios. Should an organisation have adopted ITIL practices, it is also reasonable to see new architectures introduced in accordance with the ITIL framework - specifically Change Management as the means to manage an architecture change and as a key linkage to other ITIL practices.

The relationships between the two frameworks are best considered within the ICT Governance applicable to any organisation's environment and within an intergated approach to Cross Functional Services.

Why ITIL? ITIL is the default Service Management framework for ICT. Other frameworks, such as those listed, are built on ITIL, map to ITIL or are very similar in their structure:

• IBM Tivoli Unified Process (ITUP) - prescriptive service management guidance fully aligned with the ITIL V3 framework.
• Microsoft Operations Framework (MOF) organises activities and processes into service management functions which are grouped together in phases that mirror the IT service lifecycle
• Enhanced Telecom Operations Map (eTOM). The TM Forum Business Process Framework (commonly known as eTOM) describes all the enterprise processes required by a service provider. The eTOM has been incorporated into ITU-T Recommendation M.3050 and has been approved and published by ITU-T as a new international standard.
  Release 8.0 of the eTOM Framework embeds ITIL processes in eTOM.
• ISO 20000, originally developed to reflect best practice guidance contained within the ITIL framework, although it equally supports other IT Service Management frameworks and approaches including Microsoft Operations Framework and components of ISACA's COBIT framework.
• COBIT (Control Objectives for Information and related Technology) is an IT governance framework and supporting toolset that allows managers to bridge the gap between control requirements, technical issues and business risks. COBIT can be used at the highest level, providing an overall governance and control framework that maps to the specific practices and standards such as in ITIL.

Project Management

Enterprise Architecture and Project Management

Project Management like Enterprise Architecture and like the other Cross Functional Services, is a specific practice, with its own specialist practitioners, skills, processes and reference models and frameworks. How they are applied and how they relate to each other will be shaped by circumstances and context. However they all should be oriented to common business objectives and strategies and oversighted within the same ICT governance arrangements.

Project Management may in some cases oversight the application of Enterprise Architecture within a wider project. In other cases, Project Management may be applied to implement a new architecture. Whatever the circumstances, the Enterprise Architect and the Project / Program Manager need an appreciation of the respective accountabilities and responsibilities and, ideally, an appreciation of the respective disciplines.

A project, by definition, addresses a finite timeframe. It has a specific outcome to achieve, at which time it is closed and the project manager moves on. Some may say that the same applies to an Enterprise Architecture. Some others will argue that is nonsense, the only constant in ICT is change and no architecture will withstand the test of time for more than a few years at most. Those people are correct. So, for the Enterprise Architect, Project Management is mostly something to be called upon to implement a new architecture.

Project Management fits into the time dimension of an architecture - the Transitional State that sits between the legacy or Baseline architecture and the Target State of the new architecture. It is also a consideration, albeit less defined, where a Future State or technology roadmap has been devised. It is an Enterprise Architect's role to understand the dependencies and implications for the introduction of a new architecture and ensure that these are translated into a project plan.

There are 2 well known Project Management frameworks - PRINCE2 and PMBOK. While PMBOK is referenced here, PRINCE2 is equally useful and widely adopted. (It is worthwhile noting that PRINCE2 and ITIL have the same origins in the UK's Department of Commerce).