James Governor's Monkchips

Why Applications Are Like Fish and Data is Like Wine

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

wine rack

Only one improves with age. With apologies to the originator of the phrase – “Hardware is like fish, operating systems are like wine.”

What am I talking about? Processes change, and need to change. Baking data into the application is a bad idea because the data can’t then be extended in useful, and “unexpected ways”. But not expecting corporate data to be used in new ways is kind of like not expecting the Spanish Inquisition. But… “NOBODY expects the Spanish Inquisition! Amongst our weaponry are such diverse elements as: fear, surprise, ruthless efficiency, an almost fanatical devotion to the Pope.” (sounds like Enterprise Architecture to me).

I didn’t go quiet Dennis, I just didn’t post this. So if enterprise apps are so cool- why are SAP, IBM and Oracle all competing in the Master Data Management Space? If enterprise apps cut the mustard why is ETL and datawarehousing still a strong market. If the app matters more than the tax algorithms why is Oracle bothering to sue SAP?

I actually really don’t like the bracketing of data extensibility as The Intel Inside. In fact I hate that way of articulating it. Because to my mind Intel may be a standard, but its not an open standard (well it wasn’t until AMD started to really nail it).

Of course process matters but its better to crucial to invest in having the right data. Arguably the pitch SAP traditionally made was not that it would sell you a suite of apps, but rather than it would bring all your corporate data into one place so that you can make business decisions based on facts rather than suppositions. SAP’s story today still talks clearly to this corporate data standardisation.

Information wants to be free. the Intel Inside slogan came from a monolith/island era. That’s not where we’re going next.

In this industry we tend to focus on the need to separate data from presentation, but of course we also try and enforce a separation beween data and business logic. Why? Because business logic quickly begins to smell. From a pace layering perspective.. oh wait, y’all probably don’t know what pace layering is. Its this cool idea from Stewart Brand, explained here (by Donna Maurer)

“Complex systems can be decomposed into multiple layers, where the layers change at different rates. The “fast layers” learn, absorb shocks and get attention; the “slow layers” remember, constrain and have power. One of the implications of this model is that information architects can do what they have always done–slow, deep, rich work; while tagging can spin madly on the surface. If it is worth keeping, it will seep down into the lower layers.”

