Pattern: Structuring IT Organization (SITO) .1 Business Concern to Be Addressed by the Pattern

A complex organizational unit (referred to here as a “department”) with several functions is to be restructured into a set of smaller units (say three to five, referred to here as “divisions”). This pattern addresses the question of what is the best way to achieve this and, at the same time, to take into account the necessary separation of duties and the potential synergy between functions.

As this pattern was originally developed for the re-structuring a particular IT department, it was decided to express this fact in the name of the pattern, although this pattern is applicable for various areas.

9.6.2 Logic of the Pattern

The following algorithm is proposed.

1. Specify all departmental functions: F1, F2,. . . 2. Define a set of “prohibition” rules: P1, P2,. . .

Each prohibition rule justifies why two particular functions can’t be in the same division. An example of such a rule is the “separation of duties” which is a key concept relating to internal control to protect an organization from fraud and errors.

3. Define a set of “synergy” rules: S1, S2,. . .

Each synergy rule justifies why two functions should be in the same division. An example of such a rule is client coordination whereby there is a single point of contact for each client.

4. Draw a (symmetrical) matrix between all functions by assigning the prohibition and synergy rules for each relationship (see Table9.4). For cases where neither rule exists, indicate “¼” (neutral).

5. Identify clusters in the relationship matrix. For example, functions F1 and F2 form a cluster.

6. Use the clusters identified as guidelines for creating departmental divisions.

Table 9.4 Example of the

relationship matrix Function F1 F2 . . .

F1 S1 ¼

F2 P2

. . .

9.6.3 Implication of the Pattern

This pattern makes the decision logic for structuring an organizational unit explicit and thus an organizational design objectively validatable. Of course, this formal method offers only a first approximation that should be tailored to the specific enterprise (and the available level of talent) at hand.

9.6.4 Example of the Pattern

Suppose an IT department is growing and as a consequence needs to be restructured.

First, you should select all functions that will potentially be carried out by the IT department from the frameworks followed by the IT department (such as COBIT, ITIL, TOGAF, and PMBOK). For simplicity, all these functions are combined into the following groups:

• GOVERN (governance)—group leading and carrying out “administrative” coor-dination by setting and maintaining internal policies, controls, and processes;

• ARCH (architecture)—group translating a customer’s requirements into a viable plan and guiding (only “technical” coordination) others in its execution;

• SECU (security)—group defining policies concerning the confidentiality, integ-rity, and availability of information services;

• PM (project management)—group supervising the building of core services and capabilities;

• OM (operations monitoring)—group supervising the operation of core services and capabilities;

• BUILD—group developing core services and capabilities including application services, information services, and infrastructure services;

• OPER (operations)—group operating core services and capabilities, including deployment, pilotage, and service desk;

• EVAL (evaluate)—group carrying out internal control;

• INTERN (internal)—group providing supporting services for the whole department.

Second, you should define the prohibition rules, which are specific to the enterprise:

• P1: separate doing and supervising/controlling (because of the separation of duties principle);

• P2: separate architecture/design and implementation (because of the separation of duties principle and early quality assurance or “quality at entry” principle);

• P3: separate implementation and operations (because of the separation of duties principle);

• P4: separate policy definition and policy implementation (similar to legislation vs. executive power separation);

• P5: deep specialization for provision of particular services.

Third, you should define the synergy rules that are specific to the enterprise:

• S1: need for close collaboration;

• S2: architecture is guiding implementation, because an architect is a person who translates a customer’s requirements into a viable plan and guides others in its execution;

• S3: there is a close relationship between technical and administrative activities, because in the evolution of social-technical systems (including enterprises) how you do something may be more important than what you do.

Fourth, you should prepare the relationship matrix using the defined prohibition and synergy rules (see Table9.5).

Finally, you can identify the clusters, namely {GOVERN, ARCH, SECU, PM, OM}, {BUILD}, {OPER}, and {EVAL, INTERN}, and use these clusters to form the divisions.

In this example, the BUILD function was divided into three functions, specific to the needs of the organization: BUILD process-centric services, BUILD knowledge services, and BUILD infrastructure services. The EVAL and INTERN were put in the CIO front office. The final structure of the IT department was as shown in Fig.9.3.

The divisions of the IT department can be considered as a functional layer which is used by a layer of end-to-end processes of projects (see Fig.9.4).

The technical and business knowledge and experience gained in each project are preserved, enriched, and re-used through an additional layer of “competence forums.” Each forum is oriented to support “generic” capabilities, e.g., business process management (BPM), enterprise content management (ECM), and business intelligence (BI), built “on top” of specific capabilities as shown in Fig.9.5.

Table 9.5 Exemplary relationship matrix

GOVERN ARCH SECU PM OM BUILD OPER EVAL INTERN

GOVERN ¼ ¼ S1 S1 P1 P1 P1 ¼

ARCH ¼ S2 S2 P2 P1 P1 ¼

SECU ¼ ¼ P4 P4 P1 ¼

PM ¼ P1 P3 P1 ¼

OM P3 P1 P1 ¼

BUILD P3 P1 ¼

OPER P1 ¼

EVAL ¼

INTERN

9.7 Summary

This chapter has presented patterns for the execution level of the business architec-ture (see Chap.1) to address specific business model choices in a reasonable way.

These represent only a selection of possible patterns to share them, demonstrate Fig. 9.3 The final structure of the IT department

Fig. 9.4 Functions and projects in the IT department

Fig. 9.5 Functions, projects, and competence forums in the IT department

their practical value, and to promote wider efforts for discovering and formalizing further business architecture patterns (including those at “higher-level” places in the business architecture). It should be noted that, since the presented patterns have been introduced as high-level solutions for common problems, the use of these patterns in a specific enterprise may require tailoring to the specific conditions at hand.

References

Campbell A (2010) Modelling behavior. http://ingenia.wordpress.com/2010/10/19/modelling-behaviour. Accessed 21 Sept 2014

Deming WE (1986) Out of the crisis. MIT Center for Advanced Engineering Study, Cambridge, MA

Olbrich T (2009) From coffee to changing the process perspective—a short illustration of the process experience. http://www.slideshare.net/Olbrich/process-experience-the-coffee-exam ple-2103831. Accessed 21 Sept 2014

OMG (2011) Business Process Model and Notation (BPMN) v2.0 specification. Object Manage-ment Group, Needham, MA

Samarin A (2009) Improving enterprise business process management systems. Trafford Publishing, Bloomington, IN

Samarin A (2013a) Practical process patterns: Decision As A Process (DAAP). http://improving-bpm-systems.blogspot.ch/2013/10/practical-process-patterns-decision-as.html. Accessed 21 Sept 2014

Samarin A (2013b) Practical process patterns: LifeCycle As A Process (LCAAP).http://improv ing-bpm-systems.blogspot.ch/2013/11/practical-process-patterns-lifecycle-as.html. Accessed 21 Sept 2014

Samarin A (2014) Enterprise as a system of processes.http://improving-bpm-systems.blogspot.

com/2014/03/enterprise-as-system-of-processes.html. Accessed 21 Sept 2014

SEI (2009) CMMI^® for services, version 1.2. Technical report, CMU/SEI-2009-TR-001, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA

Simon D, Fischbach K, Schoder D (2014) Enterprise architecture management and its role in corporate strategic management. Inf Syst e-Bus Manage 12(1):5–42