How to Define and Establish an SAP Integration Competency Center (ICC) · 2017-02-23 · How to...

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2011 SAP AG 1

How to Define and Establish an

SAP Integration Competency

Center (ICC)

Applies to:

SAP Customers who consider standardizing their technical integration efforts and reducing the TCO for integration by establishing an Integration Competency Center (ICC).

Summary

Integration Competency Centers (ICC) are an organizational unit within an enterprise, aiming at the governance in the integration area. This article shows up a methodology for establishing an ICC in an SAP environment.

Author: Florian Koeller, Fabian Schreiber

Company: SAP

Created on: 23 December 2011

Author Bio

Florian Koeller, SAP Consulting - Florian is a Senior Integration Architect, focusing on process integration and SAP NetWeaver Process Integration. He is a member of the PI Community and active in the SAP integration area for many years.

Fabian Schreiber, SAP Consulting - Fabian is a Senior Consultant with expertise in project management and PI/SOA Governance. During his career he has worked across different branches, including high-tech, automotive, retail and banking. He is a member of the PI Governance focus group.

How to Define and Establish an SAP Integration Competency Center (ICC)


© 2011 SAP AG 2

Table of Contents

Introduction and Motivation................................................................................................................................. 3

The Starting Point ........................................................................................................................................... 3

Integration Challenges .................................................................................................................................... 3

The solution: an Integration Competency Center (ICC) .................................................................................. 3

How to get there .............................................................................................................................................. 4

Scope of this document................................................................................................................................... 4

ICC Strategy ....................................................................................................................................................... 5

Strategy ........................................................................................................................................................... 5

ICC Model selection ........................................................................................................................................ 5

Best Practices ICC ....................................................................................................................................................... 6

Standard Services ICC ................................................................................................................................................ 7

Shared Services ICC ................................................................................................................................................... 8

Central Services ICC ................................................................................................................................................... 8

ICC Service Portfolio .......................................................................................................................................... 9

People (Organization, Skills and Culture) ......................................................................................................... 10

Organizational structure ................................................................................................................................ 10

Roles ............................................................................................................................................................ 10

Best Practices ICC roles ............................................................................................................................................ 11

Standard Services ICC roles ...................................................................................................................................... 11

Shared Services ICC roles ......................................................................................................................................... 13

Central Services ICC roles ......................................................................................................................................... 14

Processes and Methodology ............................................................................................................................ 16

Implementation and Upgrades ...................................................................................................................... 16

Operations and Optimization ........................................................................................................................ 17

Technology ....................................................................................................................................................... 18

Basic integration definitions .......................................................................................................................... 18

SAP Integration Products .............................................................................................................................. 19

Summary........................................................................................................................................................... 20

Related Content ................................................................................................................................................ 21

Copyright........................................................................................................................................................... 22



© 2011 SAP AG 3

Introduction and Motivation

The Starting Point

Today’s enterprises run a vast number of different business applications (e. g. SAP Business Suite applications), supporting all kinds of processes relevant for the enterprise: finance, controlling, human resources, etc. Many of these end to end processes are supported and automated by different business applications. This raises the need to communicate between applications and perform process integration.

According to the Integration Consortium integration is “the process of integrating multiple applications that were separately developed, may use incompatible technology, and remain independently managed.” Integration comes in many forms and types; there are numerous integration tools and approaches; it can be achieved in many different ways.

In this document, we focus on the following integration approaches:

Enterprise Application Integration (EAI): Process- or Message-Level exchange of data between heterogeneous business applications.

Extract Transform Load (ETL): data-oriented exchange of data between applications on database level.

Service-Oriented Architecture (SOA): flexible set of design principles for integration, based on consuming and providing services.

Integration Challenges

Today’s enterprises are highly-complex, distributed over regions, business units and functions; they constantly change due to mergers and acquisitions. This makes enterprise-wide integration governance a challenge and often leads to:

Development and operation in silos

o No central understanding of “the big picture” and no interaction between teams.

o Each integration development/operations team follows different standards.

Heterogeneous integration technologies, guidelines etc. through mergers and acquisitions

