Friday, December 30, 2011

For 2012, I Pledge to Gain Weight

This year will be different. I am going to oscillate through various diet and exercise programs until I am 20 pounds heavier. I am going to eat more salt, and wait longer to reply to emails and voicemail. I know these don't sound like good goals, but I have so badly underachieved my resolutions over the past several years that if I miss these by the same degree - I’ll lose weight, lower my blood pressure, and be more responsive to my customers.

I don't know about you, but New Year's Resolutions are not one of the glory spots on my life's accomplishments list. I have tried every manner of resolution, including the resolving not to make any more resolutions. I am tortured by the knowledge that my resolutions tend to morph as the year progresses to a point that they are impossible to fail. For instance, I start the year with:

  • January 1: I resolve to lose 25 pounds before April 1
  • Later, this becomes: I will lose 10 pounds before May
  • Which morphs into: I will endeavor to lose weight sometime this year
  • By late mid-summer: I will eat better and try to exercise (note how any mention of weight loss has slipped right off the list!)
  • Which denigrates into: I will eat.

Around about October 1, I take the last quarter of the year to deliberately over-indulge my eating psychosis and accept my exercise phobias and inundate my system with toxins so as to purge my body of any healthy desires. This sets the stage for my weight-loss resolutions which I will start, of course, next year.

Keeping resolutions is tough even though we know we are merely resolving to do what we ought to be doing. I cannot count the number of times I committed to inserting comments into my application code, or (gasp) a script file. I figure I'm going to meet St. Peter at the Pearly Gates and be reminded that there are, oh, about a billion and three configuration settings I promised the gods I'd document once I found "The One" that fixed my system.

We work in a tough business; Information Technology; always under pressure for faster times to market, better performance, more functionality, and fewer bugs. Somewhere in the back of our minds we know that if we slowed down, spent more time on design, documented-, tested-, and refactored more; our products would have fewer bugs, perform better, be easier to maintain, and require less after-production attention. We know it, we absolutely know it.

So what stops us? Is it an innate desire to work weekends, get paged in the middle of the night, do we actually want to be tied to a job simply because no one else knows the secret bits to twiddle?

Have we become so addicted to the illusion of progress, that the appearance of effort has replaced actual productivity.

Just once this month, resolve to do something right that has previously been passed over because it took too much time. Do it right, and never, ever have to do it again.

Wednesday, December 21, 2011

Yes Virginia, There is an Architecture

We take pleasure in answering thus prominently the communication below, expressing at the same time our great gratification that its faithful author is numbered among the friends of The Enterprise Architecture Blog and note that responses of this nature have been produced as far back as 1897 (Example here, back story here).



Dear Enterprise Architecture,

I am old. Some of my friends say there is no architecture, only code. Manager says, "If you see it in a blog, it's so." Please tell me the truth; is there an architecture?

Virginia O'Hanlon
DEVELOPER,
CORPORATE OFFICES, USA


Dear Virginia,

Virginia, your little friends are wrong. They have been affected by the skepticism of a skeptical age and too many vendor meetings. They do not believe except what they code. They think that nothing can be which is not coded first, and then refactored for bugs later. All minds, Virginia, whether they be programmers or analysts are too little to comprehend user-requirements without a design based on the truth, knowledge, and principles of architecture.

Yes, Virginia, there is always an architecture. It exists as certainly as performance and reliability and flexibility exist, and you know that they abound and give to your annual evaluation its highest beauty and joy. Alas! how dreary would be the world if there were no architecture. It would be as dreary as if there were no Virginias. There would be no consumer confidence then, no resiliency, no elegant simplicity to make tolerable this existence. We should have no enjoyment, except in melodic pager tones and emergency-fix conference calls.

Not believe in Architecture! You might as well not believe in quality, or predictability, or even extensibility! You might get your manager to hire others to watch all the help desk calls to look for one that reads, "The architecture is broken", but even if they did not see architecture mentioned, what would that prove? Users never see architecture, but that is no sign that there is no architecture. The most real things in the world are those that neither children nor men can see. Did you ever see flexibility dancing on the lawn? Of course not, but that's no proof that it's not there. Nobody can conceive or imagine all the wonders there are unseen and unseeable in the world.

