Why use Cloud Pak for Business Automation?

CP4BA differentiates itself in the market through four key different aspects:

1. Low-code/no-code: A completely integrated environment to build automation using a true low-code approach to build enterprise solutions – whether it is workflow, content, decisions, robots, apps, or interactive agents.
2. Built-in security, scalability, and governance: One argument against low-code/no-code is the proliferation of badly written solutions that are not secure, do not scale, or have a lack of change control. Given the enterprise software heritage of CP4BA, IBM already considered many of the non-functional characteristics that an IT shop demands, so clients do not have to worry about coming up with something themselves.
3. Built-in AI: There are many examples where IBM is pioneering the use of AI within its solutions with no need for customers to hire data scientists or any kind of ML modeling.
4. The breadth and depth of the portfolio: With thousands of clients using the technology inside CP4BA worldwide, chances are that some clients have implemented your use cases before and there is enough flexibility in the products to support your use cases.

The following section will explain, at a high level, how to design an IA solution.

IA solutions

When starting an IA project, it is important that we guide the stakeholders (often, these are the line of business owners or IT executives) to focus more on the intended business outcome rather than a specific set of technology. The intended business outcome can be to improve the customer engagement experience, speed up the time to value of existing projects, or increase the agility of the business in response to changing business conditions. By focusing on the business outcome, we can help LOBs to better define the business problems rather than just a particular solution upfront.

In this section, we will discuss how to go about the methodology and considerations to create a solution architecture for your IA solution.

Business analysis

An IA solution cannot be truly successful until we get buy-ins from both the business and IT sides of the organization. To get those buy-ins, enterprise architects can start with a business analysis and utilize an approach such as IBM Design Thinking to bring both business and IT together.

There are several important principles that enterprise architects and automation developers can use to create an initial concept of a solution:

• Hills: Hills are statements of meaningful business outcomes. They are written with users in mind and will describe the Who, What, and How aspects of what the solution is trying to achieve.
• Playbacks: In simple terms, playbacks are the gatherings of minds that are used to keep stakeholders, clients, and teams in sync. Playbacks should occur at regular intervals and often align with either the start or end of a development iteration of an agile development process.
• Sponsor users: Sponsor users are people that the project team engages on a regular basis to solicit and gather feedback. Sponsor users can be a part of your project team, but often, they are external users who can provide guidance and feedback as you design the IA solution.

