The Integrity Unit Pattern

Down the years I have advised customers on the use of an Integrity Unit pattern on numerous occasions, yet strangely this incredibly useful pattern seems to remain a best kept secret.

It’s pretty simply really. I define it as: A defined group of capabilities that comply with common policies and common level of trusted behavior. 


In a Service Context, it can be immediately useful to cluster services with common security or rollback capabilities. In an automation unit context it can be used to rubber band units that are tested and certified together. In effect it is an organizing concept that can be overlaid on the technical architecture. Whilst it might be seen as compromising elements of technical integrity – for example the encapsulation of services, in practice it is a sensible level of compromise. The service behaviors remain encapsulated at the individual service level, and indeed permit plug and play at that level, but the overall IU remains the unit of certification and trust. It’s important to note that the IU certification level should address both SLA and behavioral characteristics. 


I’m interested to hear whether others use this as a pattern!