Knowledge and Memory

Once upon a time, people thought of an information model as defining the structure of the stuff you want to remember. Nowadays, this definition is too restrictive: it might possibly be adequate for a system/database designer, but is not adequate for an architect. 

Here are three examples where my knowing and using information is not dependent on my remembering it.

1. I recently helped an SME with its PCI DSS submission. One of the critical points is that they avoid a lot of trouble by NEVER storing their customers' credit card details, merely transmitting these details directly to Barclaycard using a secure device. Clearly the credit card details are stored in various places elsewhere, but our systems don't store them anywhere, not even in cache.

2. When I did my driving test, many years ago, the Highway Code had a table of stopping distances that you were supposed to remember. I decided it would be easier to remember the formula and calculate as required. Obviously that's a design decision.

3. My computer remembers frequently used email addresses. But if I want to get back in touch with someone, I will use Linked-In or Google to find his current email address rather than use the one on my computer which may be out-of-date.

The system/database developer and the architect may use the same patterns for defining an entity or entity type, but they have different agendas, and therefore different success criteria. The architect may be less rigorous about some aspects, and needs to be more rigorous about some other aspects.

The system/database developer may see an entity as "something you need to remember etc.". An architect sees an entity as "something you need to exchange information about". The information model establishes a consistent basis for information exchange between people, systems, services, processes and organizations. I can only talk with you about customers, share your customer data, use your customer-related services, and so on, if either (a) you and I have the same understanding of CUSTOMER or (b) there is a mapping between your notion of CUSTOMER and mine. We can call this semantic interoperability.

This idea of semantic interoperability underlies the Open Group vision of Boundaryless Information Flow.

If you have a private list of customers on your laptop, then you can identify them in any adhoc manner you choose. But if you want to share the list with other people, the identity criteria become important.

So which entity types is the architect is most interested in? Primarily the ones that are referenced in the interfaces between systems and services. There are lots of other things that you might wish to remember, monitor and/or direct, but if they can be encapsulated inside some service or component they have no architectural significance. For example, the business needs to know the prevailing VAT rate; so you build a common VAT routine with the VAT rate hidden inside.