You may tear apart a web page and see what makes it work; the HTML, CSS, Script, and graphics, but there is a veil covering the unseen world which not the strongest man, nor even the united strength of all the strongest men that ever lived, could tear apart. Only design, planning, best practices, elegance, standards, tools, patterns, libraries, and frameworks, can push aside that curtain and view and picture the supernal beauty and glory beyond. Is it all real? Ah, Virginia, in all this world there is nothing else real and abiding.

No Architecture! Thank God! it exists, and will forever. A thousand years from now, Virginia, nay, ten times ten thousand years from now, architecture will continue to make glad the heart of users.

Tuesday, August 16, 2011

Naming is Everything

A project manager and very good friend of mine once called and asked to speak with me, urgently, and privately. I was somewhat intrigued and suspicious. She wasn’t given to flights of fancy, so I couldn’t imagine the issue.

She enters my office, closes the door, and says, “I have a problem with my team. They’ve been in a conference room all morning arguing. People all over the floor are beginning to complain, and I don’t know what to do.”

Why me, I wonder? Of all the resources she could have selected, why did this person seek my advice? Was it my wisdom? Interpersonal relationship skills? Was it my over-sized jar of pretzels? Then it hit me. She was probably aware that I’d been in a number of conference rooms in my day having, shall we say, enthusiastic verbal parlays with my office cohabitants.

Her staff was arguing and she knew that I had been in, if not instigated such venues before. Great, my reputations doth proceed me.

I replied, “What, may I ask are they arguing about?” Sheepishly, with a hint of embarrassment, she replied, “Naming conventions.” “Oh, this is easy”, I said. “Get them some pizza and close the door. Do nothing to inhibit the conversation.”

Johnny Carson once said, timing is everything, and maybe in comedy it is. But in the IT space, nothing trumps naming conventions, naming patterns, or rules. What you call a thing is the single most important element of understanding. Get it wrong, and you’ll sentence yourself and generations of descendant support teams to ambiguity hell.

I’m in a conversation right now about service level agreements, recovery time objectives, and recover point objectives - all vitally important topics and concepts in the business continuity and disaster recovery space. Some teams like to use terms like continuous, high, moderate, and none; while others like to use granularity based on time and numbers, less the 4 hours, more than 48, and so forth.

Still others want to use color coded labels such as gold, silver, and tin as these leverage visceral and visual imagery that are easily assimilated and yet allow for definitional changes as technology morphs over time.

It’s not easy, and we’re not through the process, but I’m in no hurry. Naming is everything, and if we get this wrong we’ll be fighting the uphill climb of training and explaining, when we could have exploited intuition and instinct.

Send pizza. I’ll be in a conference room for the duration looking to find a golden answer in 24 to 48 hours with highly consumable labels.

Saturday, June 25, 2011

Good Architecture, Bad Implementation

I’m not particularly resilient to bouts of insanity as readers of this blog will surely know. I skirt precariously close to the edge of hyper-expressiveness over the simplest topics. For example, just ask me about using production data in QA. Just saying.

I received a voicemail from a vendor who, presumably, wants a call back. I say presumably because they left a return phone number. At least I think it was a phone number. No humanoid audio-receptors indigenous to the genome referred to as Homo Erectus could possibly have deciphered the string of mashed syllables that followed the words "can be reached at …"

I don’t get it - the one single piece of information that is most critical to getting a call back - the phone number - is the one piece of data that is most commonly scrunched up to unintelligible gibberish. I do get this though - the phone number is so well known to the speaker that they can speed-speak it. That’s great for them and their precious cold calling phone time, but it is perfectly useless to the listener.

Again, readers here know of my critical eye when it comes to reader-centric writing, but the same is true for speaking. It doesn’t matter if the speaker knows what’s being said, it only matters if the listener knows. Seriously, I frequently have to replay the end of voicemail messages three, four, and five times, just to catch the phone number. I’ll bet this happens to you too.

