Frequently Asked Questions
Delivery and Operations
What approach is followed to let kuori become a part of my ecosystem ?
As kuori is not a black box, COTS package, but an integral part of the ecosystem, it's not something you can just install by clicking 'next' a couple of times. kuori needs to connect to your servers, integrate with your overall security policies, and so on. This needs to be discussed, configured, tested and approved. This step can be seen as a project, and we refer to it as the Setup (project/phase). At the end of the Setup phase, Acceptance Criteria are used to determine whether the kuori configuration is up to specifications. Once you (the customer) has verified this, then we end the Setup phase and deploy into production. From then on the normal subscription starts running, which can be cancelled at any time.
So, in short, there are 3 important steps:
Active in production.
What happens during the Setup Phase ?
During Setup, a number of crucial activities take place:
Understanding the high level needs is insufficient to deliver the proper quality. During the setup phase we deploy example components, so their behaviour can be examined by the customer and the kuori team. This provides better insights in what the best technology is to use, but also how that should be configured within the customer context (it is a very different configuration if something needs to be fast, but the occasional dropout is not a problem vs lower throughput but high-availability). Working with our customer we arrive at the ideal setup (cost-efficient, meeting requirements). The insights are also used to refine and expand the acceptance criteria document.
Modus Operandi (MO)
Because we start deploying components early and frequently, automatically a way of working with our customers is established. How many environments are there? How does our release process integrate with your release process? As we deliver a part of your ecosystem this is very important, but often overlooked. If we have remote deploy permissions (or host ourselves) and an easy process of notifying the correct people at the customer, our effort to bring new patches into production will be significantly lower than if this has to happen via long approval flows ('red tape'). In turn, this may affect the subscription fee.
Finalize Acceptance Criteria
As stated in the 'Fit-for-Purpose' section, the setup phase is used to find the right configuration of components, but also to put these findings in the acceptance criteria. The Acceptance Criteria is a list per component or group of components. This list contains the items that will be tested/validated by the customer before clearing a production release.
In our experience, customers struggle with providing detailed acceptance criteria up front. Instead of moving ahead with assumptions, best guesses and missing parts, kuori uses the setup phase to support you in specifying the acceptance criteria that really matter to you.
Example: kuori deploys components to have data flow near real-time from a source system to a service API (with some transformations). In a first deploy we may have provided a parallellization of 6 (nodes). After testing we see that running on 3 nodes only has a marginally higher latency, while providing a significant cost saving for the customer. The customer validates that the performance with the 3 nodes is acceptable. We then 'translate' this insight into the acceptance criteria : "an average latency between source and target should not be higher than 1 second". Typically more details about how this will be measured (which intervals, what are acceptable peaks, ...) are included as well. The other side is an adaption of the infrastructure cost for that component, which can be set a lot lower. Result: a formal agreement that for the lower cost the customer is satisfied with this performance of the system.
At the end of the Setup phase, the Acceptance Criteria are finalized, and when the entire setup is released to an acceptance environment. You also have a list that correctly represents your needs.
Fit-for-purpose: The kuori components are configured and tweaked to work as requested
Modus Operandi (MO): a practical way of working on environments is established (where do we deploy, how do we notify when deploys happen, how do we promote from dev-test-prod, how do we integrate with your release process, what environment is hosted where, who has credentials for each environment, ...)
Finalize Acceptance Criteria: Seeing components in action on the actual customer environments leads to new insights and understandings of what is really important. These findings are discussed and changes to the acceptance criteria are made. By the end of the Setup both Customer and kuori team have a clear, documented, agreed/approved and common understanding of when the kuori ecosystem works as expected.
What does the Acceptance Phase entail ?
Deploy on Acceptance
When the configuration of all components has been done, and acceptance criteria are clear, there is a bundled release of the entire kuori eco-system to an acceptance environment. We coordinate this with you, as it is then up to you to verify both the functional requirements (correctness) and acceptance criteria (quality). We set up a planning together when you will be testing, so we can make sure to have support people available, where possible.
Testing is completely up to you, but we typically see that there are 3 groupings of testing:
Deploy on Acceptance Environment
If all goes well, bugs are found and fixed (or no bugs are found), and you have been able to verify that the kuori ecosystem does what it should do, and does it with the proper quality. When you give the "Go" signal (in the manner we agreed upon during Setup as part of MO), we then plan the production release. As the alignment with your release methods has been done, the manner in which this deployment happens can vary wildly, but is always aligned to how you want to work (very agile, devops-style releases to production vs formal packacing in planned release weekends, ...).
In case that during testing (or already during Setup) there is a "No-Go" (which of course is highly exceptional, and something we try to avoid at all cost), the relevant part of kuori (or entire eco-system) is not released to production. It is a part of the contract negociation to clear out what happens in this case.
functional tests: Does a component (or group of components) do what it's supposed to ? if a component exposes an API, it can be tested if the API conforms to the specification (contract). If it should ingest data, does it take all the changes from a database (deletes, updates, inserts) ? ...
quality of components: as listed in acceptance criteria: performance, peaks, latencies, ...
quality of eco-system: typically done together with eco-system tests for the business applications that run on top of kuori : is the entire security setup correct (with kuori working within the confiments dictated in acceptance criteria or a security reference document that you have)
What do I get once we go into production ?
As soon as a release to production has been carried out, there is a monthly subscription fee that covers all your costs (transparent Total Cost of Ownership, or TCO). The monitoring is done by kuori, to ensure that the agreed SLA's are met. The right to use kuori is evidently included as well. Finally, following up on changes of the underlying components (e.g. security patch for Kafka) are done as well, to ensure that the entire eco-system stays up-to-date.
The world changes, and so does your company and her needs. We firmly believe in freedom and flexibility. If some components are not needed anymore you can cancel the subscription, and the following calendar month this already takes effect. In case that there is a technical impact throughout the eco-system the 'phase out' is coordinated together with you.
What to do when we detect an issue ?
Once you have a kuori ecosystem in use you can rely on our incident management when issues occur. Here is some practical information.
In your contract there is a specific section on SLAs (including examples of priority tiers for incidents). If you're a new customer or visit this page as a prospect, and want to have more information, contact us to receive our standard SLAs, or to discuss how we can meet your SLA requirements.
In practice, there usually are a handful of people at your company that receive a login on our service desk portal (Service Desk Users). As kuori usually is the information and integration foundation of your ecosystem, the people who can create incidents are typically technical people (System Engineer, Technical Architect, Lead Developer, ...) and maybe their manager (for direct status and follow-up of incidents in our portal).
The process that is followed is a standard ITIL based process:
Incident Detection: When something unusual is detected, you discuss internally to see if the cause is likely (partially) in the kuori ecosystem. All possible information is gathered (sometimes we agree on a template/checklist to minimize wasted time in back-and-forth questions).
Incident Logging: One of the Service Desk Users logs in to our portal, and logs the incident. For SLA purposes, this moment counts as the start of the incident.
Incident Diagnosis: An initial confirmed receipt response is given, after which the kuori team conducts an initial diagnosis. This is both checking that sufficient information is available in the logged incident, as well as evaluating the severity and priority of the incident.
Incident Assignment: Following the SLA stipulations, a category assignment is made for the incident.
Incident Resolution: both short term workaround as long term fixes (is needed) are worked on by the kuori team. Typically this involves you as well, as additional questions will be raised, and workarounds are asked to be tested.
Incident Closure: after a resolution has been found that is satisfactory for you (accepted workaround short term), the incident is closed.
Reporting: A periodical report on the relevant KPIs (Key Performance Indicators) set in the SLA is provided to you.