Could We Just Build This Ourselves?

Every organisation with a capable software team asks this, and rightly so: "We could build this ourselves, why buy it?" Our answer has never been "you cannot". This article lists the items that genuinely belong in that decision. In some organisations the answer will be "build it", and we say so plainly.

You Can Build It, That Is Not the Question

A bank's or a large enterprise's software team can build this tool. Several large organisations have done exactly that and run their own internal change management platform. Some of these run more than a hundred validation rules, grade them into levels and integrate with the corporate ticketing system. So the question is not one of capability.

The real question is this: is this your core business, and are you prepared to maintain it for the next five years?

The Visible Work: A Form and an Approval Step

The first estimate usually looks like this: a request form, a field to paste the script into, an approval step, an execute button and a log table. That is two to three months of work, and it genuinely is. The problem is not that the estimate is wrong; it is that the estimate covers only the visible part.

The Invisible Work: Seven Items

1. Parsing with a real grammar

The easy way to write rules is text search and regular expressions. It does not work. A DELETE inside a comment looks the same as a real DELETE. A table name inside a string literal is mistaken for a real one. Subqueries, common table expressions, joins, dynamic SQL: all of them fool text matching. Reliable rules need the syntax tree of the statement, and that means a separate parser per database engine. If you govern three engines, you have taken on the maintenance of three parsers.

2. Attaching a finding to its object

Saying "this script contains an unqualified update" is not enough. You have to say which table, because that is how the match against your critical object list is made. In a multi statement script, attaching every finding to its own object is a separate layer built on top of the parser.

3. Freezing the rule as it stood that day

Rule sets change. Explaining a decision made six months ago with today's rule is misleading and an auditor will not accept it. A frozen copy of the rule set in force that day has to sit next to the decision. This is a design decision that belongs in the data model from the start; adding it later does not rescue past records.

4. A tamper evident audit trail

A log table is not an audit trail. The auditor says "prove this record was not altered". As long as the team that keeps the record has database privileges, the table alone cannot prove it. A keyed chain, where the key is stored, what happens to the chain when the key rotates, a sealed second copy in a separate database and a way to verify all of it: each is a separate design problem. The most common mistake is building an unkeyed digest chain; anyone who can write to the database can recompute it, so it proves nothing.

5. Sensitive data detection and masking

If you also want to govern reading from production, the work grows. You cannot decide whether a column is sensitive by its name alone; the content has to be validated. Is the identity number structurally valid, does the card number satisfy its check digit, is the account number well formed. Then come the masking format, partial masking, an extra approval for unmasked requests, how the result is delivered, encrypting the delivery package and how the password reaches the recipient. That is a product on its own.

6. Generating the rollback script

For schema and procedure changes, a rollback script can be generated from the object's current definition on the server. That requires fetching definitions from the target, knowing each engine's metadata layout and emitting correct statement forms. For data changing statements a full rollback cannot be generated, and the design has to say so honestly. A rollback button that gives false confidence is more dangerous than none at all.

7. Authorisation, roles and separation of duties

Can an approver execute their own request? Can they approve it? Can a senior role skip a step that a junior role was supposed to close? Which steps may be skipped in an emergency and how is a skipped step recorded? Each of these needs a default, a per server exception and an audit record. Most importantly: authorisation has to be enforced on the server rather than in the interface, and revoking a permission has to take effect immediately.

The Real Cost Is Not Building It, It Is Keeping It Alive

The first version of an in-house tool usually comes out well. The trouble starts in year three:

• The database engine moves to a new version and the parser does not recognise the new syntax.
• One of the two people who wrote it leaves, the other moves to another project.
• A new regulation arrives and the report format has to change; there is a queue of other work.
• Because it has become an internal product, it needs its own security review, its own release management and its own documentation.
• A second database engine comes into scope and the work starts over.

The number that belongs in the decision is not the initial build cost but the three year total cost of ownership: development, maintenance, the risk of knowledge concentrating in two people, security review and documentation.

Two Questions an Auditor Asks an In-House Tool

An internally built governance tool carries one disadvantage in an audit compared with an independent product, and it is worth knowing about.

First question: "Is the team that produces these records the same team that runs the system holding them?" With an in-house tool the answer is usually yes. The team that wrote the tool can also reach its database. Separation of duties is under real strain right there. The answer is protecting the record cryptographically and preferably in a separate place, which takes you back to item four above.

Second question: "Is there a record of the rules being changed?" Weakening a control is itself an event and has to be recorded. If the rule set lives in a configuration table and changes to that table leave no trace, the strength of the control cannot be measured.

When Building It Yourself Is the Right Call

Let us be honest. In these three cases building it yourself is a reasonable decision:

• You use a single database engine and there is almost no work outside planned schema changes. A narrow scope means a narrow cost.
• You already run an internal delivery platform and this is a natural module of it. That is a component added to an existing product, not a product from scratch.
• Your corporate process is so specific that no packaged product can model it. This is rare but real.

By contrast, a packaged product comes out clearly cheaper in these three cases: you run more than one database engine, you also want to govern reading from production, and you are subject to regulatory audit.

Five Questions Before You Decide

• How many database engines will it cover, and who will maintain a separate parser for each?
• Is reading from production in scope? If so, will you also build the masking and delivery side?
• How will you prove the audit record was not altered, independently of the team that keeps it?
• What happens if the two people who built it leave within a year?
• Have you put the three year total cost on paper, or are you only discussing how long the first version takes?

If you can answer all five comfortably, build it. If two of them have no answer, at least run the comparison.