Now here’s the rub; Bell Laboratories spent considerable time architecting phone numbers. First, most people make most phone calls within a small geographic area, so (at least initially) area codes could be assumed. Then, the exchange numbers (the set of three digits before the dash) were typically of a small set. For instance, in my neck of the woods the common exchanges are 762, 343, 561, and 563. There are others to be sure, but the vast majority of people I call are in these exchanges.

Lastly (again, not counting the area codes) phone numbers are a total of seven digits long, which fits very nicely in the human brain which has a short term memory buffer that can hold about seven things, plus or minus two. Again, a lot of research and architecture went in to figuring this all out. So, theoretically / architecturally, phone numbers represent a solid design based on the context in which they are used (the human brain). Today, we must deal with ten digits which is not optimal, but still not a bad design, when you consider chunking, and recognition.

All of this incredible thought is worthless to a over-clocked orator that can rattle off an important set of deca-digits faster than a ‘68 Chrysler goes through a tank of gas. Sometimes, you can have a great architecture with a really yuckie implementation. Just because a solution fails in production, doesn’t mean the architecture is at fault. Just because I can’t understand cold calling vendors doesn’t mean that phone numbers were poorly designed.

Consider the architecture when diagnosing production issues, but also be willing to accept that the architecture is sound, it is the implementation that failed.

Friday, June 17, 2011

Architecture: Context is Everything

If you run into me somewhere outside of work, don’t be offended if I don’t remember you. It’s a condition I have - called being human. The story you are about to read is true, only a name has been changed to protect the unfortunate Joe who had the unmitigated audacity to meet me out of the context in which we typically interact.

I’m at the grocery store and I see this guy I know very well - but his name escapes me. I know that I have bought (I’m not kidding) thirteen cars from him, all Saturns. His wife’s name is Diane. He used to be the Finance Manager at the Saturn dealership, but he is now the Sales Manager. He’s a great guy... whoever he is.

He hasn’t spotted me just yet and so I have a little time to recall his name. George? No, Paul? Ringo - don’t be ridiculous. What is this guy’s name? If my wife were here, she’d just pull it up out of thin grey matter - but for the life of me, I’m lost.

I resort to the alphabet game. I start with “A.”, Alan, Albert, Alfred, Alonzo, Aardvark - No that’s probably not it. Barry, Ben, Betty (unlikely), Brutus, nope - no "a ha!" moment. And so it goes for ten full minutes trying to recall every reasonable male name I can conjure, as well as a few outliers (Mufasa, Tiberius, and Zeus). I actually went through the list twice.

I could even remember that this fellow has a condition known as Hyperlipoproteinemia, which somehow came up in a conversation about fuel mileage and cruise control. BUT I CANNOT REMEMBER HIS NAME.

Context is everything. It’s why we spend 20 minutes in every Architecture Review to understand the business context of a solution under consideration. An architecture might be perfect in one context, inadequate in another, and overkill in a third.

I did the only reasonable thing I could. I hid in produce until I saw him leave. Two weeks later, I had my car in for service. I walked right up to him and said, "Hi Joe, saw you in the grocery store but you looked to be in a hurry." Context is everything.

Monday, June 6, 2011

Vanishing Volumes of Voicemails

I used to get a ton of voicemails, dozens everyday; so many that even after I had responded to all of them and gone home, by the next morning there would be another three waiting.  But, not any more.  At first, I was worried.  Was I no longer in the hub of activity?  Were people finding better answers through other sources?  Should I consider this a value metric which is heading in the wrong direction?  If no one is contacting you - what is your purpose?

I still get a few voicemail messages, but only from vendors - and most of them are cold calling, trying to sniff out a sales lead.  Most days, I can count the number of vendor voicemails on one hand, and still have enough fingers left to go bowling. 

I began thinking about the structure (architecture?) of various forms of communication.  Why is electronic communications growing so rapidly, and yet handwritten letters and notes decreasing in all but a few circumstances.  When do I pick up the phone, and when do I select a different medium?  In a business setting, most phone calls are initiated to get real-time answers to a specific question - this is not the ideal forum to utilize email.