High barrier of adapting to different technologies

An approach to overcome these problems is the usage of integration platforms. The main SAP integration platforms are SAP NetWeaver Process Integration and SAP BusinessObjects Data Services.

However, the usage of an integration platform is only one step in keeping integration manageable and per se does not solve the problem of e. g. silo developments, especially in large and distributed environments.

The solution: an Integration Competency Center (ICC)

An ICC is an organizational unit for governing your application integration. Sometimes an ICC is also referred to as an Integration Center of Expertise (Integration CoE). We will use the term ICC in this document. An ICC can be a stand-alone department with dozens of employees or, if required, a virtual community whose members continue to work in different parts of the organization.

The main objectives of an SAP-based ICC are:

Reduction of costs for integration. According to Gartner an ICC can save an average of 30% in development time and cost and 20% in maintenance. Furthermore, reuse can be increased significantly.

Company-wide distribution and use of SAP Best Practices.

Creation of an adaptive enterprise. As mentioned above, today’s enterprises are constantly in motion and have to be able to rapidly react to changes. Consequently, the integration landscape has never reached a final state. The goal is to enable the enterprise for constant changes in their integration landscape.



© 2011 SAP AG 4

An ICC can have different maturity levels. Its objectives can range from pure documentation purposes up to be the single implementation and operations entity in the enterprise.

Gartner recommends that each IT department dealing with integration should have an ICC regardless of its size. Consequently, an ICC can be as small as one full-time equivalent (FTE), covering all roles described in this document. In larger environments, it can consist of numerous FTEs and have a deeper structure.

How to get there

There are five steps in evolving to an ICC:

1. Definition of the ICC strategy. It is important that the goals of the ICC are aligned with the overall business and IT goals of the enterprise. Select the ICC model that fits your strategy. We will discuss this topic in section “ICC Strategy”.

2. Definition of the ICC Service Portfolio. Depending on the ICC model, the tasks and activities within the service portfolio vary. The ICC portfolio definition as well as an example can be found in the section “ICC Service Portfolio”.

Selection of the right people to form your ICC. We will describe the required organization and skills as well as well as role recommendations in section “



© 2011 SAP AG 5

People (Organization, Skills and Culture)ICC Service Portfolio

The ICC Service portfolio defines the set of activities which is delivered by the ICC organization. Since every ICC model covers different aspects of the Application Management Lifecycle, there is no standard portfolio which can be applied to all ICCs.

An example for the Service Portfolio can be found in Figure 2.

Figure 2: Example for an ICC Service portfolio

We will not discuss this topic further in this document. Service Portfolio Management in itself must be accomplished by the IT department of every enterprise. The approach to this particular topic can vary significantly. Especially in large enterprises, the use of a good-practice methodology such as ITIL is vital to the success of the portfolio definition.



© 2011 SAP AG 6

3. People”.

Define your ICC’s processes and methodology or the involvement of the ICC in your existing processes. processes. We will describe this topic in section “



© 2011 SAP AG 7

4. Processes and Methodology”.

5. Define your desired integration technologies and how to use them. We will introduce some of the SAP products in section “Technology”.

Thorough preparation and execution of those steps is mandatory for the ICC’s success.

Scope of this document

This document shows up a way how to set up an organizational structure. Therefore, we do not discuss technical details of how to manage integration with PI, Data Services, etc. We focus on the critical success factors for setting up your ICC.

Although it is possible to adapt this approach to other data integration environments, the main target groups of this document are customers that use at least one SAP integration platform.

The following areas are not in scope of this document: Information Integration/Data Warehousing (SAP Business Warehouse), Enterprise Portal (SAP NetWeaver EP), Master Data Management (SAP NetWeaver MDM) and Master Data Governance.



© 2011 SAP AG 8

ICC Strategy

Strategy

The ICC strategy should outline key principles and goals which will guide all ICC members during their daily work. The strategy ensures that the ICC’s activities are aligned with the IT organization’s goals.

The following questions may serve as a guidance to define the ICC strategy:

