Center of Excellence

As part of DevOps initiatives, digitalization projects and cloud migrations, many customers are investing in application performance management (APM).

The aim is to increase customer satisfaction and the associated revenue growth, which can be achieved through faster release cycles and the resulting reduced time-to-market with improved software quality. It is often assumed and also suggested by the manufacturers of APM solutions that this can be achieved with the purchase of the new tool.

However, as our experience shows, this is not a realistic approach. The added value of APM can only be fully realized and an ROI achieved if the necessary processes for constantly updating and improving the APM process are established and anchored in the company.

With the amasol Center of Excellence (CoE) for Application Performance Management, we offer a proven process and implementation concept for such a secure and well-anchored operational adoption of APM in the customer organization.

The CoE thus ensures that our customers make the best possible use of APM’s potential. We achieve this through our technological expertise in the field of APM and by setting up a CoE. At the same time, we ensure that our customers can make the most of the full potential of the APM solution without our consultants having to be permanently on site. This leads to a better understanding of end user behavior and enables constant monitoring and improvement of the end user experience. By integrating the CoE into the entire application lifecycle, important digital initiatives can be supported at an early stage, which contributes significantly to better product quality. The linking of CoE and APM is amasol’s unique selling point.

In the CoE, we combine the expertise of amasol with the IT expertise and competence of the users on the customer side. The result is a framework that offers our customers:
• the possibilities of APM in a tangible way,
• helps to recognize the cost-benefit ratio of the APM solution used,
• enables you to fully exploit the potential of APM and helps you
• to permanently optimize the performance of your applications,
• makes it possible to use amasol’s expertise on a permanent basis without having to make large investments.

The customer is supported by amasol in setting up the CoE. The support is gradually reduced. Experience shows that it takes around twelve months to set up the CoE, during which we work together intensively. The customer can then continue to run the CoE completely independently or, depending on individual requirements, continue to draw on amasol’s expertise for support.

Roles and organizational structure of the CoE

We propose that the CoE be firmly established in the organizational chart on the customer side. The following roles need to be filled:

CoE core team

This comprises all employees from the customer’s IT department who work 100% in the CoE.

CoE experts

Employees (primarily from the IT sector) whose expertise is required on a temporary basis. The time required amounts to 20 to 50% of the weekly working hours. As a rule, however, these are not new activities, but tasks that have already been carried out by these experts in the past, such as troubleshooting in the event of a problem. What is new, however, is that the work organized via the CoE.

CoE users

These are interested and IT-savvy employees from the customer’s business units in which the respective application is used.

To prevent resource struggles, we suggest setting up a steering group for the CoE within the IT department. This consists of all team and department heads, from whose ranks employees work as “experts” or as a “core team” in the CoE.

This steering group reports directly and with one vote to the IT management. The task of the steering group is to define the work content and align the interests of the CoE with the interests of the IT departments.

Preparatory work for the establishment of the CoE

Before the CoE can be set up at the customer’s premises, only a few central preparations are required.

Strategy workshop at management level

The aim of the workshop is to the foundation for the introduction of the APM software and the CoE at management level . To this end, the “decision-maker” on the customer side should open the meeting and explain to those present why the company has decided to make this investment. The objectives for the project are from this “statement”.

During the strategy workshop, amasol’s consultants show how the objectives can be achieved (with the help of the CoE). The strategy workshop can deal with the following topics:

• Presentation of the possibilities of the APM solution used
• Presentation of the possibilities of a CoE
• Consideration of how the CoE can be structured and staffed specifically for each customer

Basic training for core team and experts

The core team and experts require in-depth specialist knowledge of the software, which is taught in a basic training course. At the time of the training, the participants should be aware that they will be working with the software in the form of a CoE. In addition, there should not be a large time lag between the start of work in the CoE and the training so that the know-how gained can really be used optimally.

Application training for business users

In a less in-depth training course, business users are trained in how to use the software.

Work organization via a Kanban board

All CoE tasks, regardless of where they come from, are recorded, distributed and processed in a Kanban board. The ticket system used the customer serves as the basis. Most IT departments work with Jira. Together with the core team of the CoE, amasol’s consultants define the basic logic and structure for setting up a Jira board for work organization in the CoE.

All incoming tasks are recorded in the “Backlog”. Once a task has been prioritized and prepared, it is moved to the “Ready” column. When an employee starts working on a task, the task is moved to the “Doing” column. Once a task has been completed, it is moved to the “Done” column. The organization of work in a Kanban logic is suitable for IT specialists. As all tasks in the areas of monitoring and support arise ad hoc and must be processed immediately, there is no need for time-consuming coordination meetings in these areas.

