Database Triggers in #ArchiMate — And a Wish

Recently, in a discussion in the ArchiMate LinkedIn Group, Tarun Godhwani started a discussion on modelling the triggers and tables of a database. Of course, one can wonder if it is useful to model these, but in case they are, the question of course becomes “How?”. So, after a hiatus (because I was finishing writing the book Chess and the Art of Enterprise Architecture, which now is available), let’s do a bit of modelling once more.

First, of course, let’s get one thing out of the way: should Tarun model database tables and triggers at all? The answer is: who cares? ArchiMate is detail-level and subject-level neutral. You can have your own idea about what architecture is and what it is not, e.g. you can think it is about principles and guidelines, or that it should never be about details (with your own particular taste of what is detail and what not), but who are you to judge? If these details are at some point important, and you want them in your model, it is your choice.

With that out of the way, the question becomes: “How?”

Those who are familiar with the patterns of Mastering ArchiMate, will remember the use of the key concept `platform’ when modelling in ArchiMate (Sections 7 and 14, for instance). Excel is an example of a platform. Open up Excel and before you, you’ll find a clean sheet of equally sized cells. Whatever business-specific data or logic is handled in Excel, you have to enter yourself. Your formulas and macros are logic, they are programming. Your data is … data. Using the concept of a platform, Excel becomes a platform for business specific IT-logic. Excel is a platform, the spreadsheet realises both data as well as application. If you don’t have the book, see this post and this post (both ArchiMate 1, but you’ll get the idea).

A relational data base system (RDBMS) such as Oracle, PostgreSQL, SQL*Server is not that different. It contains both passive data and logic that runs inside its environment. E.g. you have logic written in PL/SQL in an Oracle RDBMS. Triggers in an Oracle database are nothing more than a small program that is started by the RDBMS every time something changes in a table. Given that you write that trigger as part of your business logic setup, we could start with the basic Mastering ArchiMate idea that such logic should be represented as an Application Component in the application layer.

We start out with a basic example. We have a data base with two tables, a Customer table and a Customer Transaction table. The Customer table has a `trigger’, that it, a piece of logic that is executed every time something changes in that table.

Aside: the fact that an RDBMS calls this a `trigger’ may be confusing. In natural language (and in ArchiMate) a trigger is not the code itself, but the fact that this code ‘is triggered’. That is a subtle difference. An ArchiMate Trigger relation is thus not automatically the best way to represent an Oracle trigger. Another example of Uncle Ludwig‘s statement about `bewitchment by language’.

In this example, the Trigger1 Code (Artifact) is an Artifact, part of the Customer Table (Artifact), which in turn is part of The Database (Artifact), the overall Artifact representing all the bits and bytes of the database. All the relations are Compositions, the first level Compositions are displayed by Nesting.

The Trigger 1 Code (Artifact) is in fact a code Artifact. It Realises an Application Component, the Trigger1 (Application Component). By the way, even if you do not model things down to Artifact level, trying it out often really helps you to see things sharp. This Application Component has behaviour: an Application Function. This — in ArchiMate — is what the component does, its behaviour. It stands for what the Application Component does, which is something with the data in the database. To access that data from an Application Function, we need to model its representation at the application layer: the Data Object. We need two: the Customer (Data Object), realised by the Customer Table (Artifact), and the Customer Transaction (Data Object), realised by the Customer Transaction Table (Artifact). When we have these Data Objects, we can model that the [Trigger 1] Update Customer Transaction (Application Function) Accesses both (reads one and writes the other).

What this shows is that at the infrastructure layer, a bit is a bit, data is data. But data can both be acted-upon (passive) and actor (logic, active). That same data can be both. For another use of that aspect, see this post.

Now, what is left is the actual triggering. When the table changes, the RDBMS system kicks off execution of that code. So, it is the RDBMS system that Triggers (ArchiMate) the behaviour of the data base table trigger (RDBMS). To show that, we can add the RDBMS system as System Software and model its behaviour, in the example The RDBMS behaviour (Infrastructure Function). Note: I’m adding a lot of detail here, that doesn’t mean it ia always a good idea to add that detail (it isn’t), but I’m just explaining something and in that case, a little detail helps. This behaviour actually Triggers (ArchiMate) the RDBMS trigger (RDBMS logic). In ArchiMate, I would like to draw a Trigger relation from one to the other, but — and here’s the snag — this is not allowed in ArchiMate. Hence the colour red in the view above.

(I added also that the behaviour in the application layer uses the RDBMS runtime services (Infrastructure Service), just to be complete.)

So, there is a problem. ArchiMate does not allow me to have application behaviour be Triggered by infrastructure behaviour. In fact, it does not allow cross-layer Triggering and Flowing at all. Personally, I think this is an omission. I think in the real world of Business-IT landscapes, applications may trigger business processes and the other way around. I think even infrastructure functions may trigger all over the place etc. So, we might say, this is another one for my ArchiMate Wish List.

So, can we do this within ArchiMate’s limitations? If we want the RDBMS update mechanism trigger the Trigger 1 code, both need to be modeled at the same layer. Given that we probably have applications using the RDBMS too, we might not want to model everything at the application layer (though see Section 18.3 A completely different platform approach of Mastering ArchiMate for an alternative). So, we have to model the Trigger 1 code’s behaviour at the infrastructure level. This might look like this:

Here, our Trigger1 Code (Artifact) realises System Software. That is not quite what System Software is meant for, but we have no choice. Now we can model the real triggering behaviour of the RDBMS system. I’ve added two applications that use this database. They are not aware of the triggering, it happens below the waterline. But the effect is that information flows from one application to another.

(For completeness, I’ve added the Used-By’s between the RDBMS Infrastructure Service and the Application Functions.)

This is fully modelled out, with a lot of detail. The database Trigger appears as three elements (the code Artifact, the System Software and the Infrastructure Function). Four, if you count the explicit appearance of the RDBMS’s triggering functionality. I think you will not always need that unless you use ArchiMate for software modelling and for that it  might not be the best tool.

The whole thing can be minimised in many ways. ArchiMate is a language/grammar, which means that there are many, many ways to model the same thing. Here is one:

Both Data Objects represent the tables and the Application Component represents the Trigger. Here you cannot see that Trigger 1 is part of the Customer table. In a sense, that is acceptable, as this is true on the infrastructure level (bytes), but the application layer is an abstraction that doesn’t by definition show all the dependencies that exist at the lower level.