How can the ICC support the company’s IT/Business strategy (e. g. “enable business continuity”)?

What is the long-term goal that the ICC should archive (e. g. “Become the central entity for all integration-related questions”)?

High level roadmap for ICC adoption

Operating model, structure and required resources/roles

Which role shall the ICC play in a rapidly changing IT environment (e. g. “innovation driver”)?

ICC Model selection

There are different ICC models, each of them representing a different level of maturity of the ICC. Selecting the model that fits the company’s vision & strategy best is the central step when planning to establish an ICC.

The selection of an ICC model can be a one-time effort as well as an evolutionary process. It is possible to pick a specific target model or to start with the simplest ICC model and evolve to one of the more advanced ones. It can be reasonable to pick a “hybrid-model” which combines different aspects of two ICC models (e. g. Standard Services and Shared Services).

A consolidated overview of all models can be found in the following table. We will take a closer look at each of the models after that.

Best Practices Standard Services Shared Services Central Services

Objective Manage and distribute knowledge

Define and Enforce standards

Optimize Resources Perform centrally governed integration

From left to right, each model extends the scope of the one before (see Figure 1). The Central Services Model is the most comprehensive model with the highest maturity level.



© 2011 SAP AG 9

Figure 1: Extent of the different models

Best Practices ICC

The Best Practices ICC model is the basic ICC model. Its main objective is to manage and distribute knowledge in the organization.

This makes it the easiest ICC Model to implement and a good first step to start within your organization.

Aspect ICC Characteristics

Focus The focus of the Best Practices ICC is to document best practices and recommendations for

procedures and standards for development (e. g. integration patterns) and operations.

The ICC is supposed to distribute this knowledge in the IT organization. Possible channels are newsletters, articles, white papers, etc. As an additional measure, “Lessons Learned” sessions for finished projects could be organized by the ICC.

People This ICC model consists of a distributed team. The members of the ICC typically work in

other departments of the organization.

We will have a closer look at the required roles for a Best Practices ICC in the section “Best Practices ICC roles”.

Processes The ICC is responsible for giving recommendations for Implementation Projects, Handover

to Production and Operations processes.

Although the ICC might give recommendations, process implementation and governance is a task of the project/department performing integration and not within responsibility of the ICC.

We will have a closer look at the ICC processes in section “

Processes”.

Technology The ICC is responsible for recommendations which and how integration platforms and technologies are to be used in the organization; however, the actual decision which one to use and how to use is up to the project/department performing integration.

Nonetheless there might be enterprise-wide architecture decision, e. g. to use PI as the general integration platform.

The technology topic will be described in more detail in section “Technology”.

Central Services

Shared Services

Standard Services

Best Practices



© 2011 SAP AG 10

Standard Services ICC

The Standard Services ICC covers all aspects of a Best Practices ICC and more.


Focus The ICC is responsible for the definition of integration standards and assurance of adherence of all integration activities to those standards. Those standards should for example cover guidelines, naming conventions and metadata standards. These standards will improve the company-wide consistency in software development and hardware.

The level of detail of these standards is an important topic to be discussed.

For this purpose, the ICC needs a dedicated platform to distribute the tools and documents to the relevant stakeholders in the various integration projects.

People In a Standard Services Model the ICC Team is still distributed, however, some of the resources spend at least a significant part of their time for the ICC. The ICC is provided an own budget; if desired, it can be an own cost center.

We will have a closer look at the required roles for a Standard Services ICC in the section “Standard Services ICC roles”.

Processes The ICC is responsible for providing certain standards for all integration related processes.

Although the project/department performing integration is responsible for definition and implementation of their specific processes, the processes must adhere to the standards of the ICC.


Processes”.

Technology The ICC is responsible for definition of which integration platforms and technologies to be used in the organization; however, development and operations of those platforms and technologies are distributed and within responsibility of the project/department performing integration.

The challenge is to assure the ICC standards are met. One possibility of achieving this could be audits of integration projects.




© 2011 SAP AG 11

Shared Services ICC

The Shared Services ICC is a major step compared to the Standard Services. It is more than just an extension of the previous models as it provides services to implementation projects, e. g. consulting or even development support.