Instant messaging, by it’s very name, is a great way to get a real-time answer to a specific question.  IM, Sametime, texting, chat, or whatever you call it has the advantage of being a real-time medium (replies *can* be delayed, but that is not its general mode), and it is not particularly well-suited to elongated conversations (teenagers notwithstanding).  It is even possible to conduct multiple simultaneous chat conversations with totally separate parties - something you could never do with the phone.

While the number of my voicemails has dropped precipitously, my number of chats has grown exponentially. Seldom do I go home at the end of the day without a dozen or more Sametime windows. I have configured my system so that each conversation shows up as a tab inside of a single Sametime window.  This makes it easier for me to manage the conversations.

My voicemails have shifted to chats.  Instant messaging has, in fact, replaced many phone calls, meetings, and emails because - none of those were really the right medium for the tasks as hand.  What do you think, post a comment or … call me.

Friday, April 15, 2011

Building the Boat is Only Part of the Problem

NCIS is the name of a quasi-cop show on CBS that stars Mark Harmon as Special Agent Gibbs who leads a team of investigators that solve crimes involving military personnel.  Gibbs has a hobby of building boats in his basement; not little toy boats, but real, human sized water craft.  It’s cathartic for him.

I had the pleasure this week of talking to a co-worker about programming. We both mused that there is nothing quite like loosing yourself in a coding project.  I’ve never lost track of time building a PowerPoint, but coding - geesh whole days have gone by in a flash.

There are a lot of reasons to like a show like NCIS, although for me there are two draws.  One is watching David McCallem, a.k.a. Ducky, or as I like to remember, Illia Kuryakum from the Man from U.N.C.L.E.  THAT was quality television, circa 1968.

The second draw is watching Gibbs work on his boat, in his basement.  Gibbs can be somewhat acerbic in his responses, so after nine seasons, we’re still not exactly sure how he gets his boats (there have been multiple) out of the basement.  He is said to have burned them - although a simple thought experiment would seem to rule that out on the merits, e.g. smoke detectors, flames, joists, confined space ... you get the picture.

Gibbs has also claimed that he just “breaks the bottle”, a classically uninformative retort.

As a programmer I have been witness to countless solutions that “broke the bottle”, i.e. solutions that worked in one carefully constructed manner, but once they hit the real / production world could not stand up.  Maybe they failed for reasons of security, or throughput, or resiliency.  If only the designers, developers, and deployers had a roadmap to which they could compare their solutions before they began building boats in their basement.

A Reference Architecture is a guide, a template, a sample general solution that aids in the development of a specific solution.  The value of a reference architecture is that it communicate boundaries and options to the developer such that the final product conforms to the environment in which it will live.

The Gibbs character is smart, so I’m thinking that the whole get-it-out-of-the-basement problem is actually part of the therapeutic process.  We, however, are not here to resolve childhood traumas (generally), so building boats that can’t fit through the door should be avoided at all costs.  Our applications, systems, and solutions should all be based on Reference Architectures that align with our business aspirations, technical capabilities, and human capital.

Gibbs, before you start your next boat, talk to an architect.

Friday, April 1, 2011

Time is Money


I can remember the day when all of our televisions had antenna and our telephones had cords. Today, of course, this has switched. I don’t mean to date myself (I did enough of that in High School – hardeee har har). I’m just saying that we used to operate under different paradigms, and I sometime reflect on those days.

Dial-up modems were all the rage in our household in the ‘80’s and early ‘90’s. Long before the internet, gophers, and frames, we used bulletin boards. Ah, the days. I used to be able to type BBS commands into the terminal faster than the screen could scroll. Compuserve was a major telecommunications provider and everybody at some point had a Compuserve user Id like 9047381968732. Mine was 3.

So I’m sitting at the computer when my wife asks me about company expense policy and whether I could be submitting for reimbursement of long distance business telephone calls. “Why”, I ask? “Well there appears to be a long distance phone call on our bill” (with wireless cell phones today, I don’t remember the last time I saw a long distance charge).