This book will not go into detail about how you can apply Design Thinking to your IA solutions. For those who are interested, there are reference materials available on the IBM Enterprise Design Thinking website (https://www.ibm.com/design/thinking/).

Understanding the CP4BA architecture

To begin the solution design, a high-level understanding of the CP4BA architecture and its use cases would be beneficial. The CP4BA architecture is designed with modularity in mind – you can start with just one capability, for example, workflow or RPA, and add more as the use cases expand. As you add each capability, new integrated use cases will become available:

Figure 1.2 – The CP4BA logical architecture

The following table explains each use case:

Table 1.2 – Examples of CP4BA use cases

Business scenario – client onboarding

To start putting together the solution architecture, let’s go through an end-to-end scenario, where multiple pieces of these solutions are used together.

In this scenario, we are going to implement an IA solution to onboard clients for a fictitious national financial consulting company. The solution consists of a business application, where the client representative collects all the required information and the requested services about the client before the representative will submit the request to the back office for further processing:

Figure 1.3 – Client onboarding scenario with corresponding key personas

Before we can design the architecture of the solution, first, we will need to break down the business requirements into a set of hills. In this example, we are going to start with three hills. Each hill should speak to the desired business outcome that we want to achieve as a part of the automation solution:

• Hill 1: As a client representative, I want to be able to collect all the necessary information to onboard a new client in under 10 minutes.
• Hill 2: As an account manager, I want to be able to validate and onboard a new client in under 30 minutes.
• Hill 3: As an account executive, I want to make sure a new client can be onboarded within 2 business days, with a performance report on a weekly basis.

You might notice that the preceding hills do not mention any technology at all, but instead, we are trying to focus on the business values – in this case, we want to make sure any new client can be onboarded within 2 business days.

In this case, we have identified four personas:

• The client
• The client representative
• The account manager
• The account executive

As a solution designer, you will have to go through one or more playback sessions with the participants – in this case, with the client representatives, account managers, and account executives to roughly identify the outline of your solution.

Hill 1

We will be creating a business application to help the client representative collect all the information required, such as the contact details and the services required, and even offer a potential quote. Once all of the information has been collected, the client representative will then submit the request for further validation and approval, and to schedule the actual service date with the client.

Through the design session, it was also decided that the business application will have three steps:

1. Fill out the onboarding info
2. Review documentation
3. Submit for approval:

Figure 1.4 – Hill 1 high-level solution architecture

Within each step, we will also be using other automation services to gather the necessary information:

• On Page 1: We will be using the Workflow capability to retrieve the client information by name. The reason for using Workflow is that we already know there is an available service in the back office to work with client information. We will also be using Decisions to determine an initial quote, depending on the currently-selected service plan, along with any past transaction history with the client.
• On Page 2: The client representative will get an opportunity to review any prior documentation that the company has collected about this client and to submit additional information this client will have. In this case, all documentation is stored in the content service.
• On Page 3: The client representative will get a chance to review the collected information with the client before submitting the request for approval. The approval will be handled by the IBM Enterprise Design Thinking website by a workflow in the back office.

Hill 2

In this hill, we will focus on the work required by the account manager to review the submitted information from the front office, approve the request, and schedule the requested services with the client. If the request cannot be approved, both the client and client representative will be informed:

Figure 1.5 – Hill 2 high-level solution architecture

The entire process will be orchestrated by a workflow, where multiple automation services will be used together to complete the client onboarding process.

1. The process will validate that all the necessary information is available. In cases where information is missing, the system will wait for documents to be provided by the client before proceeding to the next step. The client can upload missing information by sending the data via email, which will then be picked up by an RPA bot to deposit the information into the content repository.
2. In this step, we will be using rules and machine learning models from Decisions to categorize the client into segment 1 or segment 2 and will also leverage machine learning techniques to determine whether the request is a low-risk or a high-risk request.
3. We will be using RPA bots to update existing legacy systems with the assessment results and onboard the client into the system of records.
4. We will be using another workflow to notify both the client and the client representative of the approval or denial. If approved, the workflow will also instruct the client representative to work with the client to schedule the actual service calls.

Hill 3

In this final hill, we will be focused on the experience of the account executives. On a regular basis, the account executive should be able to inspect the business performance of the organization, and make adjustments (for example, re-balance the workload of different account managers) or suggest changes in the scoring model:

Figure 1.6 – Hill 3 high-level solution architecture

There are three data sources that we can use to draw information from:

1. In Workflow, we can obtain process performance information, such as the number of new onboarding requests per day, the time it took to complete an onboarding request, and the relative performance of the client representatives and account managers.
2. In RPA, we can obtain information about the success and failure rates of the robots, along with performance characteristics to decide whether any changes are needed.
3. In Decisions, we can obtain information about the scoring models and potentially make a comparison to the actual business outcome.

Technical Foundation

Since we usually focused more on the business outcomes during the initial hill discussion, one aspect that we sometimes miss during the initial hill discussion is the Technical Foundation hill. Technical Foundation is where we lay down the non-functional requirements of the solutions. In this particular use case, the following aspects are important:

• What is the expected client traffic? Is it hundreds or thousands a day?
• What is the number of client representatives that we need to support?
• What is the expected uptime of the system? Is it 8x5 or 24x7?
• What is the disaster recovery requirement? What are the recovery point objective (RPO) and recovery time objective (RTO)?
• What are the security requirements?
• Any data privacy and GDPR considerations? Are we storing any sensitive personal information (SPI)?
• What is the timeframe for the project? (1 month or 3 months)
• What is the budget for the solution?
• What is the set of existing services that are available?

Many of these questions will have a direct impact on the deployment topology and the overall cost of the solution. While everyone might want to be able to support thousands of concurrent users and want the system to be up 100 percent of the time, it does not come for free. We will discuss this further in Part 3, Deployment Considerations, of the book, where we will go deeper into the deployment topology and architecture of an IA solution.