All Posts in Architecture

Enterprise Technical Architecture Management

|In: Architecture|Last Updated:

Not that it’s relevant to anything important, but I stopped admiring people who “speak truth to power” quite some time back.

It isn’t that I’m against the practice. It’s that I long ago read enough about epistemology (roughly three medium-length paragraphs) to understand that none of us have access to “the truth.” As we don’t have access to it we sure shouldn’t take it upon ourselves to share it.

Understand, I do have some experience in this game, as when I debated Gartner about their total cost of ownership metric: I spoke “truth” (my opinion) to power (Gartner being a force in the industry.

But I wasn’t, in truth, speaking truth to power at all. The best I could and can claim was that I provided my honest opinion, based on the best evidence, logic, and withering ridicule I could come up with.

None of us know the truth about anything. But on the other hand we’re all capable of honesty – a more advisable because less arrogant alternative to pretending to truth-telling.

None of which has anything to do with this week’s subject, which begins with my new favorite word, polysemy, which is when different words have closely overlapping meanings. Drawing on the subjects of recent weeks – integration and data warehouses in particular – this week’s polysemes are “system of record” and “source of truth.”

There are those in technical architecture circles who use these terms interchangeably, as if they were the same thing.

But like the difference between truth and honesty, systems of record and sources of truth are distinct and different concepts: a system of record is a matter of technical choice, while a source of truth is a matter of design.

Imagine your applications portfolio includes three different applications that manage customer information – maybe a CRM suite, an ERP suite, and a third-party database marketing company. Your job: make it easy for a sales representative to find a customer’s primary business address. It isn’t easy now because often the three applications contain different addresses for each customer.

What you need is a more-or-less arbitrary decision as to which of the three applications will, from this point forward, contains the address that will be used. That application is the “system of record” – the application developers will consult whenever they need a customer address.

Compare that to a source of truth. A source of truth is an integration point, often an API, possibly an “operational data store, enterprise service bus connector, or for different uses a data warehouse. What makes a source of truth invaluable is that someone has constructed a single software locale that knows, for each chunk of information, which application is its system of record and … and this is the crux of the biscuit … how to reconcile any discrepancies.

Systems of record are concrete. Sources of truth are abstractions.

To put a dot on it, anyone wanting to make use of corporate data must have a map that identifies, for each piece, which application is the system of record for that data.

Or else they need to ignore the individual applications and, for each piece of data they want they should consult the sources of truth.

Bob’s last word: When it comes to IT, understanding and making use of sources of truth in lieu of systems of record is a handy way to get work done faster and more accurately. But the same thought process can play out in non-technical situations.

Each of us has sources of truth for information we need. These sources take the time to collect and summarize information so we don’t have to. Maybe Gartner is one of them (good luck!). Greg and I hope KJR serves this purpose for you in your professional life. Microsoft wants you to start relying on Copilot, encouraging you to obey our future robotic overlords.

Regardless, given the flood of information available to us should we need any of it, perhaps our biggest challenge will be vetting our summarizers. For the ones we choose the minimum standard can’t be truth. The raw sources are, after all, in the cloud.

And the internet doesn’t trade in truth.

Now in CIO.com: Want more along these lines? Read Bob’s newest CIO Survival Guide post, “CIO risk-taking 101: Playing it safe isn’t safe”, about how organizations often get risk-taking wrong.

Comments

|In: Architecture|Last Updated:

There is an important question that is often requested, but not planned for when you are designing reports, dashboards, or other Information products.

It is a simple question to ask, and an easy one to answer, but data itself won’t support these questions unless they are designed in from the beginning-

“Where?”

At the risk of sounding like something that is too good to be true, by planning ahead on your data warehouse schema, and anticipating this question, you can get a lot of bang for the buck.

The “Where?” question could apply to everything from warehouse location for inventory, customer addresses, technician dispatching, critical infrastructure, or utility network connections.

To each of these examples, there are different kinds of “Where?”, ranging from X/Y/Z coordinates (for a warehouse) to an address (for shipping), to Longitude/Latitude (for critical infrastructure), or drive time (for technician dispatching).

The costs of acquiring spatial data are at an all-time low, and more or less free in many cases.  When you look around at the data sources, and the sensors embedded in so many devices now, the data is there, ready for you to collect.

Similarly, the costs of storing spatial data are pretty much free now.  You just need to spatially enable the storage tools, aka, the tables, views, and Data lakes/warehouses/silos.     In many cases, this is a configuration, not a customization, or at most a few more fields to a table.

Taking what we discussed last week, of beginning with the end in mind, it would help to anticipate how we might think about the “Where?” question.   We could be anticipating a map display (kind of obvious), or some sort of analysis, such as relationships or distances between any number of customers or suppliers.

Tying this all together, the trick is to collect data that is fit for purpose.

In order to create a point on a map, we need some sort of Geo-reference—the X/Y/Z coordinates.  This can be collected directly from something like a GPS, or it can be created by a (built in or standalone) Geo-Coding engine. Geo-coding is some sort of translation between where we think of something (a delivery address being a great example) to a coordinate (a Longitude/Latitude, displayed on screen).  In a building, these X/Y/Z coordinates would likely be related to a room, shelf or bin.

To understand the relationships between two or more items/people/locations, it may be necessary to collect more information, such as the network they connect to, including the rules of the network.   One relationship people immediately gravitate towards is Proximity— knowing the distance, direction or measurable time between two objects.  One long time reader of KJR (Hi Doug!) uses RFID based “finding” devices to look for routine medical supplies that might get lost.

Accuracy is also an important part of the fit for purpose discussion.  The right rule for most applications is “accurate enough to find it”.   For example, in many applications, it is important that the data can help you find the house on the right side of the street, but it may not matter if you have survey grade accuracy to the front door.   Don’t ask for precision that you don’t need.  Use only the minimum precision required that helps you meet the needs of your users.

Finally, the “Where?” question is an invitation for creative visualization.  Any application that returns some sort of text answer to this question is going to frustrate users.  While creating a map is one outcome, it doesn’t end there.  In Warehouse Management, the hot thing is “Pick to Light”, where a small device blinks, and guides staff to the exact bin or location containing the right inventory.   Simple database or warehouse enablement for spatial data answers a lot of answers, and helps you bring a lot more options to solve problems for colleagues.

Only now, this is easier than ever.

Comments