Hmm, I ponder, “What’s the area code?” “It’s 303”, she replies. 303? … Who do I know in area code 303. I jump up and get the telephone book. A telephone book is a large, densely printed, um, er… well it has all of the numbers, um…. Nevermind – if you don’t know, just TXT your BFF, maybe they’ll tweet you back.

Area code 303 is in Boulder Colorado where the National Institute of Standards and Technology resides, or more to the point, it’s where their dial up servers were located that could be used to set the time on your computer.

Now this is cool. By using your modem to dial up NIST, you could set the time on your computer to the exact millisecond. You had to download some software, but the really neat part was that the synchronization process even accounted for the lag time resulting from your computer’s distance from NIST.

My wife was not all that impressed, so I decided to use a time honored husbandly method of advancing the conversation – diversion. “I could not have been online for very long, how much is the phone charge?”

“13 cents.”

“Seriously? You seriously want me to submit a business expense for 13cents. Don’t you think you’re being just a tad ana… er, um persnickety?”

“Possibly”, she says leaving the room. “But then again, I’m not the one who had to have his computer call Boulder Colorado to have the clock adjusted to the correct millisecond.”

Friday, March 25, 2011

Digital Earthquakes and Tsunami

We’ve all been watching the events in Japan recently and felt the shock of seeing the devastation of the earthquake and resulting tsunami.  As of this writing there are still untold victims needing to be rescued.  But there is one element of the disaster that bears consideration - one element of bad news that just didn’t happen; at least one headline you haven’t seen.

If you haven’t already, play the video and carefully watch the tall office buildings sway back and forth.  One can only imagine being inside one of those skyscrapers during such an event.  I work in the US Steel Tower in Downtown Pittsburgh and when the high winds of Spring blow through you can see the light fixtures swing.  There is nothing quite like the sound a building makes when it sways like a Junior High slow dance. It’s terrifyingly cool.

The Tokyo office buildings do not sway by accident, it is not a design flaw, or a failure of structure or strength.  Quite the reverse - these building sway on purpose so that they don’t crumble and fall over.  Think about a pane of glass - it is very hard.  So much so, that you need a diamond to scratch it.  Try to bend it, and it doesn’t.  Try just a teeny bit harder and it cracks, shatters, and breaks apart. Glass is either in one piece, or a dozen - there’s no in between.

Tall buildings used to be constructed like glass.  Hard, Strong. Rigid.  But if even a small earthquake came along, the result was devastating.  Buildings shattered like glass.

That is the headline you didn’t read.  Amongst all the destruction, and make no mistake there was widespread loss - but none of the tall office structures collapsed, because they were designed to lean, bend, ebb-and-flow, and to dissipate the energy of ground movement through their skeletons, connections, and interconnected systems.

In the digital domain, this would be called loose coupling.  Loose coupling allows the failure in one system to be absorbed or deflected by others.  The failure of a back-end process should never cause the user interface to lock up - if they are loosely coupled.

We work in an environment where high availability and disaster recovery should be natural elements of our solutions.  Like the architect’s of Tokyo’s office buildings, we should take the time to ensure that our highly distributed, complex applications are loosely coupled so that in the event of the unthinkable, (or even the routine!) our systems behave in a manner most conducive to allowing our customers and employees to achieve as many of their goals as possible.

Servers will fail.  Queues will back up.  Digital earthquakes happen - they are not “unexpected.”  Design for them.

Friday, March 18, 2011

Top 10 Reasons to Love Binary

As Information Technologists, binary is a fundamental element of the environment in which we work. Digital computing, integrated circuitry, and logic are all based on the concept of On or Off, Yes or No, and True or False. This all stems from the binary number system, where there is no room for ambiguity.

You know that the binary only has two symbols, 0 and 1, whereas the system we typically use is based on ten symbols; 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, i.e. zero through nine.

The Romans used I, II, III, IV, V, VI, VII VIII, IX X, i.e one through ten. The result was really bad accounting because the Romans had no symbol for zero. If Marcus had five chariots and he rented III to Venus and the other II to Cesar, how many did he have left? Send me your answer.