Work organization in the CoE (ad hoc tasks from monitoring and support)

The organization of work in the CoE is based on the basic concepts of agile working and draws on relevant methods and structures. In the following, we describe the work organization along the tasks that are processed in the CoE.

These essentially originate from two areas:

Monitoring of predefined parameters of deployed applications

Certain parameters of the applications used are constantly monitored. If a parameter changes significantly, this results in a task for the CoE. These tasks arise ad hoc, they cannot be planned and must be prioritized.

Tickets from support for the applications used

If an end user of an application has a problem with its performance, he/she contacts IT support (as before). As a rule, IT support creates a task in the customer’s internal ticket system. These tasks also arise ad hoc, they cannot be planned and must also prioritized.

Work organization in the CoE (systematic improvements to the performance of individual applications)

In addition to carrying out all routine monitoring and support work, the CoE offers customers the opportunity to analyze, improve and further develop individual applications in a targeted manner. To this end, the IT, Operations and Business departments work closely together, controlled by the CoE. These tasks arise in a targeted manner and can be processed in a planned manner. This requires separate structures. The consultants at amasol advocate a gradual approach to performance improvement. This means that only one or two applications should be the focus of optimization at any one time.

amasol forms a working team for each application that needs to be improved. This consists of CoE employees, IT experts and application experts from the business. The performance of each application is optimized in iterative improvement loops. In the following, we outline structures and processes for the work of the CoE in the systematic improvement of individual applications.

Target workshop

Once a specific application has been selected, all stakeholders and the entire CoE meet to jointly define the goal(s) to be achieved. We suggest a workshop-type format of around three to four hours for this. We do not yet plan any milestones or implementation steps here. It is simply a matter of defining the objective.

To do this, we answer the following key questions:

• What do we use this application for?
• What do we want to achieve by improving performance?
• How do we recognize that we reached our goal?

We record the result of the target workshop in the Kanban board used. In Jira, we can create an epic (i.e. a description of the requirement for new software) for this purpose.

Responsibilities and roles

Responsibilities and roles are defined during the target workshop. We suggest assigning at least two roles:

Project manager

This person acts as the central point of contact. Internally, they are the contact person for all those involved. The project manager knows the current status at all times and ensures that work on the topic is sufficiently focused. This person is not solely responsible for ensuring that the goal is achieved – but they keep an eye on when work on the topic is being done with too little focus and the overall goal is being jeopardized as a result.

Customer

If we want to work on improving an application in iterative loops, then we also need an instance with which we can check whether we are working on the right topics and whether our results are going in the desired direction. For this reason, we recommend consciously filling the role of the customer. As a rule, an application owner or key user is particularly well suited to the role of customer. All roles must be filled by at least one or a maximum of two people. It is not advisable to fill the roles with groups or to rotate them.

Goals and tasks per quarter

We recommend switching to a quarterly perspective for planning and processing the tasks that arise. Contrary to the classic logic of waterfall-style project management, we do not define an overall project plan. Based on the results of the target workshop, we answer the question of what specifically needs to be done in the next quarter.

There is also a quarterly meeting in which we identify and define the specific quarterly targets. Each quarterly target consists of two elements:

User story

In the form of a few lines of continuous text, we answer the question of why we are working on this topic. The user story must be related to the overall objective.

Checklist

In the form of a checklist, we define all the points by which we can recognize that we have achieved a quarterly target.

The quarterly meeting is by all employees who are actively helping to improve the performance of an application in the coming quarter.

In addition, all stakeholders and representatives of the steering group are invited, but their participation is not mandatory.

As we have defined the roles of the project manager(s) and the customer in the target workshop, it makes sense for these people to prepare the quarterly meeting by drawing up concrete proposals for the quarterly targets. All other participants can add to these suggestions. At the end of the quarterly meeting, we have expanded the overall goal (the “epic”) to include specific quarterly goals (always only for the coming quarter) and made them tangible.

Planning meetings (every four to six weeks)

For the planning of specific tasks and to-dos, we keep the time horizon even shorter. Here we suggest a basis of four to six weeks. In these planning meetings, we fill our backlog with specific tasks that we need to complete in order to achieve our quarterly targets. The planning meeting is attended by all persons who are actively required for the processing of tasks.

