My family of five recently moved from our home in California to Germany. After a few months here, one of my sons asked me why in Europe so many of the towns were built in "clumps?" Indeed, we can ride or drive tens of kilometers without seeing a structure, and then suddenly a town with a thousand inhabitants will pop into view, houses and apartments crammed so together that they share roofs and walls in the midst of large green empty spaces.

Why would townsfolk live so clustered, when they could seemingly spread out instead?

The answer to my son's question is that towns in Europe historically have maintained walls. Some towns clustered inside and around central castle fortifications, while others developed series of walls spreading slowly outward like tree rings. For century after century, the real estate inside of a well-fortified wall was valued between highly-desirable and a matter of life and death. And so towns were packed very tightly and built to utilize every cubic meter they could, even going surprisingly vertical for such small footprints on the land.

Today in Europe, we happily do not need town walls and city gates to live successfully--indeed, it might be pointed out that there aren't even generally fences between nations, let alone tiny municipalities. Yet old towns and cities continue to be generally quite dense, and new-built villages mimic the ancient ones.

As an observer, I would guess that there are a few reasons for this that go beyond just plain-old inertia. It turns out that having a densely-built town is excellent for solving a number of problems, including energy efficiency, services and utilities coverage, walkability and public transit effectiveness. Towns in Europe are also naturally more tight-knit communities, and it would seem that there might be a more than incidental relationship between the physical and social architecture.

In essence, a community pattern that began to appear in response to security challenges survives, and even thrives, because of a number of benefits that accrue from the pattern, even though the security challenge and technology used to deal with it has changed drastically over time.

What is Asset-Oriented Data, and why?

With a little imaginative generosity on the part of the reader, we might connect pattern of town construction here to the potential benefits of Asset-Oriented Data.

Asset-Oriented Data is an approach for handling data from a network that includes elements that must be verified and trusted for security and other business purposes. As of this writing, blockchain and distributed contract technology can be applied with rapidly rising effectiveness to fill those purposes.

The application of those technologies leads to data handling requirements and constraints, the shape of which suggest an organizing pattern to best handle those requirements and constraints. We are suggesting to call that pattern Asset-Oriented Data. We'll be writing about AOD (and developing about AOD) quite a bit over the next several months, and we'll do our best to present our ideas about the details of the pattern. Connecting back to our towns analogy, we believe that there are several potential benefits to AOD unrelated to security. Also--true to our metaphor--we believe the pattern might survive and thrive even in the case that our security needs and technologies change or disappear altogether.

What do you mean by Asset?

"Asset" is a word that has been adopted in a number of technical and modeling frameworks, so we probably need to tread carefully with our own definition. In our rubric, an Asset can be defined as a part (or Entity) of an information model whose data is immutably recorded and tracked. While there are some interesting candidate technologies for this tracking activity (ones which we will surely go on and on about later on this blog,) those technologies might be best thought of as an implementation detail at this stage. If we had an ongoing loan of durum pots between two cave-persons--tracked by etched lines on a stone tablet--that loan would be an Asset using our pattern. In case we might happen to have a technology to identify and track the weight of the clay pots on our Internet-of-BronzeAgeThings network, they would be Assets also.

Assets are hardly mysterious; we think of assets all the time in the general world, especially from the viewpoints of business and society. From those perspectives, assets are definable things with tangible value. Indeed, since organizations tend to move first to understand and secure their most valuable assets, the relationship between assets and our "Assets" is nearly tautological, although not identical. For an asset to become an Asset, it has to be uniquely identifiable and capable of generating data, and somebody needs to care enough to make that identification and measurement happen. The Statue of Liberty probably has value as an asset to the residents of New York, but assigning it a digital certificate might be a bit superfluous. (Although...)

A couple of requirements for Assets include their immutable identity and data history. Essentially, our Asset-Oriented Data framework needs to respect these requirements, and take advantage if possible. The data describing and generated by Assets needs to interact with other data from other assets, as well as with calculations and information we have stored about our systems. These interactions involve ideas we call "Composites" and "Contributions," and they are managed as "Transactions." In future posts we'll go into a bit more detail, but for now, we know that the primary focus is on the Assets.

What problems can Asset-Oriented Data solve?

As you can imagine, there is a special focus on making sure that we can determine everything we need to know about an Asset; not just from today's readouts, but from every point from the genesis of the Asset until the current time. It turns out that Blockchain is not just a buzzword technology; it also happens to be very elegant and effective for managing the chain of transactions that alter or deepen our information about an asset.

By focusing on Assets, we also potentially solve a couple of other problems. One is by enabling more robust and accurate data models for complex systems, we make it potentially easier to move new data and new kinds of data into and out of those systems. An Asset-Oriented view may tend to be clearer than more symbolic or semantic approaches toward organizing data, with more obviously lines of authority for parts of the data. We have also noticed that Asset-Oriented models seem to stick more closely to the actual "truth-on-the-ground" due to the tangible nature of Assets, thus potentially avoiding politically-charged squabbles in complex organization modeling.

An Asset-Oriented approach to data also gives us the opportunity to improve and standardize the distribution of user roles so that we can insure that the right people can see the correct parts of a complex system of data and calculations. An Asset can very simply have owners and viewers, whose security access can be handled straightforwardly throughout a system, rather than on a custom case-by-case basis.

Isn't this all a matter of semantics, rather than something new?

Asset-Oriented Data is neither a revolutionary leap forward, nor necessarily something that we are inventing from scratch. We should point out that while this post is not coining the terminology, the term and approach are not broadly-cited or adopted  Similar patterns and approaches have been written up for Engineering asset management organizations (EAMO) and logistics applications, and there is a San Francisco based firm called Element Analytics that mentions Asset-Oriented Data in their blog. Booz Allen Hamilton is doing some interesting work on related topics also. So, not a consensus yet, but we're hardly alone in our interest in the topic.

In the context of Health Care and Life Sciences, our "home industry," we think that a focus on Asset-Oriented Data is a concept whose time might be just about right. There is an increasing level of investigation of blockchain and related technologies as the industry evaluates ways to prevent drug counterfeiting and better reuse clinical data. Too, the sheer number of regulatory agencies, institutions, and consortial have led to a situation where navigating industry data is plagued by the "Babel" of competing standards and frameworks. When we look at the many ways a person seeking treatment can be defined, segmented, and even named across these frameworks, we can see that these definitions are often categorically not Asset-Oriented; they compose many objects, definitions, and limitations, often with a level of semantic precision too narrow to be practical.

We feel that the adoption of Asset-Oriented approaches to data may help simplify this complexity, as well as working to help assemble secure, authentic data alongside other sources into useful, clear models of understanding.

The name of the Blog has AOD in the title, so of course we feel that the approach is worth exploring. Hopefully you, the reader--regardless of your interest level in cryptography and blockchain--will join us as we explore concepts, applications, and even code for Asset-Oriented Data.


Icons made by phatplus from www.flaticon.com licensed by CC 3.0 BY