Without a number for zero, such problems result in ambiguity. Is the answer to the above math problem none, or did you leave it blank because you don’t know? See... ambiguity.

While binary eliminates any ambiguity, it can be a tad verbose. Here for example, is the year I started with my company written in binary: 11111001010. Very clear. Isn’t this much better than the Roman MCMXCIV? You see - the “CI” could be a hundred and one, or the “IV” might be four. This is so hard that the Romans probably just used Google.

As much as our occupation is based on binary - there is still a lot of ambiguity around. What’s the best way to connect two real-tine applications? SOAP, an ESB, MQ Series, Java Remote Method Invocation? Is your answer an opinion, is it based on a personal preference, or is it the same answer that ten different application designers would arrive at over the course of a year?

This is one of the value propositions of the Architecture Review Board - it represents the end of ambiguity. By assembling the company’s thought leaders in application architecture, platform solutions, infrastructure, as well as all of our technology operating practices - we are able to ensure that consistent, unambiguous solutions are applied to our business aspirations.

Our occupation is surrounded by ambiguity. We need to be able to distill some of the complexity down to the fundamental elements where we can make clear, correct, and consistent choices. The ARB represents the end of ambiguity.

So... my top 10 reasons to love binary are:

1. Only two digits to remember.
10. No waiting to get to the end.

Friday, March 11, 2011

Dialing In and Checking Out

Can you spot the difference in these questions:
  • What is the company’s operating practice when it comes to running a batch job in the shared database environment, Bob?
  • Bob, could you give us a summary of the company’s operating practice relative to running a batch job in the shared database environment?
Does this sound like a trick question? Do you look at these two and say, other than the placement of the name, “Bob”, these questions are about as identical as they could be?

I facilitate a lot of conference call meetings, and a high percentage of them are needed to analyze or resolve architectural issues. Architecture Review meetings can be as much fun as a flat tire, without the novelty of searching for the jack. Now I’ll admit that a good loose coupling debate exhilarates me - but I’m not sure I’m all that sane.

The difference between the two questions is exactly what you thought - in the one case the respondent, Bob, is informed upfront that the question is for him. When conducting a conference call, webex, or even a video conference where several people are “dialed in” it is important to provide audible cues as to the ebb and flow of the conversation.

Now you might say that the responsibility to stay engaged rests with each individual, and you’ll get no argument from me. There is nothing more wasteful than to have assembled all of the pertinent individuals only to learn that a third of them mentally checked out nine seconds after roll call.

So first, why does this issue come up in a blog about architecture? We work in a world where conference calls, geographically dispersed teams, and self-induced attention deficit are common place. I use every trick available when facilitating a virtual meeting to ensure that we arrive at the best answers, clearest direction, and least ambiguity. I don’t mind using a few little “cheats” if it increases the value of everybody’s time.

Secondly, audio bridges and video conferences just don’t, can’t, and won’t provide the same level of conversational immersion as personal contact. A phone call between lovers will never replace a goodnight kiss. If you want to maximize the value of everybody’s time, use audible cues to narrate everything you do. “Let’s now take a look at slide #3.” “That covers the first agenda item, let’s move on to Eric’s project update, .. Eric?” “Bob, can you summarize our batch job policy for Carl?”

If you are facilitating a virtual meeting, think of yourself as a narrator, making sure that you verbally depict the context cues that would normally be obvious if everyone were physically present.

Thursday, February 17, 2011

Running Stop Signs

I’m not a lawyer; I don’t even play one on TV.  But, I did once win a court case - a case involving a traffic citation for running a Stop sign.  As we have established here on a number of occasions, I am but a mild-mannered enterprise architect, hardly the type to flaunt the institutional governance that establishes the balanced flow of goods and services within the appropriate bounds of safety. 

