More Fun(?) with words

Sometimes the TwitterSphere is just too constraining to get a thought across fully. I naively posted a question about the definition of "Application" – to see what would come back. It turned into a delightfully healthy discussion with some twists and turns along the way. It isn't every day that Duns Scotus and Humpty Dumpty show up in the same post – at least not unless Richard Veryard (@richardveryard) is involved!

So a good question is "Why do you want to define application?" My answer is actually that I don't want to DEFINE it, I just want to know what people might mean when they bandy the term about. As Nigel Green (@taotwit) and I chatted this morning at length on this and other topics, the recurring theme was, "I'd like a quick way to parse a conversation." In other words, when I am talking to someone and trying to understand what it is they want (requirements anyone?) I would like to know their frame of reference so that we can communicate.

How often have we heard requirements that say things like, "I want a database that …." Actually, I suspect it isn't usually the database that the requestor wants, it is some way of manipulating the data with a purpose in mind. Maybe, even, an application (gasp).

So just as in a previous post where I was wondering about type/instance nomenclature, so here I am wondering about other opportunities for miscommunication.

Richard makes an interesting point, "@seabird20 If something persistently escapes or evades precision, then maybe it was the wrong concept in the first place." That may well be true, but we can't unbreak the egg. The words are out there, their meanings are many, we can't (and shouldn't) attempt to unify the vocabulary (even the Académie francaise has stopped trying to keep French completely pure – le weekend anyone?)

So this is not a cry for definition and ontology for its own sake. It is a means to collect lots of definitions so we can understand each other better. Of course, the more we share context, the more "shorthand" we can use to express ourselves – because we have either tacitly or explicitly agreed to the vocabulary. It is in the "getting to know you" stages where shared context and trust are established. It is at those early stages where slight misunderstandings can blossom into full-fledged disagreements and a loss of opportunity to trust.

Process Improvement and the Chaat Cafe

My favorite Indian restaurant is a 20 minute walk from my house. It has the most wonderful Indian snacks/appetizers and of course kulfi. It is also a thoroughly confusing place. I will try to describe the changes in process that I have seen over the last 18 months – since it opened.

First, some background. It is set up with three major "stations" where things are cooked. The flat top where the dosas, parathas and other flatbread dishes are prepared. The drink area (lassis, etc.) and the chaat area (samosa, golgappe, etc.)

Version 1.

You wander into the restaurant, decide what you are going to have and fill out a 2 part form in front of the station. Hand it to the cook. The cook makes the dish and when ready calls out over the speakers. You go and collect it from the counter. When time to pay, you take the white parts (tops) of the 2 part form to the register. They total up the bill, you pay and leave. Problem – this didn't scale well because we could never hear the loudspeaker announcements. Well we could hear that there was an announcement, but not what was being said.

First Process Improvement

Numbers were attached to each table. Your table number was required to be placed on the bottom of the form. Problem then was you had to select your table prior to placing an order. How do you keep it while ordering? Can someone else grab it? Much chaos ensued. Advantage was that the loudspeaker announcer just had to call the table number. You still handed your forms to the cooks, etc. There is still the possibility that unscrupulous diners would forget the white chits or (as I have to admit to having done) throwing one away by mistake when clearing away the dishes. So my guess is that auditing showed some yellow chits (what the cooks did) which didn't have matching pair white chits. And no way of running down the offenders until much too late. Everyone seems to pay cash there!

Second Process Improvement

Technology was introduced! Central order taking was introduced. So now, the restaurant has done away with the need to grab a table before creating an order. It has introduced a central ordering location. The forms, however are essentially the same and are not at the central location. The forms are still in front of the cooking stations. So you fill the form out at the cooking station and carry it to the central ordering facility. There (if you have not already been given one) you are given a vibrating pager. Presumably local in-restaurant network only. This is similar to the pagers often used in restaurants to tell you when your table is ready. When you place the order (on the 2 part form) you enter the number of the pager device. Now when each part of your order is ready, the pager device goes off. As you collect the dish, you need to stop by central ordering, so they can turn the thing off. If you fail to do that, it keeps vibrating and you have no indication when another part of your order is ready. Also, unknown to the first time user, the device will be used for computing the bill, so if you are looking for individual receipts, you need one vibrator each.

When you go to pay, you hand your vibrator to the checkout clerk. This automatically brings up the bill. I haven't seen the behind the scenes magic that does this yet. They also have an accordion file into which they put all the yellow copies into the slot numbered with the same number as the vibrating pager. You pay and leave…

So what you may ask?

This is an interesting exercise in changing processes and system state knowledge to adapt to conditions. In the first 2 iterations all the state was pushed to the diners (white copies) and that state information was used for "billing" and "payments". In the final case we see an audit database (the accordion file) and a shared key (vibrator number and slot number).

So by looking at what was causing trouble (what Policies and Values were not being dealt with correctly), the store restaurant owner instituted quite significant changes that make the process of ordering/getting the food/eating it/paying for it (the order to burp process) a great deal more streamlined. Very little automation needed, almost no effect on the primary Value of the place – "Somewhere that serves high quality, tasty, vegetarian chaat with a flavor of home."

It has been fun to watch this humble restaurant put so much thought and effort into helping itself run smoothly and maintain a great connection with its customers. Would that we in IT be as effective.

The trials of pedantry – aka type/instance confusion and other adventures in meaning

"I had Taco Bell for lunch today". I keep hearing that usage from co-workers, students, random people in passing. At some level it makes complete sense – I get it that the person speaking ate at food obtained at a Taco Bell "restaurant" (why anyone would do that is beyond the scope of this posting). However, compare and contrast that with, "I had salad for lunch today." The second describes the food (pretty generically), the first describes the place where the food came from.

Now imagine you don't know that Taco Bell is a food chain, and maybe you are not doing analysis in your primary language). What assumption would you make about the statement, "I had Taco Bell for lunch today?" I think the first reaction would be that "Taco Bell" would be classified as a kind of food, not a kind of place. And Because that is a first impression, it would set a context that could be hard to shake.

As an aside, while working in France a couple of years back, the nearby Pizza Joint was called "Speedy Rabbit". When a project team member suggested we have "Speedy rabbit" for a working dinner – and that I, being the project manager and therefore an impediment to progress should go and fetch it. Since in that part of France, rabbit is often served, and often really tasty, I had visions of having to chase this thing down in my underpowered rental car. Turns out it was a pizza joint and that it was a simple pickup. Not a rabbit in sight. Oh well.

As architects/analysts we often find words or phrases that are used in surprising ways (idiomatically one might say if one were being charitable). The insiders to the group get it, understand the meaning, know when the statement refers to Taco Bell the company HQ, the Taco Bell on the corner, the specific lunch (without knowing the actual details of the meal). So we have to be careful when we are faced with words like "office" or "transaction". We need to know the context that the speaker is coming from and to be able to decouple our understanding of the word from the understanding that the speaker means.

How often have you heard statements like "we have 7 transactions in our banking system"? My first reaction is, "wow those must be huge transactions" or this bank is going under soon. And then I realize that of course it is transaction types or kinds of transactions, not the instances. Once again context rules. If you ask the question, "How many transactions did you do today?" You may well get an answer of 100 million. If you ask the question, "How many transactions can be executed?" You might get the answer 7.

So, how do we know when we are getting a "type" answer? How do we know when we are getting an "instances" answer? How do we make sure handle the precision that we need, without pushing all the annoying explicit packet context onto the people we are striving to understand. We have to learn the context, apply the context properly, and hide the distinctions unless it becomes absolutely necessary. One way of doing this nicely is to have stash of instance models handy. So when talking about concepts we should talk about them extensionally when we mean to describe the instances, and intensionally when talking about the type.

 

EA and Finance

This post come out an initial simple twitter question, "Should EAs understand finance?" The conversation went all over the place. In 144 character bursts. It is hard to get the essence of what I was thinking in these short bursts.

Some of the slices:

How does EA justify its own costs? Interesting, important, but not where I had hoped to take things.
General discussion on values - again interesting but not what I was looking for.
Simplification - again, doesn't get to the meat.
IT should understand spend on everything (not just IT) - this is getting closer. It isn't necessarily about spend, though.

I guess what I should have asked is broader and better categorized than what I did ask.

When I say finance, my first thought was should the EA be able to understand (at a deep level) the balance sheet OF THE BUSINESS?

Second when it comes time to look at an annual report, should the EA be able to interpret the financials? Including the footnotes?

When it comes to investment decisions - should the EA bee in a position to understand the implications of different kinds of investments and tradeoffs? A new airplane hangar vs increase in parts inventory vs a new data center?

Note these are ALL: business decisions.

Now, since the spend on "IT" is so relatively large (1.3% to 5% of turnover or revenue) - depending on what's counted and how you count it, should the EA be an active participant in the allocations of this spend (budgetary vs actual)?

As technologies evolve - the shift from inhouse data centers to outsource (back to insource - outsource costing, in house operated), cloud, the economics become driving factors. How well should the EA understand these economics? How much should the EA be involved in these discussions? Is the EA involvement any different in these IT kinds of decisions than in other technology shifting decisions. For example changing the delivery fleet from gas (petrol) burning to biodiesel/electric/hybrid/CNG, LPG, LNG. All of these have huge effects on the business and its bottom line.

When a business has the opportunity to allocate "money" across its various operations, should the EAs be in that discussion? Normally it is an hierarchical, line of business, roll up approach with little input from EA except the CIO might ask, "What's your budget?" This is nonsense. The EA must have a budget, for sure, but to properly assist the business, it must be an active participant in budgeting decisions.

So as the EA has the opportunity to influence the business (used loosely) that s/he supports, where are the lines around finance?

Innovation and incremental improvement

I was watching the Formula 1 race from Malaysia this morning. It was on live and early, so I had the TV to myself. For the past several years F1 has been dominated by McLaren and Ferrari. For the past few years the changes to the formula have been relatively small.

This year, however, the FIA have made some pretty dramatic changes – resulting in a major shake-up. The old factory Honda team is no more, but has become reborn as the Brawn F1 team (Ross Brawn, the man behind the rise of Michael Schumacher being the team principal). Toyota have also done well, with the red bull/toro rosso teams also having good outings.

So, what changed. I contend that this is a great example of the difference between steady, linear improvement as managed in lean/six sigma kinds of processes, and the need to be radically different as is the case when major innovation is necessary.

The FIA changed the rules dramatically. Back to slick tires, much reduced rear wing area, the Kinetic Energy Recovery System (KERS) which charges batteries under braking so the power can be deployed at times to suit the driver. Adding an extra 80 hp for about 6 seconds a lap. Engine revs reduced to 18,000, etc.

The teams that appeared to treat the rule changes as evolutionary are doing poorly/ The teams that recognized the radical nature of the changes – and with little to lose, are doing much better.

So, perhaps where innovation is concerned we should not try to put it into well defined, six sigma, DMAIC based processes. Let the creative juices flow, make changes in a non linear fashion until the platform has become relatively stable and then shift to six sigma type approaches.