Which talks pretty well to my point. Has anyone formally mapped Model-View-Controller to pace layering? I doubt it. But if we look at business architectures data has the longest shelf life, followed by business logic, followed by presentation. Sometimes the data stays the same but the data model changes, another layer. Presentation goes off even faster than fish [ed: what does go off faster than fish, or is this metaphor b0rked? Why do shops keep investing in mainframes? Because they are investing in data. Why do people keep buying apps? Because their old ones went off.

Just to abuse the metaphor a little bit more there are some interesting things to note about wine. Not all wine is designed to be kept. Not all data increases in value over time. If organisations spent more time working out what wine was worth keeping, and which had turned to vinegar, they would be a lot better off. Retain the data that has value. In some applications- market risk for example-the only reason to keep historical data is regulatory requirements. Operational risk on the other hand needs to more cognizant of trending. For market data risk freshness matters.

Dennis says:

“To me, data is valuable for understanding what is going on inside a process. The data may suggest an alternative course of action. But that in itself implies the application of process steps and will have been the result of pre-presentation filtering and refining, via business processes.”

. The process provides a context for the data, sure, but could the process or application be different? Regardless of whether or not corporate data has a life outside the process, which of course i think it does, it would still pay organisations to really think through their data, and what its for. We don’t want it all in the cellar, after all. Sometimes you need a drink. Anyway- what do you all think?

fish

disclaimers: IBM is a client, SAP soon will be, and Oracle we’re working on
credits: wine picture courtesy of avixyz on Flickr. fish courtesy of midquel.

21 comments

  1. “But if we look at business architectures data has the longest shelf life, followed by business logic, followed by presentation.”

    This is vey much true !! Having worked with Canada Customs, the data I presented to thier Customs Platform has to be the same if audited within the 7th year.. that is if asked for Y1 Data.

    however Y2 Data elements may slightly change due to mandates which trigger Data elements/process changes.. however, if I were asked to present Y1 data then it has to be identical to what was tranmistted to customs platform, we cant present Y2 type data elements, because it will not match thier DB, even though 100% compliance was ascertained at the time of transmission during Y2

    Data Harversting/ rentention is the core of a business.. data is the wine.. process is the fish .. and the presention is the “bread” ..

  2. I swore, the next time, I heard “information wants to be free”, I was going to pop my cork, and you won the contest.

    Of course, information wants to be free. So does livestock. That’s why Joseph Glidden’s invention of barbed wire transformed the west. It made it possible for the owners of livestock to protect their property rights.

    So let’s look at another aphorism, one I’ve been preaching since the 1980s, and maybe it will catch on pretty soon.

    Hardware is free.
    Software is expensive.
    Data is priceless.
    Customers are everything.

    As Paul and Art sang, “Preserve your memories, they’re all that’s left you.” Teenagers want to be free, too, but if you aren’t careful about what you’re doing, instead of enjoying your “empty nest” years, you’re going to spend them raising your grandchildren.

  3. OK James, I’ll take the bait.

    MDM is important because the companies you cite are all trying to tie data together an…dare I say…normalise it. OK – wrong expression but basically they need get rid of the redundancy across multiple applications and instances of those applications. The perceived wisdom is to get it sorted out using meta data as the method.

    ETL and DW is important for static data but modern thinking knows it’s needed as the bse for data in motion.

    Come on – you know why Oracle is suing SAP. It woke up to the the fact TN has taken not just monkey nuts and it rests its business model for PSFT/SEBL/JDEC acquisitions on those 22% maintenance fees. Nowt to do with data.

  4. James, excellent post!

    Process is where data can be captured, application is where logic is applied to the data.

    Processes changes, and they should – and at that stage data can be raw just reflecting the real facts.

    The application of logic onto the data does not only change all the time, it should be allowed to be different for each user. That is why I whip out my HP 12 C every time I see some annual accounts!

    Rip apart process and application – “applications” should be mere “templates” of logic, customisable of course.

    Keep data in raw form, only apply (any) logic when needed – don’t mess up for the others!

    (Your “middleware” clients may not like that idea though, making a living from extracting some usefulness from manipulated data as they are…)

  5. Dear James,

    Good thought provoking post. You bring up a good point about the temporal nature of information and data. I think it is important that we don’t rush in and delete data as it could one day give us some insight as to what happened on a particular day in the life of that object, person, place, etc. I am accused of being a packrat, but I have proven over and over again that data is precious and we should always find ways to preserve it and make as much of it as possible available to us.

    I think it is easier to find a place to put the data as opposed to finding data to delete. Every bit tells a story, and besides five minutes after you delete the file you will want it back, kind of a Murphy’s Law thing.

    Cheers,
    Tom West
    Blog: http://www.ttoolboxes.ca/blog

  6. […] 18th, 2007 · No Comments James  recently posted about wine and fish.   Thoughtful stuff indeed, and made for a good lunchtime discussion at St Johns […]

  7. Ah, data like wine… Love it James. That is bound to mean that information is like cognac: distilled, aged, of higher value, with longer shelf life, … — Jeff

  8. Excellent! Love the pace layering piece – that is the first I’ve seen it.

    There is an interesting side topic about information being harder to make sense of as it gets older (difficult to stretch the analogy for this, so I won’t even try!). the more removed data gets from the processes and applications that created it, the less context you have. Particularly since those pesky applications and proceses are constantly changing and “absorbing shock”. Over time, new data does not line up comparatively with old data, making it difficult to understand in context. This is where metadata comes into play – a key to preserving context over time.

  9. Great post and metaphor. But I think the Stewart Brand quote should go to Karl Fast or Grant Campbell from this talk at last year’s IA Summit: http://www.iasummit.org/2006/conferencedescrip.htm#164

  10. I must say this made for a very interesting reading. I agree data is like that of wine. Data in a sense either ages, upgrades or is thrown out.

    Applications in a way are like fish:

    Expensive, cheap or look bad.

  11. […] Governor about “Why Applications Are Like Fish and Data is Like Wine” This entry was written by h3lge, posted on November 22, 2008 at 5:44 pm, filed under Tidbits. […]

  12. […] can work with them. That is why FOX and wikimedia have recently made major purchases of Sun gear. Data is like wine, Apps are like fish. I was very impressed to see this new Sun data erasure service – I can imagine some financial […]

  13. […] apologies to Chuck Hollis at EMC and James Governor at RedMonk I decided to take a crack at this whole “Why Applications are like fish and Data […]

  14. […] apologies to Chuck Hollis at EMC and James Governor at RedMonk I decided to take a crack at this whole “Why Applications are like fish and Data […]

  15. […] to A C Censi in the comments the original quote was from James Governor’s Monkchips – Why Applications Are Like Fish and Data is Like Wine Comments […]

  16. […] – Andy Todd ? James Governor […]

  17. […] Applications Are Like Fish and Data is Like Wine […]

  18. […] In a lot of ways I think this work illustrates James Governor’s adage: […]

  19. […] is said to age like wine – meaning the longer it’s kept, the more insights you’ll be able to glean from […]

  20. […] Data is said to age like wine—meaning the longer it’s kept, the more insights you’ll be able to glean from it. While this may be true for some forms of data, this analogy doesn’t apply to all situations. Many types of data have a limited shelf-life where their value can erode with time—in some cases, very quickly. For example, in retail it’s better to know which products are out-of-stock in terms of seconds or minutes rather than days or weeks. The more quickly a retailer can restock its products, the faster it can return to generating product sales. […]

  21. […] We do not refer to any of this being ‘rules as code’, mostly because Parliament doesn’t have a governing ruleset, but also because code may be fish, and we prefer the fine wine of data. […]

Leave a Reply to /pd Cancel reply

Your email address will not be published. Required fields are marked *