Planning Considerations for Service Orchestration

Service orchestration requires extensive coordination between various teams which means that planning is essential. The bigger the implementation, the more important it is to start with a detailed planning phase. This topic goes over what you have to consider when preparing for such an implementation.

Being the Project Manager

If you are responsible for the implementation of an automated service orchestration process at your organization, you need to plan the project and then oversee its development. You are the project manager.

Sometimes the role of this project manager is filled by an IT service owner or an IT service administrator for the system that initiates a service request. Other people who are also well positioned to be the primary project lead are an Automic Automation Workflow designer or an Automic Automation administrator.

Whatever your role is, you will have to involve people from each of the systems involved. Among your main tasks are identifying the right people, getting them on your project, and then ensuring clear communication between the teams.

First Step: Detail the Process

Most likely, you are trying to automate a process that is currently being done partially or completely manually. Therefore, people who best know all the steps involved are the people who are currently providing the service. With their help, map out the process. If a procedural manual or other documentation exists for any part of the process, also use them and corroborate the steps with your experts. Your end result is a detailed document of the entire process. Remember to include steps that must be done by a human being, such as approval steps.

Identify the Systems Involved

From your process map, identify the systems and components involved. In addition to Automic, typical types of systems that are also involved in a service orchestration process are:

• Systems on which the service is located, for example the server that needs to be maintained, the cloud-based server that hosts a virtual machine, an application that needs to be provisioned
• Monitoring tools
• Incident management solutions
• Databases
• Applications
• Add-ons and plug-ins

Identify the People You Need

In addition to the people who are currently doing the procedure, you need the people who will make the automations possible. The types of people you have on the team depends on the skills needed for your specific implementation. The following are typical people you need and the kinds of things they would be responsible for:

• Automic Automation administrator
  • Provides a system user and its authentication details through which incoming messages, posts, payloads, and other data can be received by Automic Automation
  • Creates agent assignments for the clients that need to receive the incoming traffic.
  • Installs any required action packs or add-ons on all relevant AE instances
  • Provides the same for all other relevant AE instances and Clients
  • Provides a test environment
  • When rolling out a solution to other locations, deploys the workflows to all Automic Automation instances and clients.
• Automic Automation Workflow designer
  • Creates and tests the central workflow that provides the required service by orchestrating all steps across all systems.
  • Provides lists of required workflow parameters to the administrators and developers of any systems or applications that need to deliver input values
  • Defines how to securely pass parameters in and out of the Workflow
  • Has expert knowledge about Automic Automation objects, prompt sets, variables, and scripts
  • Knows which Automic action packs and other add-ons are useful for the workflow
• System administrators of each of the other systems involved
  • Provides authentication information or solution for Automic to access the system, when applicable
  • Provides the infrastructure definition to Workflow designer
  • Defines how to securely pass parameters in and out of the system
  • Installs any required plug-ins or add-ons to communicate with Automic
  • Provides a test environment
  • Deploys the final solution to all servers and locations
• REST, Java, or webhook developers to code the posts and retrievals
• Form designers to create forms for collecting input parameters
• For cloud-based systems, cloud administrators
  • Provide cloud server access details (endpoint specifications, authorization account details)
  • Provide the required resources

Remember project stakeholders

In your plan, include people who are involved in the project even if they are not responsible for actually producing the deliverables. These are people who are accountable for certain deliverables, are consulted about certain deliverables, or just need to be informed.

Note: You can create a RACI chart to help you with this. Indicate whether each person or role is responsible (R), accountable (A), consulted (C), or informed (I).

Identify the Connection Points

In any process that involves multiple systems and applications, there are two critical considerations: security at the connection points, and optimal performance at those points. Therefore, with the help of the experts on your team, determine two aspects for each connection point:

• The authentication approach

  This needs to be a secure approach. Will you use encrypted REST calls, key certificates, or an authentication standard such as OAUTH or Kerberos.

• The data communication approach

  Can you do this with a REST call, a Webhook, a triggering event, or some other way?

Identify Any Missing Components

Automic has extensive integrations and its marketplace offers hundreds of out-of-the-box solutions to add to your AWA installation or to a third-party vendor (such as ServiceNow). Determine which solutions can optimally support your implementation. Make sure they are available on the necessary systems.

Provide a Test Environment

Any integration project has a mixture of complexities and potential fail points. For this reason, we highly recommended that you develop and test the automated process in a sandbox environment before implementing it in a production environment.