Focus In addition to standardization, the Shared Services ICC’s focus is to optimize integration resources in the organization. For example, it can provide resources to integration projects.

People Due to its size, there are at least some resources working centrally for the ICC. They could perform ICC-related tasks, consult or even be member of integration projects, representing the ICC.

Still, some ICC roles might be staffed by shared resources with other departments.

We will have a closer look at the required roles for a Shared Services ICC in the section “Standard Services ICC roles”.

Processes See processes for Standard Services ICC. The Shared Services ICC might consult the project/department performing integration with regards to the processes; however, it is not responsible for their definition, apart from adherence to the standards.


Processes”.

Technology Analogous to the Standard Services ICC model.


Central Services ICC

The Central Services ICC is the highest maturity ICC model. Its objective is to perform centrally governed integration throughout the enterprise and can be aligned with enterprise architecture function and services. More information about Enterprise Architecture can be found under http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/90a744a3-55d9-2910-96b9-8a1513fefb1f

While being a good option in small and medium enterprise, establishing this ICC model is challenging in globally operating large enterprises.


Focus All integration within the enterprise is governed by the ICC as a central entity. The ICC has its own budget and acts as a service provider to all projects across the enterprise. Goal is that all implementation is going through the ICC.

People The ICC is a central organization with own budget, resources etc. It might be responsible

for integration projects or support other projects with integration-related consulting.

We will have a closer look at the required roles for a Central Services ICC in the section “

Central Services ICC roles”.

http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/90a744a3-55d9-2910-96b9-8a1513fefb1f



© 2011 SAP AG 12


Processes The ICC Team is centrally responsible for all integration-related processes, covering all stages from development to operations. For those processes out of scope for the ICC (e. g. an organization-wide change management process), it is still responsible for correct process alignment.


Processes”.

Technology The ICC is fully responsible for all integration platforms and integration technologies in the enterprise.


ICC Service Portfolio

The ICC Service portfolio defines the set of activities which is delivered by the ICC organization. Since every ICC model covers different aspects of the Application Management Lifecycle, there is no standard portfolio which can be applied to all ICCs.

An example for the Service Portfolio can be found in Figure 2.

Figure 2: Example for an ICC Service portfolio

We will not discuss this topic further in this document. Service Portfolio Management in itself must be accomplished by the IT department of every enterprise. The approach to this particular topic can vary significantly. Especially in large enterprises, the use of a good-practice methodology such as ITIL is vital to the success of the portfolio definition.



© 2011 SAP AG 13

People (Organization, Skills and Culture)

This section deals with the most important aspect of the ICC: selecting or building up the right people with the right skill sets and putting them into the right positions.

Organizational structure

In larger SAP environments with more than one integration tool in place, an ICC can consist of several sub-teams, e. g. one per integration tool. There is at least one central team without close assignment to an integration platform.

ICC Lead

Vendor Manager

Quality Manager

Integration Architect

Project Manager

Central Roles

PI Developer

PI System Administrator

PI Change Control Coordinator

…

PI Solution Architect

PI Roles

DS Developer

DS System Adminstrator

…

DS Solution Architect

Data Services Roles

…

…

…

…

…

…

Enterprise Architect

Figure 3: Example of an ICC team structure in an SAP environment

There can be many more influencing factors on the organizational setup of your specific ICC, e. g. the available number of ICC staff members, the geographical structure etc.

Roles

Finding and educating the right people is critical for the success of an ICC. Besides hard skills in the area of integration, soft skills are essential. If the ICC is to become a success in your enterprise, a proactive attitude will be necessary to minimize integration activities outside the ICC domain.

The roles to be established depend on the chosen ICC model. The higher the maturity level of your ICC, the more roles are required, consequently the number of resources is typically higher as well.

The roles in the following are partly integration platform-specific and partly independent. There is a column in the following tables indicating if the role is platform-specific or not. Platform-specific means that you need it for each platform in use. A PI developer, for example, has a significantly different skill set compared to a Data Services Developer. The integration tool-specific roles mentioned in the following sub-sections are valid for an SAP NetWeaver PI environment and can be used analogously for other environments. They have the prefix “PI” in the role name and correspond to the roles described in the following SCN document:

