Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
By signing up for your free account, you agree to receive e-mails from Triggre.
By signing up for your free account, you agree to receive e-mails from Triggre.
In my two previous posts, I talked about bridging the divide between IT departments and business units and why innovative IT departments allow business units to make software themselves. I stated that it is necessary for the tools used by business units to make software themselves help IT departments to meet their goals as well. Today I will explain the concept used to solve this problem used in Triggre.
In computer science ‘separation of concerns’ means that a system is split into distinct parts, each with a specific concern. This way of designing a system makes it modular, which is a solution for managing a complex system. In businesses we see the exact same solution for large, complex businesses. Those organizations are usually separated in business units and departments, each with a specific concern. In other words, the different responsibilities of the organization are handled by different business units and departments.
The big question of course, is where to separate. And as organizations and software systems can be separated in an unlimited number of ways, this is not an easy question to answer. To know how to make a separation, we need to fully understand the responsibilities of the thing we’re trying to separate.
In the case of Triggre, there are a lot of responsibilities that need to be taken into account. For the sake of simplicity we will only focus on the major responsibilities that are of concern for allowing business users to make software themselves. This means that we have to take into account a set of responsibilities of both the side of making software as well as the goals the business has with the software. This gives us the following list:
Triggre consists of two distinct parts: the designer and the builder. The designer is where you make your application and the builder then creates the actual code and publishes the application. The separation of concerns that we are discussing in this article is done inside the designer, where you make your application.
The most important aspect is that Triggre has different environments that you can publish your application to. The first is the Main environment, which is where your application should be published when you want your customers and/or colleagues to work with it. The second is the Lab environment, which can be used for testing. If you have a good idea for a new process for example, you would design it and publish this update to the Lab environment to test it.
And it is this Main and Lab separation that we have leveraged to make sure that all responsibilities can be met. Let’s examine each of the four major responsibilities in detail.
Triggre has built-in security mechanisms that are part of your application when you publish it, no matter what environment. The important aspect here is that user roles and accounts are managed per environment. This means that an account on the Lab environment will not work on your Main environment and vice-versa (unless you create the same account with the same password on both environments, of course). In other words, even if someone has access to the Lab version of your application (e.g. for testing purposes), they cannot use the Main version of the application unless you explicitly give them access.
When programmers write software, technical tests are of vital importance. Not because the programmers aren’t smart or good enough, but simply because it is very hard to write software without defects. Technical testing therefore, greatly influences the quality of the final system. And matters become even harder when multiple software systems have to work together. For example, one system needs to send information to another system and that information has to correctly be handled in all cases. All in all, technical testing encompasses a lot.
Triggre solves the largest part because of it’s builder. The builder creates software from your design, and because our builder has gone through extremely thorough testing, the software that you make with it is very reliable. But that is only part of the technical integrity. The other part is data that is exchanged between systems. Often this means that the systems have to be tested together, for which a testing environment is usually set up, basically a complete copy of the live environment but with test data instead of real data. This way, the communication between systems can be tested.
The Lab environment in Triggre can easily be used to facilitate such testing. All connections with other systems are set up per environment, so you can use different settings for the Lab environment and the Main environment. This means that you can set up the Lab environment to be connected to all the test systems, while the Main environment is connected to all the live systems. Even if you publish the same design on both the Lab and Main environments, these connections will be set up correctly. This greatly lowers the risk of accidentally connecting the wrong systems.
The solution for technical integrity is also a solution for data integrity, or at least a big part of it. Accidentally connecting a test system to a live system is something that happens all to often and causes many IT departments a lot of headaches trying to restore the data to a correct state.
But this is only a part of data integrity. Another issue is a bit more subtle. Consider a system that sends an email to all customers reminding them of any open invoices. This is done automatically each month. While it is a common best practice to never use live data on test systems, this is something that happens all too often. Such as customer email addresses. If the automatic email process runs, it will send an email to those customers in the test system that have an open invoice. But the customer can’t see the difference between a real reminder and a test system reminder!
The solution is not placing the word “TEST” in a big red font on the reminder email, because then this might at one point be copied to the live system and then we have the reversed problem. Instead, Triggre can simply filter all emails the Lab environment sends and send them to a special email address that is set up for testing purposes. This way no customer is ever faced with test information, which can be a major headache for both the IT department and business units.
With some of the major situations that provide problems for IT departments solved, we can look at how Triggre can then increase speed of development. Since Triggre handles those headache cases for you, it is no longer needed to consult the IT department for every small change that a business unit wants to make. The IT department can simply relax, knowing that Triggre handles these situations automatically. And the business unit can very quickly release changes to the application, by publishing to the Lab to do a test and then publishing the same version to Main. All while Triggre makes sure that the application behaves exactly as expected!
At Triggre we are always looking for ways to make things simpler. And we are very proud of being able to allow business users to make software themselves. But that doesn’t mean that we forget about the important aspects of IT that are involved in making and using software. This article is just an overview of the most important aspects that we have taken into account designing and developing Triggre. If you want more, feel free to contact us and ask!
