If you are like most companies, you use various software applications to support your business, and often you have applications from multiple providers to support users in a certain domain. To get the most out of the applications and data you have, it can be helpful to integrate them.Integrations help prevent costly manual work to keep data in sync, and combining data helps you gain better insights to support good decision making to achieve business goals. To help you build helpful integrations, BowTieServer has two new APIs that make it possible to connect your bowtie related data to and from other applications.
API stands for Application Programming Interface, which is an interface to software that allows two applications to talk to each other. This blog explains the basics of APIs and how to use them in an understandable way.
Bowtie Update API
The new Bowtie Update API allows for updating all basic properties of the 8 standard bowtie element shapes. To be more specific, you can update properties of the Hazard, Top Event, Threats, Consequences, Barriers, Escalation Factors and Escalation Factor Controls. Some examples of properties that can be updated are Barrier effectiveness, Threat frequency, Consequence category and many more.As an example, this means you can have a risk register outside BowTieServer and integrate in a way that any change you make in the risk register software (e.g., update frequency of a specific Threat), it automatically updates that threat and reflects the new frequency in BowTieServer.
Another method that the API supports is the creation of a new bowtie. This means you can implement a button in the risk register software with a name as “Create bowtie” and this could call the BowTieServer API to create a Hazard + Top Event. BowTieServer will subsequently send the new unique ID (GUID) and a URL back to the bowtie. If you then show that URL in your risk register software, you have a direct link between your risk and the new bowtie that belongs to it in BowTieServer.
Is it that easy?
Well… Probably the data format, taxonomies, and other complexities of both software applications are quite different. Therefore, a direct API to API integration is often not possible. You would require implementing middleware, that basically functions as the connective tissue between the applications. The middleware can make sure that the data (format) is transformed so that it can be received by the other application, it can store a mapping of reference table values, or you can define some business logic and let the middleware apply it before sending a request through.
