Sunday, June 21, 2009

Real Life Caching

The thought behind this post comes from the rich pageant of daily life with Madame. Yesterday morning we were discussing when she should visit her mother (a sprightly 96 year old who lives about 1,000 miles from us). So it was a matter of looking for decent airfares, timing the visit to coincide with my absence, minimizing the flight time (it is always requires a change in either Chicago or Detroit).. What you may wonder is relevant about this in architecture. It all has to deal with the location of the process, and the location of some of the data required to complete the process.

The computer was in her home office – up a flight of stairs from the main living areas of the house. Her purse was down in the kitchen. She had dutifully retrieved her credit card from her purse prior to starting the transaction (pre-cached the data), and carried it upstairs. Because of where I work, I almost always try to ensure that bookings are made on Travelocity.com – keep all possible revenue in the family.

So the process goes fairly smoothly – Madame is using my Travelocity account to make the booking (easier than creating a new one at that moment). Of course this would be a security violation, so let's say, I was acting as the operator for this purpose! We get all the way through the process (well almost) when we realize that her frequent flier number is not in the account anywhere. Also that data has not been cached anywhere (not in her head, not by bringing the physical card to the point where the transaction is being executed.) So an IO request is issued – resulting in the slow IO processor (me), walking from her office, downstairs to her purse, finding it, and returning the whole purse. Why the whole purse you ask? One reason is privacy – it is hers and I don't access its contents without permission (PII rules). Second is that I don't know what other esoterica might be needed, so I want to save my weary legs – and not have to make another trip to the purse data store (which by the way is a heap storage model).

The IO request is completed. Madame parses the purse data structure until she finds the relevant card, she then types in the number and completes the transaction.

As always with these stories there are a couple of questions:

  • Would it have been more sensible for her to bring the whole purse data structure instead of just caching the credit card? In hindsight, yes. But how would she make that determination. The stairs are steep and it is a long way. The purse could be heavy (too much payload) and unwieldy.
  • Should I have brought the whole purse or just the needed card, or better still a lightweight interpretation of the number (she didn't need all of the information on the frequent flier card)?
  • Does it make sense to cache the whole content of her purse in any room where she might execute transactions? After all with wi-fi that could be anywhere, including outside the firewall (i.e. in the garden or yard)? What about security? The gardeners and the maids (would that we were so lucky!) would then have access to the cached data. That could be troublesome.
  • Is the network transport reliable? Could I have been distracted in the bringing of the data back upstairs – through answering the telephone, needing some refreshment prior to attacking the stairs, pure absent-mindedness or what?

Of course the point isn't to think about home processes much – we will do things that seem expedient without a whole lot of thought. But when designing systems, we have to think quite carefully about these kinds of things. By putting them in this sort of context, it can sometimes help to think things through.

And, oh yes, this is not really architecture – it is design. However, there are patterns that emerge, and they become important aspects of architecture.

Friday, June 5, 2009

Architecture on the Product Side

In an previous post, I wrote about the difference between the application of technology to the building of products, vs the application of technology in running the business. They are pretty different animals, if nothing else because of the way they are deployed.

So, I get to wonder what the head of architecture for the product side of one of these companies does. I can take one of the Architecture frameworks and apply it – but to what? Individual products (each with own P&L, development teams, practices, degrees of product maturity)? Across the whole product organization itself, so that we can begin to standardize/use same services across the product suites. When the products can be deployed in several ways (in house operated and sold as ASP), on-premise at the customer, on=premise hosted by one customer and used by another,…So as the products are deployed we have to think about the how the platform affinities work.

The customers want to customize the way the work is performed using the products/services that they have bought. So somehow we have to think of ripping the process logic out of fixed applications.

There are cross product dependencies as well. So sometimes we have to rip code out of one product and insert it into another.

Oh and the up time for these products must be in the 99.999 range – the products handle very time/life critical activities.

And finally a legacy that dates back a long way – pretty much bulletproof, but definitely has its own way of presenting itself to the world.

This Architect's world feels very different to me than the "traditional" EA world where the need to build for wide deployment and customization is less important.

Any thoughts anyone?

C