Among my many idiosyncratic manifestations, however, is an utter intolerance for unjustified retribution.  In short, don’t tell me I’ve crossed “the line”, if you haven’t taken reasonable steps to identify said longitudinal barrier.  Define the line.  One of my earliest grade school memories is of a teacher barking, “You’re outa’ line Meredith.”  Gee, I didn’t know there was a line, let alone that I was out of it.  My attempts to solicit information about this line were met with detention and unpleasant phone calls to mom.  But I digress.

If there are rules … Just... tell... me... what... they... are!  I can be compliant, I can be frustrated, I can be many things, but I am not, and never will be clairvoyant.  Define the line because I can neither read minds, nor predict the future. 

So... if you want me to stop my car, you should erect a clearly visible Stop sign.  Thinking of putting up a Stop sign, or putting one up and then allowing the native shrubbery to obfuscate the view pretty much violates the concept of “define the line.”  To make a long story short, I appeared in court with my traffic citation and the photos displayed here to show the judge that while there was a Stop sign, and I did, in fact, proceed unabated through the intersection - the sign was clearly obscured.  (By the way the two words “clearly obscured” can give an analytical thinker recursive migraines).

There are limitless options for deploying web applications, untold permutations of database configurations, and exactly 7,000,000,002 application integration options (it was seven billion and three, but it turns out that no one remembers CORBA).  No company can support everything, so there need to be rules as to what is allowed, when it is allowed, and why. 

But having the rules is not enough.  It is not enough to say “You’re outa’ line” if you haven’t clearly defined the longitudinal barrier (I think I covered this).  We all need to do a better job defining reference architectures that include clear, unambiguous, consumable operating practices.  By “consumable” I mean that the rules need to be written for the consumer rather than the expert.

Thursday, February 10, 2011

Change is Easy - Transitions are Tough

When I was a young boy and the phone rang for my mother, I was told to say that she was indisposed if she could not come to the phone. “Indisposed” was polite for - in the bathroom. Polite children do not speak of bathrooms. Today, I am disposed to speak of being indisposed.

Recently, I found it necessary to make a brief visit to the necessary room for men. Guys, boys, dudes, and gentlemen do not commonly speak in public “facilities.” Head-bobs are considered formal conversation. So... as I was headed for a sink and I heard the questioning word “flush?” I was taken back, looked in the mirror, observed my normative pale complexion and replied, “No, I’m fine thank you.”

“No”, the contextual assailant replied, “Are you going to flush?” I hadn’t given it any thought. It just kind of happens automatically, right? Wait - this is an older building, maybe, just maybe.... Yes. A manual system. How quaint. I returned to the scene of the omission and pressed the magic lever.

As I returned to the sink I began to ponder the state of transition we’re in, where some of the “facilities” have introduced sensors and others have not - and how this yields (the very definition of) thoughtlessness. Not as a result of cruelty, but the literal “I didn’t think about it” kind of thoughtlessness.

By now I was wondering when the water would begin to flow. I lifted my hands a little, then lowered them, then began waving them in all manner of random directions. I began to wonder if Alan Funt was having a good day. Oh! this is a manual restroom. How quaint. Turn the knob, wash the hands, look for the towels.

Wait! Walk back to the sink and turn the water off. Quaint. Return to the paper towel dispenser and reach for the crank on the right side. No crank. Lever? No lever. Maybe I just have to grab the towel in front and pull. No towel. Grrrrrr.

A line of impatient soggy hands has begun to form behind this usually competent enterprise architect. “Just wave your hand in front of the dispenser... it’s like Magic” someone quips. I hate him. I truly hope I get the last towel. I leave the restroom feeling like Star Trek’s Chief Engineer, Scotty, talking to a mouse to generate the plans for transparent aluminum.

Fortunately I reach the elevator just as someone is getting off, and it’s empty. Alas a few moments to collect my thoughts after three harrowing moments of indispose. Transitioning from manual- to sensor-driven automation is going to screw me up.

So, why hasn’t the elevator moved? Did I forget to push the button. As a inside joke, I confidently announce “Bridge!” Nothing happens. I reach for the floor buttons. My choices are Close Door (already closed), Fire Alarm (seems rash), Help (no way given my recent bathroom trauma), or Open Door (sigh). No line of floor numbers, no color-coded buttons, just four equally useless options. This is one of those elevators where you have to select the floor before you get in.