https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/2061257f-970c-2c10-3783-9821abb59991?overridelayout=true

Please keep in mind that the relationship between a role and a Full-time equivalent (FTE) is not necessarily a 1:1 relationship. In small environments, the ICC can consist of one FTE covering more or less all roles. At the other end of the spectrum, more than one FTE can have the same role. Example: in a large team, there is typically more than one PI developer.





© 2011 SAP AG 14

Some of the roles might not be applicable to your environment, for example if certain parts of the organization are outsourced.

Finally, you might decide to establish additional roles. Assuming the organization has reached a certain headcount, it might make sense to establish additional layers, e. g. team leads.

Best Practices ICC roles

As this ICC model is focused on documenting rather than governance or delivery, the necessary roles are:

Role platform-specific

Responsibility

PI Knowledge Coordinator yes Development and maintenance of patterns, templates, best-practice documents. The documents are made available throughout the enterprise.

PI Training Coordinator yes Responsible for

Coordination of SAP or internal PI trainings

Internal distribution of events, presentations etc.

Standard Services ICC roles

The members of a Standard Services ICC typically come from different teams in the enterprise. In addition to the Best Practices ICC roles, the following roles have to be established:


Responsibility

ICC Lead no The ICC lead is the manager of the ICC staff. He is also responsible for the budget.

Integration Architect no The integration architect is responsible for the high-level architecture, the evaluation of integration requirements from architectural perspective and selection of the right technology (PI, Data Services …).

He is also responsible for the alignment of the ICC’s work with the overall enterprise IT strategy. Therefore, his activities should always be embedded into the Enterprise Architecture in order to assure the ICC’s alignment and relationship to strategy, processes, data and applications.

Basically, he is responsible for the technical implementation of conceptual and logical application to application communication from solution perspective.

PI Solution Architect yes Responsible for the PI architecture and standards governance. Should have deep integration expertise.

PI Basis Architect yes Responsible for all architectural decisions in the basis / infrastructure area, e. g. deployment strategies, security concepts, etc.



© 2011 SAP AG 15


Responsibility

PI Enterprise Services Repository (ESR) Administrator

yes Responsible for capturing and maintaining metadata as well as all shared content. Mainly applicable in case your IT organization promotes certain standards (e. g. CCTS).

In PI, all metadata is stored in the Enterprise Services Repository (ESR). In case Global Data Types are used, the Metadata Administrator is also responsible for the GDT catalog.

1

In case a canonical data model / Generic Business Objects (GBOs) are used, the PI Metadata Administrator is centrally responsible for their maintenance and proper usage.

Vendor Manager no Responsible for

Selection of vendors for servers, storage and network facilities.

Vendor relationships

This role might be assigned to a non-ICC member.

PI Standards Analyst yes Responsible for

Monitoring and promoting integration content (e. g. industry standards) into or out of the enterprise.

2

Acting as the company’s official representative in the various communities (e. g. in DSAG, ASUG)

3

Security Administrator no Responsible for

Adherence to enterprise security guidelines in the area of integration. Should also have influence on these guidelines.

Observing correct implementation of these guidelines in integration tools.

1 More information about Global Data Types can be found under

https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/4037b3fc-fb52-2a10-4888-e28362af626e?overridelayout=true

2 More information about SAP Standard Integration content can be found under

http://www.sdn.sap.com/irj/sdn/nw-soa?rid=/webcontent/uuid/009ac474-f048-2a10-d994-f47fc5f74520#section2

3 More information about SAP communities can be found under

http://www.sap.com/communities/index.epx





http://www.sap.com/communities/index.epx



© 2011 SAP AG 16

Shared Services ICC roles

As the Shared Services ICC is additionally responsible for consultancy and/or delivery, the team is typically significantly bigger than a team for one of the lower ICC models. In addition to the above roles, the following roles are required:


Responsibility

PI Change Control Coordinator