This meeting can also prepared by the project manager with concrete proposals for all upcoming tasks. These should be described in such a way that it is clear why we are working on them and how we can recognize that the respective task has been completed. The interdisciplinary team becomes extremely dynamic and powerful if it succeeds in breaking down the issues at hand into the smallest possible subtasks. The maximum size of a task depends on the respective area of work.

Two examples for orientation:

• In the area of software development, no task should take more than eight hours.
• In all other areas, it should be possible to complete tasks in a maximum of two hours.

If a task is larger, it must be broken down into subtasks. A time estimate per task is strongly recommended. Based on the time estimate of the individual tasks, the team gets a feel for how much work is involved in the individual topics. This makes it possible to quickly recognize whether the planning (for the coming four to six weeks) can be achieved with the available resources or not.

At the end of the planning meeting, we know which tasks we want to complete in the next four to six weeks, what resources we need for this and what dependencies exist between the tasks.

Two-week sprints

The team decides in the sprint planning who is specifically responsible for completing which task. This takes place every two weeks and lasts around 30 minutes. It is also mandatory for all those who will play an active role in the upcoming sprint to be present. Sprint planning is used to decide which tasks from the “Backlog” are processed by whom. All tasks for the upcoming sprint are moved to the “Ready” column.

At this meeting, everyone can coordinate, especially if the expertise of several people is required to complete a task. The team decides together how many and which tasks will be completed in the upcoming sprint. The tasks are also assigned to people who are responsible for completing them.

During the sprint, those responsible take care of the tasks independently. If difficulties or problems arise that they cannot solve on their own, they should contact the project manager. The aim of the sprint is to work on all tasks (“Doing”) and complete them
(“Done”).

Review (every four to six weeks)

Before a planning meeting takes place every four to six weeks, it is worth taking a brief look back at what been developed so far. All new functions, results and partial results that are relevant for the entire team are presented in the review. The “customer” is also present at the review. The progress of the project is presented to him on this occasion. The review only deals with the content and technical issues of the project. Even though we are describing two separate work steps here, it makes in everyday working life to hold the review and planning meeting on the same date.

Retrospective (every four to six weeks)

The collaboration of an interdisciplinary team, as we describe here, is subject to many dynamics. The procedures described here must evolve depending on the structures and routines of the specific company. To make this possible, we recommend establishing retrospectives as a fixed structural element. In a retrospective, all those actively involved in the project come together to reflect on the way in which they work together and to make targeted improvements.

We do this by answering three key questions:

• What has worked well in terms of collaboration and should therefore be
maintained?
• What has not worked well in terms of collaboration and should therefore
be changed/abolished?
• What new idea do we want to try out to improve our collaboration?

Conculsion

The combination of APM and CoE gives us a consistent overview software performance from the mouse click in the browser to the mainframe. The successful integration of all relevant players also enables us to further develop and improve individual applications in a targeted manner in order to provide an optimal end user experience.

The CoE does not require any additional personnel resources. The added value is created by bundling existing resources and optimizing their interaction.

All ad hoc and unplanned tasks (from a ticket system and the constant monitoring of critical parameters) are accepted and processed independently by the CoE. The clarity of responsibility alone is an argument in favor of setting up a CoE. However, the interaction between APM and CoE unfolds its full creative power when it to taking a closer look at individual applications and developing them further in a targeted manner. bundled expertise from various IT areas in the CoE means that application optimization can be implemented very efficiently in order to achieve better IT quality for end users.

The CoE brings together all relevant stakeholders in a company (development, operations, business) and their interests. Thanks to the clear working method based on agile project design, the first results can usually be experienced after a few days to weeks.

Center of Excellence

Roles and organizational structure of the CoE

CoE core team

CoE experts

CoE users

Preparatory work for the establishment of the CoE

Strategy workshop at management level

Basic training for core team and experts

Application training for business users

Work organization via a Kanban board

Work organization in the CoE (ad hoc tasks from monitoring and support)

Monitoring of predefined parameters of deployed applications

Tickets from support for the applications used

Work organization in the CoE (systematic improvements to the performance of individual applications)

Target workshop

Responsibilities and roles

Goals and tasks per quarter

Planning meetings (every four to six weeks)

Two-week sprints

Review (every four to six weeks)

Retrospective (every four to six weeks)

Conculsion

Discover more about amasol

Our expertise

Resource center

Our tools

Why amasol

amasol

Additional Resources

Legal Information

MUNICH

VIENNA

NEW DELHI

LONDON