Planning Your Camunda Proof of Concept

A crucial part of any successful POC is the planning stage—this sets the stage for how the POC will unfold and clearly demonstrate your requirements.

Welcome to the first blog in our Proof of Concept (POC) series to help you run a successful Camunda POC. Over half of software projects fail and having a well-planned and executed POC can help you reduce that risk.

In this blog, we will provide guidance on how to plan for your POC so that you can accurately show that your requirements are being met and that you have a clear path to understanding the success and/or failure of those requirements.

First, let’s just take a moment to make sure there is a baseline understanding of the POC process and then we will jump into recommendations on planning that POC.

What is a POC?

In a broad context, a proof of concept offers verification that your concepts can be practically implemented. When it comes to technology, this might mean that you need to demonstrate the practicality of a specific software project.

It is common, when executing a POC, to create a prototype application to demonstrate the functionality required to determine if Camunda is the right solution for your process orchestration needs. Some common aspects relevant to your POC may include:

• Does Camunda fit into your architecture?
• Does the development approach fit into your organization’s approaches?
• How can you model a specific business domain problem?
• Which kind of know-how is needed for the business and development teams?
• Which effort will typically be needed for these kinds of projects?
• What are the impacts of process applications for operations?

You may want to engage directly with Camunda, one of our partners, or a specialized consultant to assist you in performing the POC.

As part of POC, it is important to have the proper POC definition, scope, and evaluation process. You may also want to include a demonstration to the POC team as well.

Defining your POC

One of the most important components of planning your POC is to have a clear objective or definition of what concept(s) you are trying to prove. This objective should be written in such a way that it will encompass the criteria or requirements you want to prove by undertaking the POC. For example, your objective might look something like this:

“This POC is to demonstrate how we can improve the processing of our online orders in a more timely manner using process automation with Camunda.”

The objective or definition is the first step in the POC planning process. Next, you need to scope the requirements that will be covered in the POC project and document them.

Scoping your POC

You need to have a clear focus going into the POC about what you are trying to achieve and how you plan to achieve it. This may include modeling a process, using one or two Connectors to integrate with other systems or capabilities, creating a service task, showcasing human tasks where applicable, and showing a dashboard depicting process analytics from the POC. This doesn’t need to be part of the definition, but should be included in the scope.

You want to make sure that you also put parameters around your POC. This includes:

• A definitive timeline of when the POC will run
  For example, the POC will run over a period of two (2) weeks. You can get more granular with how many days will be allotted for things like installation, building, testing for success/failure, demonstrations to key stakeholders, and documenting results.
  
• A definition of POC participants
  A key part of the POC is that the right individuals are involved when required. You may require the proper personnel be available for installations, building processes, access to usernames and passwords for integration points, meetings and other important milestones during the POC. Clearly defining the role of each team member and their contact information helps to keep the POC on track. You may want to consider implementing a RACI matrix to help manage participants and their responsibilities.
  
• A clear list of assumptions
  A POC needs to have a clear list of requirements, but also a clear list of assumptions. For example, you may need to extrapolate based on a simpler use case around system integration for the POC. You also may need to make assumptions about availability of various team members and time they will be free to work on the POC. In addition, you will want to document any technical assumptions. This would be a good time to map technical and stakeholder risks using the RACI matrix.
  
• A specific set of requirements
  This is where you outline what you are trying to prove. As previously mentioned, this might be a list of specific components of functionality. For example, “the POC will demonstrate the connection to one other system using the REST Connector” or “the system will demonstrate one human step providing three (3) different field options on the displayed form.”
  
• A clear definition of success and failure for each requirement
  This may be the most important part of your POC. It is very important that you document the expected response or result of each functionality component to be tested so that it is clear if it was a success or a failure. For example, “the REST call to the XYZ System provides a response of the form <put the JSON form expected here>”. You may also want to add a second component of that response that explains how you are able to update a process variable based on the JSON response to your REST call.
  
• How you plan to document and present your results
  Executing the POC is one thing, but making sure that you document and present how it performed and your case related to its success or failure is equally important. You want to make sure that you plan for the correct audience and how you will present the media (slides, demonstrations, examples) that will be used to show the results.

Planning your technical environment

The best practice when embarking on a Camunda POC is to use Camunda SaaS for your environment, which helps to minimize or eliminate the installation process and allows you to focus on the functionality to be provided by the process being automated.

In this case, you can often use a test account unless your POC will include some sort of load or performance testing. When doing this type of testing, you will want to engage with Camunda to help you determine the configuration and clusters required for your POC.

If you are trying to validate the installation process of a self-managed Kubernetes environment, then you will want to make sure you plan ahead for the time required to complete this installation.

Camunda recommends that you also take advantage of a repository to hold any code you develop outside of the Camunda organization. Your Camunda process models can be versioned within Camunda, but if you are developing a service task or webhook that needs to be coded, you may want to store that in a system with version control, like GitHub. This will enable you to keep track of changes made and to rollback to previous code versions if required.

Finally, if you are accessing an external or third party environment, you will want to do some simple testing to confirm that they are accessible for the POC.

Example for documenting success or failure

As previously mentioned, it is key that you properly assess the success or failure of each requirement you are trying to prove. You will need to document the requirement, how to “prove” success or failure with expected results, the success or failure and then any comments about what you encountered when you tested the requirement.

You may also include (or only include) an overall success or failure of the POC; however, often consideration of each individual requirement on its own is worthwhile, as there may be alternative ways to address an individual requirement or you might be able to modify something else to be sure a requirement can be met—such as changing the target/source system call.

The following example may help you understand how to document those requirements and how they might play out during a POC execution.

The requirements matrix

Many POCs provide a documented requirements matrix that documents the requirements, testing results and comments about the actual testing approach and results. The table below shows a simple example of one requirement for a Camunda POC.

What this might look like when running the POC

The example video below shows how this requirement could be demonstrated as part of your POC. First, let’s provide a little background. Keep in mind that for your POC, this might be a single step in the overall BPMN process.

The REST service to be called

In this example, we are using a public API REST service that will return a total mortgage payment but in a standalone process for execution purposes.

You will need to know the input parameters, the headers, the authentication type and the expected response in order to complete this requirement. You may or may not want to add those specifics to your POC documentation.

As you work with your team on POC planning, you can determine how you want to prove/demonstrate the success of each requirement.

More on Camunda POCs

To get more information on executing a POC with Camunda, please review our documentation on POCs.

If you are looking for additional guidance, don’t forget to reach out to our consulting team and discuss a POC workshop.

Getting started with Camunda

Sign up for a Camunda Starter plan today and get started with a 30 day free trial!

Already have a trial? Upgrade to Starter today

If you already have a trial and want to continue with the capabilities of the Starter plan, you can ensure a smooth transition by upgrading today.