CRUD, CRUDE and other action-acronyms

Anyone working with data would be familiar with the CRUD acronym – Create, Read, Update, Delete – that describe ‘atomic’-level actions on data. But how well does it work with other asset-types – not just data and other virtual items, but physical things, relationships between people, and relationships to vision, brands and other ‘aspirational assets’? Seems a theme worth exploring – especially for enterprise-architecture, as it more and more breaks out of its old IT-centric box.

First suggestion is that it may be helpful here to use the asset-categories from Enterprise Canvas:

• physical – objects, material ‘things’
• virtual – data, information, ideas, so-called ‘intellectual property’
• relational – linkage between two tangible entities, usually but not necessarily real-people
• aspirational – linkage between a tangible entity (usually a real-person) and a virtual entity (such as a belief, an idea, a brand etc)

Which we could show visually as dimensions in a tetradian layout:

It’s perhaps important to emphasise that most real-world assets are actually composites that incorporate various (and often dynamic) combinations of these asset-dimensions. For example, a printed book is a physical ‘thing’ that also carries information (virtual dimension), that for some person probably carries some of personal meaning (aspirational dimension), and, if the book has been borrowed from someone else, also represents a link between those two people (relational dimension). When working with assets, we need to keep aware of all of the respective dimensions – not solely the most obvious one that’s in focus for the current operations on that asset.

Anyway, let’s start with CRUD. That set of Create, Read, Update, Delete does, at first glance, seem to apply reasonably well to all of the asset-types, as descriptions of actions that we’d typically do with those assets: for example, we create a relationship, we sort-of read it, we’d certainly update it from time to time, and we can sort-of delete. It all sort-of fits: sort-of. But only sort-of. Could we do better than that?

Let’s add the idea of an Exchange action – where we transfer an asset from one person or place to another. This would give us an acronym of CRUDE:

• Create: make a new one of whatever-it-is (or W)
• Read: enquire about the state of W
• Update: make some kind of change to W
• Delete: destroy W
• Exchange:
  • physical (alienable): remove W completely from one place or ownership, into another place or ownership
  • virtual (non-alienable): create a copy of W in the new location and optionally delete (Erase) the original item in the original location
  • relational (person-to-person) and aspirational (person-to-abstract): provide conditions under which an equivalent of W can be created in the new ‘between’-location

Which, again, sort-of works, but only sort-of. It does illustrate that CRUD on its own (without Exchange) probably does make more sense with virtual data, because the exchange operations are non-atomic – in other words, that an exchange is made up of smaller Create, Read and Delete operations. For the other types, though, Exchange is atomic – sort-of. So let’s keep going with this for a while.

When we look at physical things, they’re never actually deleted as such (other than in nuclear operations, which is somewhat of an extreme case…). Instead, they get transformed, often literally from one form to another. Which suggests that for operations on physical things, we might be better to replace CRUD with CRUET:

• Create: make a new instance of something physical
• Read: enquire about the status or condition of something physical, or use it (largely unchanged) in some physical process
• Update: change the condition of the physical object, without changing its fundamental nature or form (for example, reshape, or change some subsidiary-component)
• Exchange: relocate the object or its ownership
• Transform: change the fundamental nature of the physical item (for example, melt it, make an alloy out of it, laminate or bond it with something else, bind it into a larger-scale entity)

And even CRUD itself is becoming a bit misleading for some types of data, or data-operations – especially in big-data and the like. For example, one of the key points in history-log files is that data should not be deleted. Also, increasingly, we also need to treat the relationship between data and its accompanying metadata as part of the overall operation, sometimes with data and metadata as a single unit, sometimes as separated-but-related entities – in other words, the ‘atomic unit’ of data can itself be variable. Which suggests yet another acronym, CRAFT:

• Create: create a new data-item, optionally with associated metadata
• Read: read the data-content, optionally as a unit with its associated metadata
• A (several variants):
  • Amend: change the data-item (equivalent to Update, but at the respective ‘atomic’ level)
  • Attach: link to another data-item
  • Append: incorporate into a larger (usually read-only) data-item
  • Aggregate: merge the data-item into a larger compound data-item, using the respective transforms of that larger item (aggregates-of, trends-of, etc) as part of an ‘atomic-unit’ action
  • Anonymise: detach the data-item from its accompanying metadata prior to or as part of another action
• F (several variants):
  • Find: identify a data-item (with or without its associated metadata) (special case of Read)
  • Fetch: return a data-item (with or without its associated metadata) (special case of Read)
• T 
  (several variants):
  • Transfer: move a data-item (with or without its associated metadata) (atomic-level combination of Read/Fetch, Create and optional Delete)
  • Transform: change the data-item as a single unit (such as a matrix-inversion or coordinate-system transform)
  • Trash: destroy the data-item (with or without its associated metadata) (equivalent to Delete, at the respective ‘atomic’ level)

With relational and aspirational-type assets, there’s really no such thing as a mere Read: any action of any kind on these assets-types inherently changes the asset itself. (We can Read information about a relational-asset, for example, but that’s not the same as a ‘Read’ of the relationship itself.) Which, for those asset-types, suggests yet another action-acronym, CURDLE:

• Create: create a new relationship with a person (relational) and/or abstract (aspirational)
• Update: read and/or maintain the relationship (often just as routine background – equivalent of a ‘ping’ in data-network relationships)
• Refine: take explicit action to change the nature of the relationship (data equivalent – change role or access-rights)
• Drop: take explicit action to end the relationship (equivalent of Delete)
• Lapse: a failure to take action maintain the relationship (i.e. that lack of Update causes an effective Delete)
• Extend: create conditions under which an equivalent relationship can be created for another party (relational equivalent of Exchange)

No particular point I’m aiming to make here, by the way: just thought it might be useful to some folks, is all.