yes Responsible for

Software Logistics in PI (e. g. Release Management, Version Management, …)

Changes applied to existing PI content

Encouraging or enforcing reuse of existing content where possible

PI Developer yes Responsible for

Reviewing and evaluating functional specifications

Creating technical specifications

Implementing integration solutions in SAP NetWeaver PI.

Project Manager no Responsible for all project management activities in integration projects. Mainly requires project management skills, however, a technical or integration background is more than helpful.

Quality Manager no Responsible for

Defining and Executing all aspects of quality management (Quality planning, quality assurance, quality control, quality improvement)

Test management, e. g. unit tests, system tests, support of end-to-end integration tests

Engagement Manager no Primary point of contact for the ICC. Responsible for

handling all requests

supplying estimates or quotes



© 2011 SAP AG 17

Central Services ICC roles

As the Central Services ICC additionally provides support and has full life-cycle responsibility for the integration platforms, the following roles are required:


Responsibility

PI Application Monitor yes Responsible for monitoring all messages in PI as well as root cause analysis and error handling. Close collaboration with business.

PI Basis Monitor yes Responsible for periodic monitoring of all technical PI instances, services and applications.

This role might be assigned to non-ICC members or might be obsolete at all in your environment.

PI System Administrator yes Responsible for creation and maintenance of the configuration and physical hardware for running SAP NetWeaver PI (Basis), for example

Configuring PI systems (Setup of SAP Web AS, …)

Managing the PI Systems (User Management, Logging/Tracing, …)

This role might be assigned to non-ICC members or might be obsolete at all in your environment.



© 2011 SAP AG 18

Best

Practices

Standard

Services

Shared Services Central Services

PI Knowledge

Coordinator

PI Training

Coordinator

ICC Lead

Integration Architect

PI Solution Architect

PI Basis Architect

PI Enterprise

Services Repository

(ESR) Administrator

Vendor Manager

PI Standards Analyst

Security Administrator

PI Change Control

Coordinator

PI Developer

Project Manager

Quality Manager

Engagement

Manager

PI Application Monitor

PI Basis Monitor

PI System

Administrator

Figure 4: Overview of the ICC Roles for the different models

Although not explicitly mentioned in the roles definition, it is imperative to establish a regular exchange between the ICC and the Enterprise Architecture practice to align on architectural decisions and IT strategy topics. This can be accomplished e.g. by a “dotted-line” reporting between the ICC Integration Architect and the Enterprise Architect.



© 2011 SAP AG 19

Processes and Methodology

The ICC underlies the processes of the IT organization. However, certain processes could be defined by the ICC or have to be aligned with the ICC.

We will have a look at the following process groups:

Implementation and Upgrades

Operations and Optimization

Application

Manage-

ment

Figure 5: The Application Management Lifecycle

The tasks and activities of the process groups will not be discussed further in this document; they can be looked up in the service market place (see section “



© 2011 SAP AG 20

Related Content”). However, we will have a look at how the involvement of the ICC could look like in each phase. No matter how deep the involvement of the ICC might be (it might for example cover an information flow only), a close collaboration between project teams and the ICC is vital for the success of both the project and the ICC.

The processes in this document are based on ASAP (for Implementation and Upgrades) and RunSAP (for Operations and Optimization). You might use a different methodology in your environment.

Implementation and Upgrades

The involvement in the different project phases can be found in the following table.

Project Phase ICC involvement

Project Preparation If the ICC is active part of the project, it is part of all activities in this phase anyway.

Even if the ICC is not involved in the project, it should be informed about the project and its preliminary scope as early as possible.

Furthermore, project procedures and ICC procedures should be aligned. For example, the ICC (Shared Services or higher) might have an internal approval process for developments which has to be considered within the project.

Blueprint If the ICC is performing the implementation for the project, it is part of all Blueprint activities.

Even if the ICC is not involved in the implementation, it should still be consulted by the project in order to assure that the project is aligned with the ICC standards, e. g. for developments.

Realization If the ICC is fully or partly performing the implementation in the project, they are automatically involved in the project tasks and activities of that phase.

