Enterprise pattern: Structuring IT Organisation (SITO)

How to decompose an IT organisation into smaller units?

Approach

1. Collect major IT-related functions (approx. 30-50) to be carried out at an IT organisation; potential sources COBIT, ITIL, PMBOK, PRINCE2, HERMES, etc. 
2. Draw a matrix of mutual relationships between those functions or group of functions (about 10) 
3. The relationships may be like “synergy” (functions to be carried-out rather together) 
4. The relationship may be like “prohibition” (functions to be carried-out by different units because of SoD principle, good practices, etc.) 
5. Each particular relationship has to be justified 
6. Find clusters in that matrix 

Example of  the relationship matrix:

Potential functional groups

• GOVERN – administrative coordination as the whole -- set and maintain internal policies, controls and processes
• ARCHitect – technical coordination – define structural changes (of core capabilities and services) in response to business and technologies changes
•  Make SAFE (added to be conceptually complete) – define policies concerning the confidentiality, integrity and availability of information services 
• Supervise building of core services and capabilities – project management (PM) Supervise operating of core services and capabilities – operations monitoring (OM) 
• BUILD core capabilities and services: application services, information services and infrastructure services 
• OPERate core capabilities and services – integration, pilotage and service desk
• EVALuate (as an independent control) capabilities 
• INTERNal support capabilities 

Define YOUR rules for decomposition

Depending on your current needs and concerns, define two group of rules.

Prohibition rules:

• P1 Separate doing and supervising/controlling – SoD 
• P2 Separate architecture/design and implementation – SoD, specialisation and quality at entry 
• P3 Separate implementation and operation – SoD, specialisation and quality at entry 
• P4 Policy vs applying it – legislation vs executive separation 
• P5 Specialisation

Synergy rules:

• S1 Close work (e.g. there is a primary / single client for services of that function) 
• S2 Architecture role to guide (an architect is a person who translates a customer’s requirements into a viable plan and guides others in its execution) 
• S3 Synergy between technical and administrative activities (how you do something may be more important what you do)

Example of relationship matrix

 

Arrangement of functions into smaller units (divisions)

BUILD-related functions are decomposed into three (process-centric, knowledge and infrastructure) due to specialisation.

So, the structure should be as shown below.

Thanks,
AS

EA view on Enterprise Risk Management (ERM) platform

In many cases, it is impossible to find a single ERM product which spans all business areas to be covers by ERM. So, it requires building an internal ERM platform on top of which different ERM-related applications will be built (following the PEAS enterprise pattern – see http://improving-bpm-systems.blogspot.com/2011/04/enterprise-patterns-peas.html ).

Business architecture view

Risk must be carefully monitored (through data collection), evaluated and acted upon. This means (see also the illustration below):

1. Enterprise business functions should be enriched to generate the risk-related data.
2. Those risk-related data need to be collected at the enterprise data warehouse together with other business data.
3. Some business processes need to be updated to embed risk-related activities.
4. A set of risk-related rules, logic and risk-related knowledge should be able to use the risk-related and other business data to detect acceptable limits of risk as well as interdependencies and correlations between different risks.
5. Some business processes for risk mitigation maybe automatically activated.
6. A lot of risk-related indicators, alerts should be available in the form of dashboards and reports available for different staff members.
7. Staff members should be able to initiate business processes based on the observed risk-related information.

Business-generic capabilities involved

The following business-generic capabilities are involved in the ERM platform:

• Management by processes
• Efficient data gathering channels
• Single version of truth for data
• Ingesting (into the data warehouse) of external information
• Efficient dissemination channels
• Effortless collaboration within groups / communities of practices
• Formalized business logic

Supremacy of management by processes

Managing any work by processes is the key business capability with allows to address the risk-related issues in a proactive manner. The risk is strongly related to how the business processes are carried out. By understanding a process (i.e. through being able to simulate it) the business may predict how the risk is changing during the execution of that process. The explicit description of processes permits to add a few “check-points” within any process to examine its risk-related “health”.

Business processes act as a skeleton to which the enterprise adds risk management (as shown on the picture below) – each usual activity is enriched by risk-related monitoring and evaluation.

The risk evaluation may initiate some risk mitigation processes. The risk evaluation may be as complex as necessary, and it may include simulations (e.g. value at risk and stress testing), and the conduct of statistical and scenario analysis.

IT-generic capabilities involved

The following IT-generic capabilities are involved into the ERM platform:

• Enterprise resource planning platform
• Data analytic
• Business process management platform
• Business intelligence platform
• Business rules management platform
• Document management platform
• Corporate portal

Thanks,
AS