The exception proves the rule. I do not want to argue about this statement but I'd like to understand how exceptions behave and when they show that something is bad. This train of thought will be about principles and processes we are closed around. Certainly the principles mean architecture principles in this portal and the processes are mostly those ones, which you find around the architecture management: orders, development change requests, infrastructure changes and so.

First of all I would clarify that exceptions may prove rules but will break laws! Never forget that our principles are not laws, therefore some exception will not mean the end of the universe. On the other hand, too many exceptions shows another issue, but let me come back to it a bit later.

Exceptions and offences

We defined rules as principles and processes but we have to define exceptions too. Exceptions are only those deviations, which are realised as necessity and approved by principle or process owners! The deviations, which are not "planned" and approved are offences and similar to the normal life situations they should be recompensed. Recompense practice would differ organisation by organisation but "do nothing" results the rules to be meaningless. I would highlight two things here, about exceptions handling:

• The rules must be well-known by the actors. Simple to say that ignorantia non excusat legem but assuming your target is to be successful as architect and delivering results, this legal clause will not bring you closer to your target.
• Each rule either it is a principle or a process must have an owner who is responsible of the approval of exceptions.

It is also useful to have a clear process of exception handling, but the result, the exceptions themselves must be registered to follow-up consequences! There is no bargain here! Now, look after the type of consequences.

Types of consequences

The most usual case about an exception that it will result additional work to do later. Like improper logging is allowed before going to production but it must be fixed later. More risky if OPEX will be affected on longer run, because that is something which usually not recognised.

From business prospective the exception-handled function maybe changed to a normal one and all the data has to be migrated, causing a lot of extra costs and business risks behind.

Parallel to the additional work on the imperfect solution the most important thing is that you as architect must understand the reasons about principle related issues and process owners to do the same about process issues.

Imperfect communication

It may happen that all the rules are good but are not known by their users. This is a simple case, the reponsible people must initiate communication, trainings, exams if necessary to ensure that everyone knows what they have to.

Rules are known but not counted

We have two reason to speak here: wrong rationale about rules and the other is the improper penalisation of deviations. The first part means the you as owners should fix and communicate the rationale of rules and let people use them properly. The other side would mean significant change in the organisation culture. I mean that in most case a well-handled escalation is the penalty what is more then enough, but that assumes your management is committed to the rules affected...

Improper rules

Last but not least you should change the rules if the exceptions shows that they are not OK anymore. A simple measure is: having more than 5 exceptions about a rule in a year, the rule should be changed or fine-tuned. 

Never forget: freedom is made by great rules and this is a basement to maximise ability to change!