Even if the ICC is not involved in the implementation, it still might have to assure that all developments are performed according to the ICC guidelines (Standard Services), for example through audits.

Final Preparation Depending on the model, the involvement of the ICC in this phase could be:

Support or execute the transition of the project developments into a productive environment

Provide or support in creating all necessary documents that will aid the team (Checklists, cutover plan, etc.). Over time the ICC will have a pretty large base of documents.

Prevent impact on productive integration scenarios.

Go-Live Support See section “Operations and Optimization”.

Figure 6 shows you a possible RACI matrix for the different phases. The matrix has to be adjusted to fit your environment.



© 2011 SAP AG 21

Best

Practices

Standard

Services

Shared

Services

Central

Services

Project Preparation - I C or R R, A

Blueprint - C or I C or R R, A

Realization - C or I C or R R, A

Final Preparation - C or I C or R R, A

Go-Live Support - C or I C or R R, A

R = ICC is Responsible

C = ICC is Consulted

I = ICC is Informed

A = ICC is Accountable

Figure 6: High-Level RACI matrix for implementation and upgrades

Operations and Optimization

The different processes in operations and optimization phase are described in the following table.

The actual execution of Operations and Optimization is only relevant for Central Services ICCs. However, in case of Best Practices, Standard Services, or Shared Services ICC models, the ICC can of course consult the operations team(s) when it comes to defining the processes.

Process Tasks and Activities

End-User Support The End-User Support of an ICC is integrated into the IT Support Organization. Therefore, it can make use of all standard tools and procedures for the rest of the IT organization; it might make sense that the ICC has its own end-user support.

Change Management Operations

The Change Management Operations process of an ICC is embedded into the IT Support Organization. Therefore, typically the same tools and procedures as in the rest of the IT organization apply.

SAP Application Management

The performance of SAP Application Management in the area of integration is one of the tasks of a Central Services ICC.

The ICC has to collaborate closely with the business, being responsible for critical parts of the business processes.

Business Process Operations

The ICC has full responsibility for business process operations, of course focused on the integration area.

The alignment with the business has to be defined as part of business process operations.

SAP Technical Operations The Central Services ICC takes full ownership of SAP Technical Operations (unless these processes are outsourced). Other ICC models might consult.

Technical Infrastructure Management

The Central Services ICC takes full ownership of Technical Infrastructure Management. Other ICC models might consult.

Figure 7 shows a possible RACI matrix for the different operations processes. Again, the matrix has to be adjusted to your environment.



© 2011 SAP AG 22

Best

Practices

Standard

Services

Shared

Services

Central

Services

End-User-Support - C C or R R, A

Change Management

Operations- C C or R R, A

SAP Application

Management- C C or R R, A

Business Process


SAP Technical


Technical Infrastructure

Management- C C or R R, A

R = ICC is Responsible

C = ICC is Consulted

I = ICC is Informed

A = ICC is Accountable

Figure 7: High-level RACI matrix for operations and optimization

Technology

Basic integration definitions

From an architectural perspective, Integration is performed between business applications. Each business application can roughly be divided into three architectural levels:

On the User Interaction level, a user is able to view or process the data within a user interface. A typical product used for this layer is a portal, but also mobile solutions etc. User interaction will not be discussed further in this document.

On the Business Logic level, the way how the data is stored, accessed or processed is described. In an SAP landscape, accesses from or to the outside world typically take place through this layer, not directly to the data layer.

The Data level describes the actual storage of the data in the database. Data Services is able to access the databases of an SAP system natively. However, as this method bypasses all business logic built on top and it is not advisable to access the database layer directly in many cases, Data Services typically uses the Business Logic level as well to access data (due to complexity reasons this is not shown in Figure 8).



© 2011 SAP AG 23

Business Application 1

Services (SOA)

Connectivity (EAI)

SAP NetWeaver PI

Business Application 2

User interaction

Business Logic

Data ServicesData

Service Integration

Message Integration / Business Process Integration

Data Integration

Figure 8: The Architectural Levels from integration perspective

