This post takes you through an approach that you could use to design a Kaizala solution. In case you are already following a design process, would be a good idea to read through and include the Kaizala specific areas to your existing processes. Often, rushing into developing a solution without having a good understanding of the scenario causes issues at the later stages of ship cycle which can prove to be very expensive (and hopefully avoided with a good process in place).
I have outlined a 4 step approach for the entire cycle from conception to ship: Plan, Design, Prototype, Build & deploy.
Once you have the customer scenario / requirements, check if you have all the required details like information host (like LOB systems, internal databases, may be non-existent, etc.), people involved (employees, front line workers, etc.). With the information you have, see how Kaizala fits in the solution and come up with a story-line that maps requirements to Kaizala functionality (for eg. System sends out a survey every weekday and manager gets a report, etc.).
Once you have the requirements in place, brainstorm and see if all the scenarios are feasible on Kaizala.
In the design phase, come up with the implementation details. Identify how many of them could be achieved using out of box actions like polls, surveys, announcements, etc. Check if the features on Kaizala management portal suffice managing and reporting functionality required. Identify any custom development effort that may be required and the groups you will require based on the functionality and the people in the groups.
Identify the service integration points, like connecting Kaizala service to the customer’s LOB application, writing a custom service that can act as a bridge between the 2 services, etc. Identify the kind of network the customer’s systems are on – are they public facing networks, will they need integration points to be white-listed, etc. Also, check if you will need access to the customer’s system directly from the action card itself, and if yes, can they be secured with the identity system that Kaizala provides (Kaizala Integration Service token).
By this point, you have the pieces that you have identified the pieces to build. Come up with the very basic components that you will need to validate. To give a couple of examples,
- If you are building a card, you may want to prototype:
- KASClient SDK calls, any external network calls, etc. You can defer the UI/UX to the development phase.
- The values and configurations you want to have in AppModel and package manifest files.
- If you intend to send this card programmatically, identify and validate action card properties (if any).
- If you are building a Kaizala webhook integration, there are 2 things you can do:
- Try building the web method and hit it with a REST client like postman with a sample payload and write the adapter to consume the payload and integrate with your system.
- Register a webhook with a webhook test site like https://webhook.site and from the card, submit the request / response and validate you have all the data you expect.
- If you are building a service that will need to be called from Kaizala card, build the integration validation logic and how it fits in the overall system.
Build & Deploy
At this point, you are fairly comfortable with the solution you want to develop. You may want to finalize the design and review with your stakeholders if there were changes in design. You could then go ahead with the full blown development of the solution (cards, services, etc.). You should think of how you want to test out your implementation and have suitable error handling, etc.
When it goes well, you are ready to deploy!
Hope that was helpful. If you want anything more covered, please let me know through the contact page.