In an earlier post, I identified ISO20022 as a model-driven success story. Here, I give some other examples of model-driven from e-Government and telecommunications. They are not all at the same level of maturity, but the reason why a model-driven approach makes sense is the same.
Testing SEPA Business Rules
May 17th, 2012
SEPA is a new payments system in Europe. Banks and corporates all around Europe must use new ‘SEPA’ message formats for payments and comply with SEPA business rules. One very simple rule, for example, is that you are only allowed to make payments in euros.
A medium-sized bank in Europe might have 20,000 corporate customers. All these corporates must comply with the SEPA business rules.
The bank payments systems are built to ensure that the SEPA business rules are followed. But that’s not enough. There needs to be independent services to test the business rules.
Banks won’t allow corporates to connect to their payments systems until they are confident that the corporates can submit SEPA compliant files. That’s one reason why independent testing of SEPA business rules is necessary.
Corporates need to update their payments systems to produce SEPA compliant files. If the corporate IT team tests early and often, the project finishes earlier and with higher quality. This means lower costs for the corporate. That’s another reason why independent testing of SEPA business rules is necessary.
It is well-known that isolating the business rules within a software system is very good practice. Business rules change often, and isolating the rules makes them easier to maintain. In the case of SEPA, there is very good reason to build services that execute the business rules completely independently of the software systems.
Nomos customers use OCL to capture SEPA business rules, and build independent test services. See some OCL business rules in our post on OCL Examples.