ITCAM for SOA 7.2

Typical usage scenarios

The following scenarios describe some usage scenarios using the Tivoli® Enterprise Portal and ITCAM for SOA to monitor and diagnose problems in your application environment.

These usage scenarios refer to the following fictitious personas that might reflect typical positions in your organization:
Table 1. Primary Personas
Persona Description
Annette/Olivia – Level 2 Operator
Annette's (or Olivia's) primary focus is to ensure service availability by fixing the important incidents according to the following criteria:
  • Fix the incidents as quickly as possible.
  • Fix as many incidents within the allotted timeframe as possible.
  • Understand the impact of any incident to a particular service.
  • If the incident cannot be resolved, then follow the escalation procedures.
  • Do not miss any critical incidents.
  • Know the incident to be worked next, prioritize according to urgency, impact, and service level agreement (SLA).
  • Know about the incidents before any customer calls.
  • Communicate with the necessary people (within Network Operations Center (NOC), to SMEs and outside to the business units).
  • Have a smooth transition between shifts (outstanding problems resolved or at a state where they are being worked on).

Annette (or Olivia) proactively finds negative trends affecting the business and follows proper change management procedures to prevent incidents from occurring or recurring. She does not like to be bombarded by false alarms.

Jim/Miles – Middleware/Application Support Subject Matter Expert (SME)

Jim's (or Miles') primary focus is to ensure that the middleware applications he is responsible for are up and running at all times and performing within expected response thresholds. If an application goes down, then a line of business is affected and has a direct impact on how his team is rated against the SLA. He also works with the systems monitoring and automation group to define the appropriate monitors and thresholds for his domain area of responsibility.

Additional goals:
  • To be notified of a problem as specified by the agreed-upon escalation procedures and not be distracted in things he is not interested in.
  • To make sure that everything is working as expected, so the company is running smoothly, and that appropriate process are in place, so that L1 and L2 can fix simple issues. If he has to be contacted at home for an issue, he knows that it requires his expertise.
  • Quickly and accurately determine the subject matter expert to whom he is to route the problem if he, himself, cannot fix it.
  • Provide other subject matter experts (application developer, web administrator, network administrator, and so on) with enough information to fix availability and performance problems.
  • Have the correct tools to control the content he can see, while not having control over how monitoring is implemented.
  • To focus more on transaction monitoring in his middleware.
  • To gauge capacity that his systems will need in the future.
  • To have adequate levels of monitoring in place (that can detect problems ahead of time and alert only on real problems) so that being paged in the middle of the night is more the exception than the rule.
  • Refine and update SLA thresholds to better reflect actual needs of line of business (LOB), meeting with most LOB managers to understand their experiences with WAS-hosted applications and gather information to help with his SLA projects.
  • Drive an increase in the percentage of upstream resolutions, and document and quantify the amount of time and resources saved.
  • Deliver SLA threshold compliance reports to all stakeholder groups on a quarterly basis:
    • For outages that exceed thresholds provide problem details and business user impact.
    • Derive some of this data from trouble ticket system reports.
  • Sync up with other SMEs in Level 2 to improve efficiencies in business processes and look at ways to grow the team next year.
  • Correlate problem occurrences with changes in the IT environment.
  • Definitively identify the root cause of problems, as well as the potential impact those problems have or potentially could have.
  • Fix problems (in the agreed upon timeframe) without having to escalate them to the services, development, or architecture teams.
  • Be aware of changes to the services architecture before they are rolled into the production environment.
Maria – BPM Maintainer

Maria's primary focus is to reproduce BPM reported problems using the administration account or using the user account. She must be able to identify where the BPM problem is located, and resolve simple problems herself or ask for help from the IT Administrator. She might sometimes deploy the problem fix upon the user requirement, or refer to the service level agreement to deploy the fix. She also educates users on how to use the system correctly.

Adam – BPM IT Administrator

Adam's primary focus is to support the line of business (LOB) when they want to author a process, need a new role, need a new service, or get confused. Adam works within a test and production environment that empowers the business user and is available at all times.

Sophie – Install and Configuration Administrator

Sophie's primary focus is on installing and configuring the tools (input feeds) needed to produce relevant and accurate information, in terms of classification, severity, and priority. Sophie is responsible for keeping the tools available at all times and updated with latest versions, patches, and e-fixes. Her duties include installation, verification in a production environment, and any data migration needed.

Sophie assists the lead product administrator in supporting the users of the tools by:
  • Training operators on how to use the tools.
  • Answer “why did this issue happen” questions.
  • Perform after-the-fact problem determination or error analysis.
  • Integrate the data sharing between tools and the smooth launching between them

Sophie must be able to quickly and accurately pinpoint software problems with a tool, and work with the tool vendors regarding problems and enhancements.

Table 2. Secondary Personas
Persona Description
Dave (or Deepa) – Application Developer

Dave's (or Deepa's) primary focus is to improve the company profits by developing in-house applications that work correctly the first time. He incorporates best practices in his coding to leverage the knowledge of others in his programs, and is diligent when conducting code inspections. When a problem comes up in a production application he is sent trace files so he can analyze the problem, which he then tries to simulate in his environment. He accurately determines the cause of performance problems when requested, and has a good understanding of the business aspects of the application he is developing.

Connie – SOA Development Manager

Connie's primary focus is managing assets through the development and test cycles. She analyzes requirements and designs solutions, including Service Interface Specification, prototypes service implementation, works with development and test / mediation teams to implement the solutions. Connie also develops prototypes of applications and helps define dependencies on service. She publishes "Golden Master" code to the Operations manager, creates Documents of Understanding (DoU) and subscription requests, and creates Service Level Definitions (SLDs). Connie evaluates specifications, evaluates the SLD and creates SLAs per the conditions of the DoU.

Table 3. Buyer Personas
Persona Description
Allen – System Management Architect

Allen's primary responsibility is to always know the status of the existing monitoring tools and services. He is aware of current monitoring and management technology and ensures that the service architecture has a high level of reliability in production. Allen detects the differences (without error) between the designed services architecture and the actual services architecture. He prototypes potential changes to the architecture and has a realistic view of their effects. Allen is able to show the relationship between the business process and the services architecture.

Kathryn – LOB Manager

Kathryn's primary focus is to drive up revenue from her customer facing services. The goal is an increase greater than 20%. She fosters a strong working relationship with the CIO and senior IT management. She negotiates and restructures contracts with outsourced contracting and consulting groups to better reflect development and support needs for her rolling 24 month planning cycle.

In the short term, Kathryn wants to know only the significant problems with her services. For these critical incidents, she needs to:
  • Proactively see the critical incidents before any external customer calls about them.
  • Understand the incident in terms of the impact to the external customer, and not be overwhelmed with technology information.
  • Feel comfortable knowing that if there is an incident, the IT personnel are aware of it and already working to resolve it.
  • Know when business services are trending toward violation of the SLA.

In the long term, Kathryn needs to know how well her applications are providing services to, and producing revenue from, the external customers. She ensures that the IT team is monitoring the critical resources for her application, and obtains service availability and IT cost information from the IT team. She works with IT administrators and architects to model the business processes, and helps IT understand the service applications, and their customers' steps and their experiences. Kathryn helps the IT team prioritize which incidents are critical to their customers, and works to ensure that she is getting the best value for her IT dollar (for example, by comparing her internal IT team to an IBM® IGS outsource group).



Feedback