Transitions. We live in a world that is in a constant state of transition, which wouldn’t be an issue if we didn’t also have a brain that relished autopilot. I used to work in an office building that installed motion detectors in half the conference rooms in order to save on electricity. The electric bill went up because everybody forgot to turn off the lights in the rooms that didn’t have sensors.

Transitions. If you are transitioning a system - you need to make it crystal clear to the users exactly when and where the “New” is - in such a manner that the old is equally obvious. I see this when reviewing application code when old and new paradigms / object models / architectures need to coexist for some period of time. Without absolute unmistakable clarity, it is so easy for Developer ‘X’ to perpetuate the old without ever thinking about it.

Transitions. I don’t think most of us mind change - in fact our industry almost demands appreciation for it. But transition and change are two different things. I will love the changes to automation and sensors, once we get through this half-in, half-out time of transition.

Tuesday, February 1, 2011

Architecture Elves

Have you ever heard of Kleiber’s law? It states that cookies made by elves will always taste better when dipped in milk. Wait - that’s Keebler’s law. Nevermind. Max Kleiber did a whole bunch of research in the early 1900s that dealt with the size of animals and their lifespans. Now get this - there is a correlation, and a fairly straight line correlation at that, that shows the ratio of animal size and heartbeats is consistent. Bigger animals tend to have slower heartbeats, but that the total number of heartbeats in their lifetime remains consistent.

A fly has a rapid heartbeat, and a very short lifespan. An elephant has a slow heartbeat and lives a long time. As Steven Johnson puts it, elephants have the same number of heartbeats, they just take longer to use them up. To be precise, metabolism scales to mass to the negative quarter power, i.e. the ratio of animal mass to their lifespan is almost a universal constant. Bigger animals have slower systems, and therefore live longer.

But the cool part is that it doesn’t stop there. As ANY organism becomes larger there is a slowdown in "metabolism." For instance, plants follow this pattern from grass to redwood trees. Even artificial organisms, such as human-made constructs, i.e. cities, as they become larger their ‘metabolisms’ slow down. As a city expands, the growth rate of gasoline stations, electrical power grids, street lights, urban communities, almost everything experiences a growth rate that conforms to the negative quarter power ratio.

Almost.

As cities grow, the amount of grocery stores, cul-de-sacs, and elementary schools follows the natural pattern of a metabolism that scales to mass to the negative quarter power, i.e. as things get bigger the rate of activity slows, like an elephant’s heartbeat - except for the rate of innovation.

Innovation follows a similar dynamic ratio to size, but it moves in the opposite direction. Theoretical physicist, Geoffrey West, wanted to see if the metabolism of urban life slowed down as one would expect using Kleiber’s law. What he found was that every datapoint that involved creativity - including innovation, patents, and research budgets not only increased in larger urban settings, but increased dramatically.

The quarter-power law was in effect, but in the reverse direction. Instead of larger cities having fewer innovations, they had more - and it wasn’t just a linear increase. A city that grows 10 times in size produces seventeen times more ideas. An urban area 50 times bigger than its neighbor would produce 130 times more ideas.

Our company just doubled in size - what should this mean in terms of our ability to innovate? Twice as many ideas? No, more like 3.2 times as many. Ideas get generated when humans share information. Psychologist Kevin Dunbar performed research in the early 1990’s to discover where new ideas actually come from by actually watching smart people whose job entailed new thinking. Most new ideas came from conference rooms where knowledge workers share the results of trial and error.

As your company grows, you should connect with people as often as possible. Share ideas - even the ones that seem to be poor. It is the sharing that matters, not necessarily having the best ideas.

Saturday, January 1, 2011

ARB in One Page

As I've written before, Enterprise Architects need to effectively communicate to a wide range of audiences using a variety of tools and techniques.  Here is a link to a one page format that I've used for executives, to quickly communicate the value of the Architecture Review Board.


Follow by Email