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.
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.
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.