For the integration between business applications, we differentiate four relevant types of integration for an SAP ICC. In Figure 8, they are outlined as arrows.

Sometimes there is no clear separation between the different types of integration. Given a certain requirement, it is important to decide for a new integration requirement which type of integration and consequently technology is adequate.

SAP Integration Products

The SAP product portfolio offers the following solutions for systematically managing integration.

Integration Type Core functionality of….

Service Integration SAP NetWeaver Process Integration (PI)

Message Integration SAP NetWeaver PI

Business Process Integration

Integration-centric: SAP NetWeaver PI

User-centric: SAP NetWeaver Business Process Management (BPM)

Data Integration SAP BusinessObjects Data Services

As mentioned above, this assignment is flexible in practice. For example, BusinessObjects Data Services is able to perform Service Integration as well; however, it is not its core functionality.

New innovative extensions of the SAP product portfolio such as Mobility (allowing you to mobilize your enterprise to mobile devices like iPhones/iPads) and Process Orchestration (allowing orchestrating complete business processes in one suite consisting of SAP NetWeaver Process Integration, SAP NetWeaver BPM and SAP NetWeaver BRM) the possibilities of performing process integration are constantly being extended.

In this article, we will not define further specifics of the various SAP Integration tools. If eager to learn more about them, please look into the “



© 2011 SAP AG 24

Related Content” section or the various information sources SAP offers (SDN, Marketplace, etc.).

Summary

First, we have introduced you to the basic idea behind Integration Competency Centers and explained the advantages they bring in handling integration in your company. One step is to use integration platforms; the next step is to use them the correct way.

Then, we have introduced the need for a vision and strategy for your ICC, of which choosing a target model is one of the key tasks. We looked at the different ICC models and highlighted that you can either target a specific model or progress through the models over time. It is even worth to ask yourself if you already have an ICC, maybe without calling it an ICC, for example by having defined central guidelines for all your integration platforms.

After that, we have shown which kind of people you need for your ICC, how the processes of the ICC should fit into your organization and the different SAP technologies that you can make use of in your ICC.

That means, you now have the most important information at hand to start discussions about an ICC in your enterprise and work out a short-, medium- or long-term strategy for getting there.



© 2011 SAP AG 25

Related Content

The book “Integration Competency Center – An Implementation Methodology” by John Schmidt and David Lyle, ISBN 0-9769163-0-4.

The homepage of the Integration Consortium can be found under http://www.cloudyintegration.com/Integration_Consortium.html

More information about SAP NetWeaver Process Integration can be found under http://www.sdn.sap.com/irj/sdn/nw-soa

More information about SAP NetWeaver BPM can be found under http://www.sdn.sap.com/irj/sdn/business-process-management

More information about BusinessObjects Data Services can be found under http://www.sdn.sap.com/irj/sdn/ds

An article about positioning SAP NetWeaver and BusinessObjects Data Services can be found under http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/10fbac70-c381-2d10-afbe-c3902a694eaf

The Operations and Optimizations processes are based on the RunSAP methodology. More information about RunSAP can be found under http://service.sap.com/runsap

Figure 9: The RunSAP methodology

The Implementation Projects processes are based on the ASAP methodology. More information about ASAP can be found under http://service.sap.com/asap

Figure 10: The ASAP methodology

http://www.cloudyintegration.com/Integration_Consortium.html

http://www.sdn.sap.com/irj/sdn/nw-soa

http://www.sdn.sap.com/irj/sdn/business-process-management

http://www.sdn.sap.com/irj/sdn/ds

http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/10fbac70-c381-2d10-afbe-c3902a694eaf

http://service.sap.com/runsap

http://service.sap.com/asap



© 2011 SAP AG 26

Copyright

© Copyright 2011 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Oracle Corporation.

JavaScript is a registered trademark of Oracle Corporation, used under license for technology invented and implemented by Netscape.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company.

All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

How to Define and Establish an SAP Integration Competency Center (ICC) · 2017-02-23 · How to...

Documents

Transcript of How to Define and Establish an SAP Integration Competency Center (ICC) · 2017-02-23 · How to...