Tuesday, December 7, 2010

They Who Shall Not be Named

The story you are about to hear is true, only the names have been changed to protect the guilty.

THE SCENE: A wireless cell phone store located in a metropolitan setting, with customers milling around, sales staff engaged in various activities.  In walks a mild-mannered Enterprise Architect seeking information on upgrading his phone.

SALES PERSON (SP): May I help you?
MILD MANNERED ENTERPRISE ARCHITECT (MMEA): Sure, I’d like to know what my upgrade options are.

SP: Sure, may I have your cell phone number?
MMEA: 412-555-9999

SP: And your name?
MMEA: Eric Meredith

SP: Excellent, Mr. Meredith.  And your password?
MMEA: [Stare.  Mouth agape.]

Contradictory physical manifestations occur as the Mild-Mannered Enterprise Architect experiences an increase in heart rate with a simultaneous degradation in synaptic activity.  In fact, at some point a secondary neuro-play unfolds with a lead role delivered by the cerebral overseer, a.k.a. the Executive Function.

EXECUTIVE FUNCTION (EF): I’m getting indicators that something has entered the cortex and is backing up the entire workstream resulting in a failure to oxygenate the blood.  Can we please get a signal to the lungs.  Oh, and the eyes are drying out.

MMEA: [Blink]
SP: Sir?  Your password?
MMEA: [Blink]

EF: I think I found the issue.  Apparently a foreign concept has entered the system; a concept so bizzare that it has created a log jam of intellectual repulsion.  We must expunge this poison quickly.  So.. Lungs - Inhale and prepare to talk.  Neck - shudder the cranium to dislodge the confundium.  Cue the Vocal Chords, and …. Speak!

SP: Sir? 
MMEA: Um, excuse me?

SP:  It’s for your protection sir.  I need you to give me your password.
MMEA: I, I don’t understand. You want me to say my password out loud, in this store, and this is for my protection?

SP: Yes, it’s for your protection.
MMEA: Look, I’m not going to blame you for this, but apparently someone in your organization has developed a system that results in you asking for confidential information in a public venue.

SP: It’s OK sir, I can see your password right on my screen.
MMEA: [Stare, Mouth agape. Blink]

What follows is several nano-years of silence as the Executive Function considers a number of options including but not limited to hysterical laughter, an examination of the store for Candid Cameras, and the sub-cerebral possibility that the alarm clock is due to wake us up.

SP: Sir? 
MMEA: [Blink] You can see my password?

SP: Yes, it’s here on my screen.
MMEA: [Blink, Blink] So the people behind you can see it too?

SP: Yes, so you should hurry up and tell me.
MMEA: [Blink, Blink, Blink] I’m not going to give you my password.  You should not be asking for it, and in fact there should be no possible way for you to see it, retrieve it, discover it, or randomly guess it.  That it is displayed on your screen indicates a complete lack of understanding by your organization on the term “password.” 

SP: But..
MMEA: Again, I’m not going to blame you; you are merely following the instructions some uninformed system architect has provided. 

SP: But...
MMEA: I’m going to leave you with one request.  Would you please inform your management of this conversation and that I was unwilling to divulge information that you should never have been able to access.

SP: [Blink]

SCENE: Fade to black as the mild mannered Enterprise Architect walks out of the store.  Fast forward two weeks; much of the trauma has dissipated, and our Mild-Mannered Enterprise Architect is once again capable of cognitive processes.

Cue a montage of views showing our MMEA considering various cell phones and providers, eventually finding a perfect choice at the right price at a large warehouse store.  For curiosity purposes we return to the original chain (this time at a mall) to see just how good a deal has been achieved.  The MMEA does not disclose that he has already purchased a new device.

SCENE: Crowded cell phone store in a local shopping mall.

SP2: How can I help you?
MMEA: I’d like to know what the cost of an upgrade is?

SP2: Sure, what is your phone number?
MMEA: 412-555-9999

SP2: And your name?
MMEA: (Wondering just how many people have that same phone number) Eric Meredith

SP2: And for your protection, what is your password?
MMEA: (Must.resist.primal.urges...) I’m not giving you my password.  Can we do this another way?

SP2: Sure, show me your Drivers License.
MMEA Shows license.

SP2: Thank you.  By the way, your password is 9934.
MMEA: [Aneurysm]

SCENE: Fade to black with sound of emergency 911 conversation.

Confidentiality, integrity, and privacy should be foundational to any architecture; to ensure that the real conversation illustrated above cannot happen.  It should not be able to happen; and in those places where the systems are antiquated, the users should be trained to protect customer information and the corporation’s reputation for handling of private data.  I have to go now - it's time for my spoon feeding rehab.

Monday, November 29, 2010

Architecture: How Low Can You Go?

I love sinks because they help me explain how things that are designed really poorly can still be widely successful, lasting through generations of users.   Yep - most sinks are walking architectural disasters; er, make that user interface disasters.  Consider that there are two attributes of running water you need to control; temperature and rate of flow.  Perfect; most sinks come with two knobs.  Which one is temperature?

The poor design of sinks is so pervasive in our society that I typically get people trying to argue why the design is actually good.  It isn’t, and if you had been brought up on the planet Zornak (I’m just saying), you would see it too. 

Let’s just call it an implementation detail.

That, is an interesting topic - at what point do you stop considering an attribute of a solution an architectural element and start thinking of it as an implementation detail.  Where do you draw the line on an IT solution and say above the line is architecture and below it is implementation.

Consider this code snippet:

for ( int x = 1; x<10; x++ ) { array[x] = x }

Which means, create an integer variable ‘x’ and loop through the “array[x] = x” line of code, increasing the value of x by 1 while x is less than 10. 

For the uninitiated, this line of code likely does not perform as a programmer would have intended, unless he or she wanted the first element of the array (the zero-ith element), to have whatever default value the compiler assigns.

Is this an architectural discussion?  An implementation detail?  A Bug?  A clever use of computing resources based on an intimate knowledge of the language (C/, C++, Java, C#, etc..) and compiler? 

Every organization needs to establish a boundary that separates architecture from implementation.  This not only facilitate decisioning, but also responsibility and accountability.  The Architecture / Implementation boundary facilitates the systematic distribution of work, tools, priorities, skills, and training.  It allows for the encapsulation of effort, which seems intuitively elegant in an environment dedicated to developing business services.

Here, we use the Zachman Organizational Model for Enterprise Architecture, and define the Technology Row as the boundary.  Below the Technology Row is implementation; above it is architecture.  In our architecture reviews we do not consider code, IP addresses, or other details when assessing the appropriateness of a proposed architecture.  It’s not that these are unimportant, far from it - they’re just not considered architectural elements.

The Software Engineering Institute says that an architecture largely permits or precludes a system’s quality attributes (such as performance, reliability, security, etc).  Note, that an architecture does not guarantee quality attributes.  A good architecture can yield positive qualities, while a bad architecture yields faucet knobs that must be used carefully or you’ll burn your fingers or splash your tie - two mistakes that never happen on Zornak.

Thursday, November 11, 2010

Is it Time to Build a Bridge?

Recently, I’ve thinking a lot about bridges.  I participated in a team building exercise that involved a group of us building a bridge.  We had 30 minutes to design a structure that would span over 4 feet, and then we were split into two separate teams in two separate rooms to construct two halves of a bridge that was to be connected and support five pounds of weight.  Our materials were limited to some dowel rods, foam board, and of course the Delightfully Universal Correction Technique (DUCK Tape).

Take a look at the picture here of the Golden Gate Bridge as it was being constructed in 1936.  I find these pictures fascinating, because they are visually analogous to a situation IT architects, developers, and project leads find ourselves in quite often.  Note how the vertical towers are constructed before the roadbed, how the suspension cables are draped between the towers and how temporary support structures are used before the bridge can become self sustaining.

In other words, the usefulness of the bridge is significantly degraded - it cannot even support itself - until long after the initial elements are put in place.  The second picture here is of the Hoover Dam By-pass Bridge (Colorado River Bridge bypasses the Hoover Dam).  Not that the cables you see holding up the arch were temporary - they were all removed as the the road deck was laid down on it.  Construction on this bridge began in January 2005 and was completed five years later - October of 2010.

Five years.  For five years this bridge provided no value at all.  It consumed thousands of man-hours, millions of dollars of investment, and no doubt traffic detours and congestion.  Yet, few would argue that the two lane road that caps the top of the Hoover Dam was insufficient for the growing transport needs of the region.  Nevada outgrew what had been a suitable solution.

Application developers have been using the equivalent of two lane roads for many years; we call them point-to-point connections.  Need to send data to another application?  Open a socket, a port, a queue; invoke a remote method, or call a Web service.  It works.  It’s well understood, and we have a lot of infrastructure to support point-to-point conversations.

Our Architecture Review Board recently reviewed a solution that involved adding 20+ connections between 24 existing applications.  This would be on top of the connections that already existed - and make no mistake, this system will continue to grow as business requirements expand.  Continuing to use point-to-point connection in an environment where the population density (number of applications) is increasing along with a desire to capitalize on reusable components (more points of connection) calls for adoption of forward thinking - like a bridge builder.

A Service Bus, is an IT construct in which applications connect to other applications indirectly.  Rather than application ‘A’ calling application ‘B’ directly, ‘A’ makes a call to an intermediary (the Bus), which then routes the message to the appropriate end-point (application ‘B’).  The value of this architecture is that what you loose in directness and simplicity you more than make up for in manageability.  Bus architectures allow for improvements in understanding traffic flow (critical in problem determination scenarios), aggregation, security, data transformation, time to market, and while counter-intuitive - performance.

Like building a bridge, the full value of a bus architecture is not readily apparent right away.  Unlike bridges, you don’t have to wait five years - buses can provide value from the very first implementation, even if only one connection is implemented.  As additional connections are added or migrated to the bus, the value proposition increases. 

If you are managing a complex application environment, with multiple, real-time point-to-point connections - you should be moving to a bus infrastructure.  The total value won’t be realized right away, and you may even have to employ some digital DUCT Tape along the way - but the end result will be an environment with better scale, management, and flexibility.

Friday, October 29, 2010

Could you build a hospital out of a used truck?


If you had to pick the one medical technology, a pill, a shot, a vaccine, a surgery, a scanner, the one medical technology that provided the longest benefit, i.e. extended human life the most - what would it be? I can remember the very early days of heart transplants and the unbelievability of it. But was the surgery more impressive then the immunosuppressant drugs that kept the patient from rejecting the donor’s heart?

A case could be made that infant incubators hold the clear record for enhancing human longevity. No other device (in utero procedures - perhaps), are responsible for an entire lifetime of health. As far back as the 1870s, hospitals around the world have been able to demonstrate statistically that the introduction of these enclosed, clean, warm environments dramatically reduce infant mortality. From 1950 to 1998, the U.S. witnessed a 75% decline in the infant mortality rates (i.e. death) as a result of incubators.

No matter what else is going on, humans continue to have babies. Perhaps that is why, after the 2004 Indian Ocean tsunami, incubators were sent from all over the world to the affected region. Understand that incubators are not cheap; while roughly the size of a small desk, or a push cart, these things can sell for $40,000, and that doesn’t begin to cover the cost of transportation, training, expendables, and such.

So you can imagine the heightened disappointment when doctors showed up a year or two after the tsunami and found that none of the incubators were being used. Most had broken and no one knew how to get them fixed. Some were usable, but the instruction manuals were in English.

Jonathan Rosen, a Boston doctor, had noticed that third world peoples often struggle with technology as a result of a diminished supply chain, but that somehow they always managed to keep their Toyota 4Runners on the road. Maybe that’s a testament to Toyota, but I rather think it has to do with common knowledge, availability of technology, and human nature. So Rosen proposed, and the organization Design that Matters developed, an incubator out of leftovers from readily available car parts. Car batteries supply the power, headlamps the heat, door chimes the alarms, air conditioner fans provide circulation and so forth. The entire incubator is constructed using readily available components and knowledge.

There are any number of lessons here that can be applied to first world corporate I.T. shops and the designs that matter to us. But first, let’s agree that building new solutions, with ever increasing complexity out of diminishing knowledge pool is not a good idea. The key takeaway from the incubator / 4Runner lesson is that the maintenance of a solution is at least as important as the initial construction.

Every time we design and build / enhance an application, a system, or component, we need to ask - what happens to the maintainability of this solution after I move on? Can the organization find among the populous the necessary skills and tools to support the solutions I am building today.

Tourturing the incubator analogy just a little more... as you consider your next design, think about how you could assemble a solution using readily available components that the pool of future support resources will understand. If you always go back to the solutions you are comfortable with, you may be putting your business at risk once your knowledge retires.

Friday, October 15, 2010

Picasso, Magicians, and I.T. Technical Writing

Ever wonder how magicians learn their tricks? You gotta figure that these guys (they are after all mostly men) are pretty secret about their, well.. secrets. Ironically, most magicians will share anything they know with you so long as you can demonstrate that you have the skill to pull it off. No professional magician wants to see his "art" messed up by a rank amateur. So most budding prestidigitators start by hitting the books to gain the skills they need to wriggle their way into a "session."

A young lad might find in the local library (you do remember libraries, right?) copies of "The Card Magic of Le Paul", "Close-Up Card Magic", "Reputation Makers", and "The Amateur Magician's Handbook." These and countless others are the foundations of knowledge that can advance the aspirations of anyone looking to join the Society of American Magicians or the International Brotherhood of Magicians (IBM - I can’t make this stuff up!).

But!! You have to be able to translate utter gibberish more or less conforming to the rules of grammar, punctuation and style loosely attributed to English into physical movements so subtle as to be innocuous to the human mind.

Magicians are a verbose bunch - they love to practice, patter, and perform. They are however, lousy technical writers. It is in this regard that magicians, sleight of hand artists, illusionists, escape artists, mind readers - - the whole gabby lot of them - just like I.T. folks.

Just try to learn a one handed shuffle from a written description using only text. It is abusive. I still have knuckles and joints that ache from trying to accomplish the impossible - only to discover that it was, in fact, impossible.

Technical manuals... have you ever read one? Ever tried to assemble lawn furniture from Sears? While the First Amendment to the US Constitution guarantees our right to peaceably assemble, I have yet to ever assemble anything from Ikea peaceably.

Which brings me to my point. Technical writing is hard. Writing a good technical manual requires a specialized skill which can only be observed by watching English Majors who have been threatened in passive voice.

This problem is exacerbated by the delusion that the poison of illiteracy that infects the world’s conclave of technical writers has gently passed each of us by. We are immune. After all, everything we write is plainly clear to child of three, a blind squirrel, a lost lamb, and our mom. Problem is folks, all of Picasso’s paintings made complete sense.... to Picasso.

Simply put, you cannot judge the clarity of your own writing.

Truth be told - your technical writing skills are probably only usable within a narrow context. And by context, I mean to the very few people with whom you directly interact every day. Take one step away from them and your written words might as well be preceded by "Made in Taiwan."

For instance, here is an example of an instruction seen in an airline lavatory. It probably made complete sense to the author at the time of writing, but requires clairvoyance to decipher:

Please do not throw foreign objects into flushing toilet.

Is it the throwing motion that is prohibited here, or is it OK to throw things, so long as the object is of domestic origin? Can I gently drop anything in so long as the commode is not actively flushing? Every word that is added to the instruction actually reduces clarity. You *probably* get the intended meaning; but it... is... not... clear!

The vast majority of emails I read are insanely ambiguous. Authors assume their readers have all of the necessary context and thusly just start their written Rorschach Test. I once received an email that contained nothing but, "Can I get an up or down answer?" I replied, "Probably."  It seemed fair.

If it is your task to create / edit technical information, e.g. how to install software, or a preferred architecture - don’t do it alone. You must take your written result and share it for criticism with members of your intended audience. Have your work reviewed by someone outside of your discipline. You will hate the process, but your readers will love the result.

Wednesday, October 6, 2010

Can I borrow your Lawn Mower

The first job I ever got paid for was mowing lawns. To be precise, I received a pittance for mowing my family’s acre lot. Uphill. In the snow. Both ways. As I got older I branched out to the neighbors, who seemed to be on the same pay scale as my Dad. One time my lawn mower broke in the middle of a job, and I had to finish the yard with scissors. You can’t make this stuff up.

Shared systems, Certified Technology Assets, Reusable Objects, and Infrastructure. These are all terms we use to discuss the value associated with reduced complexity, reduced costs, and improved scale, governance, and agility that comes with leveraging a solution across applications. I got to thinking about this just last weekend.

I was outside pushing my five year-old mower over my still-brown-from August lawn, and noticed how much greener my next door neighbor’s grass was. He always mows on Wednesdays. Two doors up from me lives Mr. Riding-Mower-with-a-Canopy, who manicures his yard every week. Twice. There’s one in every neighborhood. Today, he’s washing his driveway.

It occurred to me, that in 25+ years of home ownership, I cannot recall a single time when I was out cutting my grass and one of my neighbors was cutting his. Don’t get me wrong, everyone in the block takes care of their lawn, and I don’t think any of them pays for a service - they do it themselves. And yet - no two of us are ever mowing at the same time.

Being an advocate for shared systems, I began to consider the logistics of sharing lawn mowers. I figure, that if my neighbors and I pooled our resources we could get one honken mower - canopy, drink holder, and even a GPS. After all I figure, the electrical system is shared by all of us, as are the natural gas pipelines, the sewage system, and even the cable TV. So why haven’t we already taken the obvious step of sharing a lawn mower. Heck, we wouldn’t even need a community calendar - 'CAUSE WE NEVER MOW AT THE SAME TIME!

This issue comes up all the time in the Architecture Review Board. We see some solution that is used by multiple teams and someone asks, “Why don’t we turn that into a shared commodity?” It’s what I call the Lawn Mower Paradox. If shared solutions are good in some scenarios, shouldn’t they be good in all?

No. Most emphatically no! I like the flexibility that having my own personal lawn mower gives me, especially when I’m accountable for the way my lawn looks. I get it; each home owner could never build their own water supply or electrical grid. A municipal sewage system really is better than a septic tank, and I really, really don’t want Mr. Wash-His-Driveway dorking around with natural gas pipes.

And yet, having a mower to call my own gives me options and flexibility that a community solution would not. In this case, flexibility trumps costs. But what about a lawn service? Some communities collect an association fee and use some of it to pay for landscapers to address their lawn care needs.

A lawn care service is illustrative of two important points. First, accountability for the lawn’s appearance shifts from the homeowner to the lawn care provider. Homeowner flexibility is no longer an issue. Second, a lawn care service is significantly more than a shared mower. Just because two business units have a common need, does not mean that sharing a common product addresses that need, anymore than two homeowners sharing a lawnmower addresses all their needs.

Shared technology assets are good, and where technology, accountability, governance, funding, and execution can all be combined into a customer-centric product or service, consolidation should be considered. But it isn’t wrong just because there are two, or three, or more of something. Other factors, such as accountability or flexibility could be more highly valued than commoditization. Got to go, it is fall and I have to buy a new rake. Wait, what if....

Sunday, September 19, 2010

Muli-tasking - Good for Computers, Not so for Humans

I’m at my desk working on some task; maybe it’s a budget spreadsheet, a new Java class, a PowerPoint presentation, or Heaven only knows what.  Architects do a lot of varied tasks. The key point is that I need to focus and get this done.  Today.  No matter what.

Ping - my instant message window pops up; “Hey ya.”  “Hey ya” ?? What is that?  Should I respond? Should I remind myself yet again to sign out of IM before beginning a task.  I wonder if there is a send-an-electric-shock feature I can employ here.

Now let me rant for just a moment.  Most IM solutions allow you to indicate that you are not to be disturbed, and furthermore allow you set set up exclusion lists so that your manager and best-work-buddy can still see you as available.

If you have not set out the Do Not Disturb sign you are OBLIGATED to respond to requests - that’s social etiquette for instant messaging. If your status says you are available - then you are. Imagine walking into a business with an “Open” sign only to learn they don’t really mean it.

On the other side of the chat, that initiator also has a responsibility to never, never, never initiate a chat without expressing what the chat is to be about.  “Hey ya”, “you there?”, “hi”, and all other greetings are actually rude and boorish behavior in the world of instant messaging.  Managers - this applies to you too.

All chats should begin with “Hey ya (or something similar), do you have a moment to discuss {fill in the subject here}.”

/end of rant

OK, back to me at my desk... Ring. Wait for it..., wait for it... Ring #2... now I can see the caller ID.  Drat - I know this person, and should probably take the call.  Why couldn’t it have been a vendor - that’s why we have voice mail and 337.

“Hey, did you get my email?”  What?  Did you actually ask me that?  When was the last time you sent me an email and I didn’t get it? You - “Ahh, let me check.”  “Sure, it’s here.”  Them - “Good, ‘cause it’s important I get a response soon.”  “Sure thing, I’ll stop everything to address your critical email about the meeting TWO WEEKS from now.”

Click.

Back to my must-stay-focused on thingy.  Wait, what was that other email with the subject line: “REQUIRED ACTION: ...” all about.

And so it goes, all sanity depriving day long.

If I’m lucky I’ll complete my assigned task, although to be completely fair - it won’t be the result of my best unassailed thinking. It will be the best I could have produced given the conditions under which I work.  But, as it turns out, we have more control over those conditions than we might think.

But first things first. Interruptions matter, they matter in a measurable way, and they negatively impact productivity, reasoning, timeliness, and quality.  

John Medina is a developmental molecular biologist, an affiliate Professor of Bioengineering a the University of Washington School of Medicine and the author of the book, Brain Rules.  He is an expert on how the brain works at the neuro-molecular level.

According to Medina, humans cannot multitask.  When one attempts to multitask, such as responding to an instant message chat, they take 50% longer to complete a task - minus the interruption time. If a task could be done in five minutes, and you are interrupted for two, the original task will now take 7.5, not counting the two minutes of interruption. Total time would be nine and a half minutes (9.5 = 5 + 2.5 + 2).

Furthermore, an interrupted person will create 50% more errors even though they are spending more time.  In other words a five minute task, stretched to 7.5 will have more errors even though one would think that the need for the extra time was because the worker was double checking their output.

Here’s one - merely reaching for an object while driving a car increases your chances of being in an accident by nine times.  Humans ... cannot ... multitask!

Since interruptions can be shown to have a negative, measurable impact on the quality and delivery of our output, we need to control them.  There are a number of strategies for minimizing interruptions.  Most of the following assume you work in a non-customer facing environment - naturally there you must always respond.

  • Block certain periods of the day to deal with the telephone, especially voicemails.
  • Do the same for emails, rather than responding to them all day long.  Do you have a popup or other “You have Mail” indicator?  Lose it.
  • Set your instant message client to “Do Not Disturb” when you need to focus, and feel completely free to delay responding to “Hi”, or chat requests that are not clearly urgent.
  • If you can, remove yourself from your typical work venue.  I have the ability to work from home, and those are by far my most productive days.
Want to multitask?  Grow another brain, ‘cause the one you have can’t do it.  Need to think?  Control your interruptions.

Monday, September 6, 2010

Enterprise Architecture Top Ten

I think sometimes we lose track of just how much there is to know in our industry when attempting to design a new business solution.  For a moment, let’s put aside all of the business information that is, in and of itself, overwhelmingly complex.

We have architecture options for the user interface of an application, for the business logic, and for database connectivity.  There are options for abstraction, encapsulation, inheritance (multiple, singular, and interfaces), and coupling.  Architects have to select the appropriate solutions for synchronous or asynchronous connectivity, for batch or real-time.

And the list goes on.  In my company we maintain an Architecture Body of Knowledge, which is affectionately referred to as the Architecture wiki.  It contains all of the detail, all the guts of our architecture organized using the Zachman Organizational Model for Enterprise Architecture.  It represents our reference architectures, our dictionary, our goto (can I use that term?) for all things architecture.

Overwhelming
But the Wiki can be, in a word, overwhelming.  We have about 300 individuals in the organization that need to reference our Architecture Body of Knowledge.  Over the course of a year, this wiki sees about 45,000 hits.  Do the math and you find that this repository is being referenced all the time.  The numbers indicate that it is a valued resource, which is being referenced again and again.

Imaging trying to learn the English language by reading the dictionary. All the words are there, as are rules for grammar, examples of sentence structure, phonetics, spelling, and punctuation.  Still, no one would think of using a dictionary as a tool for learning the basics.

Top Ten
We have a Top Ten list for internally developed applications, for mainframe applications, for application security, and other architectural areas that could otherwise be tough to navigate and understand.  Now here’s a little secret - we actually developed the Top Ten lists BEFORE delving into the guts of the wiki to flush out all of the architectural details.  We did this because our (your) architecture standards must be usable - and by that I don’t mean that they must be correct, I mean that standards must be understandable by the using community.

If you don’t yet have an architecture repository, or you have one that isn’t generating the activity you’d like, think about how easily your user community (a.k.a. the architects) can comprehend your positions, practices, and policies.  A Top Ten list is a great addition.

Friday, August 27, 2010

It Takes a Licking and Keeps on Ticking

A good friend of mine was making fun of my watch - it’s a basic model, with numbers on the face, a leather strap and a crown/stem to wind it up. Yes, that’s right, my watch does not have a battery, it's the old fashioned spring-driven kind that needs to be wound.

My friend, we’ll just call him Mr. GottaHaveTheNewStuff, created far too much entertainment at my expense over the ancient nature of my time piece - a device I might add that has not made a single unfavorable comment about him.

“When you bought the watch, did they chisel you a receipt or use parchment?” “Do you tighten the spring with a hand crank?” har dee har har, and on and on.

I'd like you to know that my watch is a family heirloom handed down to me from my grandfather who was Sergeant in World War I, and who’s very life was saved on the battlefield by that watch - which means that had it not been for the watch, I would not exist. None of this is true, but I'd like you to believe it.

No, my watch is a $10.00 Timex purchased at a Revco about 30 years ago. I have replaced the strap twice, and had the stem fixed at a mall kiosk in ‘95.

But it works. Mr. GottaHave reminds me that both Revco and Timex Corporation are now defunct (Timex was actually restructured) and so my watch is COMPLETELY out of support, antiquated, and ugly - unlike his iPhone which is fully supported and provides accurate time (to the second) regardless of continent - and looks really cool.

At some point the watch will cease to fulfill the function for which it was purchased; maybe it will break, or maybe it’ll be superfluous with the other gadgets I carry.

The same could be said of our VisualBasic applications. I know that as an architect, and someone who loves new technology, I should be all chagrin over the presence of VB6 applications within our domain. Frankly, as long as they’re still providing value, I’m not sure we need to aggressively replace them.

Yes, Microsoft dropped support an eon ago, the developer tools and the runtimes squeak when loaded, and that acknowledging you have them in your inventory is like admitting you sleep with a Teddy Bear. "What, you have a what?"

Most applications have a life span of a few years; some will surpass that significantly, but most will die on their own terms because the business function they support either changes, gets absorbed into something else, or just goes away. Software is frequently depreciated over three years - so that should provide some insight into the longevity of most applications.

Now, torturing this analogy a little longer, I'm not suggesting that anybody go out and buy a 30 year old watch, or that any watchmaker build a stem-based, spring driven timepiece - i.e. building or enhancing a VB6 application is a bad idea in 2010, but so is replacing technology that is providing value.

If you have a VB6 application that is providing a critical function and is being actively enhanced or sits on workstations outside your control - you should be replacing it. Otherwise, wind the stem, be gentle with the strap, and let time take its course.

Wednesday, August 18, 2010

Needles, Haystacks, and Theories of Relativity

Comedian David Brenner hit the late night talk shows in the 1970s with a bit that included the line, “Of course you always find things in the last place you look; who would find something and then keep looking for it?”

The answer, interestingly enough, is Albert Einstein. Turns out our national treasure, developer of not one, but two theories on relativity, and one-time Patent Clerk often kept looking for things he had already found. Maybe that’s why he gave us a second theory.

Stay with me for just a sec... Einstein’s Special Theory of Relativity deals with space and time, but didn’t explain the effects of gravity - thus the need for a second theory.

Asked about his approach to problem solving he once remarked that most people, when looking for a needle in a haystack, stop looking once they found one. He however, was compelled to keep looking until he had found every possible needle.

More to the point, even though he revolutionized our thinking about the universe, he recognized that his first theory wasn’t sufficient, i.e. the first step in solving a problem is in recognizing that you have one.

When you are trying to solve a problem, maybe how to get access to some necessary data that resides outside of a system you own - do you stop thinking about the problem once you have found a solution? Or like Al, do you keep examining the haystack, until you have considered every possible solution?

Henry Louis Mencken was quoted as saying there is always an easy solution to every human problem - neat, plausible, and wrong.

Can you evaluate your own solutions with emotional detachment and identify shortcomings? If so, that is step #1 - i.e. recognizing when you have a (continuing) problem. The next step is to continue looking for needles / solutions in your haystack / problem domain.

Of course, you need to know when to move on, so somewhere between David Brenner (stop searching after the first ‘solution’) and Albert Einstein (exhaust every conceivable possibility) we should find happiness as corporate vanguards of progress.

Thursday, August 12, 2010

Is "Because I said so" ever a good reason?

My kids are not permitted to read this post. Ever. Imagine for a moment your life is in the hands of another person; maybe you’re on an operating table, maybe you’re on an airplane in bad weather. The situation is grim, and the outcome of the event is based in large part on the decisions made by someone in charge.

To be fair, architects are rarely consulted in such situations - and for good reason. By the time "an event" is in progress the architect’s work is done, has been done, and other folks are responsible for using, fixing, cutting, closing, or landing the subject of said architecting.

The core question is still valid; when the decisions have to be right, when the final solution is really important - life and death important - how do you want the process to unfold? Would you want a highly trained specialist with years of experience, such as a pilot, or a surgeon, or an architect directing the efforts by providing unquestioned leadership, a steady hand, and a cool mind?

This kind of venue, one led by a highly educated, trained-to-the-extreme, with years of hands-on, real world, practical experience is exactly the kind of situation that has led to countless medical errors, airplane crashes, and incalculable disasters.

In 1978, United Airlines flight 173 crashed outside of Portland Oregon killing eight people and injuring 24 others because the pilot was tying to figure out why the landing gear indicator light would not come on. Turns out, the gear was correctly in place - the light was broken. The pilot was so distracted by the light he didn’t see he was out of fuel - even though the fuel indicator, the low-fuel warning alarm, and the others in the cockpit all did their jobs correctly.

Prior to that incident, an airline pilot was considered almost God-like with a respect and authority that no one could question. As a result of the ‘78 crash, the airline industry developed a decision making strategy named Cockpit Resource Management (CRM). There’s a lot to it, but the salient point can be summarized as follows:

See it, say it, fix it.

The goal of CRM is to capitalize on the diversity of viewpoints that surround a critical decision making process. All of us are smarter than any of us. As a result of CRM, the number of pilot-caused crashes, a number that despite all training attempts refused to decline from 1940 to 1990, suddenly began decreasing.

But the interesting fact is that CRM has been employed in other venues with the same result. A study at the Nebraska Medical Center resulted in the percentage of "uneventful cases" of cardiac surgeries rising from 21% to 62%. This happens as a consequence of workers feeling free to question the decisions of those with more expertise and / or authority.

In our Architecture Review Board meetings we try to foster this “anyone can chime in” environment, and lots of times our experts are asked how and why we operate the way we do.  This all leads to better understanding, better decisions, architecture, and solutions.

No one is suggesting that we permit insubordinate, unprofessional, out-of-context chatter to invade our organizational hierarchy. And of course, time sensitive (a.k.a. ticking bomb scenarios) decisions must fall to the accountable entity. But, if CRM can make proven, measurable, critical improvements by fostering an environment where the thoughtful expression of diverse views are encouraged - then architects should be willing to listen to, accept, and incorporate the ideas and suggestions of others.

Wednesday, August 4, 2010

You like Jam - But why?

“You can clearly see nothing in the box” is an opening line to a magic routine that ends with bountiful gobs of colorful artifacts emanating from within.  But carefully consider this phrase - did the magician say that the box was empty?  No? Yet, is that not the impression one would have upon hearing the words, “clearly see nothing in the box?”

Many years ago, as a budding prestidigitator, I made a promise that I would never lie to the audience.  Thus, I used clever phrasing to lead them to conclusions of their own making.  Later as an IT professional (magic it seems doesn’t pay all that well), I found that fulfilling user requirements was almost as difficult as divining the secrets of Houdini, Blackstone, Copperfield, and Paul Gertner. Maybe it was just me, but it seems the more information I gave my users, the more they changed their minds.

How we decide is the title of a great book by Jonah Lehrer which covers a lot of ground, but has one particularly interesting chapter that all IT decision-makers should read.  It begins with a simple question, “Which brand of jam do you prefer?”

In the 1980’s, Consumer Reports brought together a group of sensory experts along with the leading brands of jam.  They then ranked the jams by sixteen different criteria.  A few years later the University of Virginia replicated the test with undergradute students and came pretty much to the same results.  So much for sensory experts.

But when the University asked the participants “Why” they chose as they did, the participants started to introduce all kinds of new variables into the equation, and (and this is the key point) they changed their minds.  Jams that once rated high, were rated poor and vice versa.  In Lehrer’s book, he makes the point (based on significant research) that given lots of extraneous data our rational minds tend to invent reasons to use the additional data, often looking for patterns that simply don’t exist.  

Consider the research performed at Stanford and Caltech involving wines priced from $5.00 to $45.00 per bottle.  The more expensive wines were consistently selected as being better when, in some cases, the wines were from the same bottle; just priced as if they were different.  These studies of how we make choices have been conducted under rigorous conditions including MRIs to provide clear evidence of how our brains are making each decision.

In short - given more data (such as the price of a glass of wine) our brains will attempt to use that data to “improve” our decisions - - even when the additional data has no bearing on the quality of the product, choice, or outcome.

If you are tasked with selecting a vendor product from a group, limit the number of variables to the elements that truly matter (no small task), and avoid looking at more data - even as a tie breaker.  If the core data elements cannot distinguish one selection over another; go with your gut - don’t add more data.

Wednesday, July 28, 2010

Attention: Worldwide Shortage of Buttons

"Warning Will Robinson, Warning; There is a worldwide shortage of buttons." Electronic devices will soon be inoperative. Clocks, digital cameras, stereos, and blenders will soon be at risk. Architects, you must conserve buttons where ever possible by assigning every button, knob, dial, and slider to multiple functions regardless of usability.


This message must have been distributed to electronic device manufacturers as it is the only explanation for how the modern conveniences of my life made it out of their respective QA labs.  Take for example the clock in my Saturn Vue, a vehicle that in most other respects is usable. Here are the instructions for setting the time:

Press and hold the RCL button and at the same time press the HR (AUTO EQ left) or MN (AUTO EQ right) arrows. You will hear a beep indicating that you can change the time. Release the RCL button and press HR until the correct hour appears on the display. Press MN until the correct minute appears on the display. The time can be set with the ignition on or off.

The RCL button - what is that? What does RCL stand for - Really Cool Looking? Random Chaos Liquidator? And why do I have to hold down this magical RCL button and then contact Human Resources - or does HR now mean something different? Why am I holding down two buttons that have no apparent relationship to the task at hand when, at least theoretically, someone could have provided a single button that reads “Set Time?”

On what planet are these things designed - do the architects of these solutions understand that their users actually have opposeable thumbs, but are otherwise hampered by being telepathically-challenged.

I’ve written before about my loathing for alarm clocks - not because they wake me from blissfull slumber (although that would be enough) but because the buttons have been combined to perform multiple functions, the most important of which is “Shut Up!” And that particular button is insufficiently sized when you consider my state of dementia, blindness, and coffee-deprived motor control.

It seems every button on my clock, phone, media player, coffee maker, and geesh - mouse has to perform at least three functions depending on what other buttons are pressed, how long they are pressed, the sequence of pressing, the angle of the sun, and whether I’m leaning the button in a easterly direction. Give me a break - - are we running out of buttons?

I like my keyboard. There is a separate button for every letter I could possibly want to type. Of course, I have to look at the keyboard as I type, because when I look at the screen the buttons start rearranging themselves. I think my keyboard is in collusion with my clock.

I guess the point is that simple is not the same as few; as in a fewer number of buttons does not mean a device is simpler to use. More broadly, a fewer number of interfaces doesn’t necessarily translate into an easier interface to use, support, or describe. Since we know that more isn’t always better, and fewer isn’t always better - we’re left with striving for clarity. Design for clarity, even if it costs a few more buttons.

Monday, July 19, 2010

Inception: A Great Movie for Architects

I love going to the movies.  My son and I see about 40 a year, so when we see something which is well done, fresh, and entertaining, I tend to notice.

This is not an endorsement of the movie, a cinematic review, or a spoiler.  Rather, I wanted to explore a core plot concept that, as architects, we should be thrilled to see fully developed in a major motion picture.  

It’s easy to get lost in the film’s visual topographical contortions and the resulting points of stress that would surely surpass the bounds of architectural limits.  Watching a city fold on top of itself (this is in the preview) presents an architect with immediate impossibilities that pervert the laws of gravity, physics, and spacial relations.

But it is when DiCaprio’s character, Dom Cobb asks “What is the most resilient parasite?” that all of us should take notice.  Fortunately, he provides us with an answer right away - more so than a virus, a germ, or an insect, ideas are far more resilient.  Once an idea is successfully implanted in our minds, it’s life is all but guaranteed.

If you enjoy the cinema, these data points from four very well-known movies will cause you to recall some really great stories, but also remind you that once an idea is presented, you can’t un-know it:

  • He’s already dead
  • He’s blind
  • His sled is called Rosebud
  • He’s Luke’s father
The first time you viewed these films you were likely caught off guard by these ideas, such that knowing them changes the experience.  You cannot simply un-know them - and you cannot watch the movie again as you did the first time.

As architects it is our mission to develop solutions based on a few simple concepts (loose coupling, cohesion, abstraction, etc), and furthermore to express these solutions in such a way that, like an intellectual parasite, they become obvious, entrenched, and unforgettable.  

Inserting these architectural virus-like concepts into our solutions not only makes our jobs easier, it enables us to deliver on our business needs for faster times to market, greater resiliency, scalability, and flexibility.

Thursday, June 24, 2010

Plumbers Are Your Friend

In 1985 my wife and I bought the home of our dreams - if you define 'dreams' as an unending money pit of despair, toil, and loathing.  For 23 years I spent every Sunday at my local religious outlet, a.k.a. Our Lady of Home Depot.  I am now a Deacon of said house of worship having learned a wide variety of skills such as never trust a 1" x 1" color sample no matter how good it looks in the store, and that standard sizes for plumbing fixtures weren't really established until after my house was built.

Do you think your businesses (or customers) really care that you need to extract data from one database, transform it into a new scheme, and then load it into another database?  Stay with me - this all connects.

Funny thing about plumbing - half of your house is under constant pressure to leak, while the other half is the docile partner of gravity. Leak - what a plain and simple word that by its single-syllable phonetic seems to imply gently calming flows of relaxation and peace.  Trust me when I say, I never had a pipe leak in my house - they always exploded, and not in the acceptable big boom, mushroom cloud, dust settles kind of a way.  No, my pipes exploded and then kept right on exploding, sending laser controlled, skin piercing, eye stabbing, guided missiles of water spears towards freshly painted, newly dry-walled, recently carpeted rooms.  At night.

I became reasonably skilled at pipe hacking, and learned how to use a propane torch, the silly plumber's wax, and solder.  My joint repairs usually held, and if they didn't, they tended to weaken quickly so I could fix them right away.  At some point in the 23 year flip of the "house-of-while-you're-at-it," - time became more valuable to me than money or pride, and I actually hired a plumber.

Plumber - I just like the sound of that word.  'Plum', silent 'b', 'er.'  The fact is, no one visiting that house could have cared a lick if I soldered the pipes myself, or if a highly trained, dedicated, focused on one specialty professional technician did it.  So long as the water entered the appropriate receptacles in the manner, location, and intensity it should, and exited in an equally appropriate clockwise rotation within the confines of Newtonian mathematics - everybody's happy.

Like many enlightened citizens of the world, I do not feel a loss of control over my home merely because I delegated a highly specialized task to a specialty supplier.  I work for a large financial institution and we have a whole collection of specialty suppliers in our company providing business capabilities in the form of Common Technology Assets.  These CTAs range from long-time established Web Hosting solutions (now with .NET!), to brand spanking new Portal Platforms.

Leveraging these solutions does two things, and most definitively does not lead to a third.  Leveraging CTAs reduces costs for the corporation as a whole by avoiding duplicating efforts across lines of business.  Secondly, the less time I spend on plumbing - a task for which I am good, but honestly not great - the more time I can spend on things that really matter to the visitors of my home.  The more you can delegate to a CTA, the more time, energy, and costs you can dedicate to things which differentiate your business in the market place.

By offloading my pipe wrenching (pun) tasks to a professional plumber, I was able to spend more time understanding how various colors affect guests in my home, and how to make them feel more at ease, more willing to engage in conversation.  I now had time to slay the serpent of 1" paint squares.

What CTAs do not do in any way shape or form, is wrestle control away from you.  My plumber may have his building codes to follow, but I'm still his customer.  If he doesn't / can't / won't meet my needs, I can go back to doing it myself, i.e. there is always another plumber available.

Wednesday, June 9, 2010

CIOs - Would you like to get 100 Mpg?

Last year, I traveled home from my favorite vacation spot in my 2008 Saturn Vue and achieved about 30 miles per gallon. This means I got a little more mileage than Henry Ford's Model T - it got about 25 mpg. We put a man on the moon, landed a spacecraft on Titan, drove two toaster-cars on Mars, and can even get suckers like me to shell out $14.00 for a 3D movie about blue aliens in loincloths linking their tails with domesticated pterodactyls; and yet squeezing 100 miles out of a gallon of gas seems to be too hard.

Well - everything is a trade off. In 1935 Charles Nelson Pogue (no relation to Rielly) of Winnipeg, Canada purportedly developed a carburetor that could get 200 mpg. Turns out that even if you could get extreme miles per gallon it would come at a cost of having a car will no power, or bumpers, or anything else. Even today's high mileage cars come at a cost of being small, lightweight, and being slightly larger than Hot Wheels.

I'm looking over the architecture of the newest incarnation of our internal Web Hosting environment. Stay with me, this is relevant. The design is based on servers with multiple cores, employing VMWare with multiple instances of an Operating System, on which we'd load a Web Application Server system (like WebSphere), in which we'd run multiple applications for a single line of business.

OK, so maybe I lost you, but the point was that the configuration is complicated and is based on a series of decisions to isolate resources in some cases and share resources in others.

So we asked - what drove the designers to this particular configuration? Why not give each application its own server (a blade?), its own operating system, its own application server, and its own memory stack? Well, they said, the selected configuration was a negotiated balance between cost, performance, and scalability.

Excellent answer. Excellent answer except there is no communication that says our business model over the life of this investment will be to sacrifice scalability in order to minimize costs and performance. Nor do the architects have any direction that scalability of the platform should be diminished for 3-5 years in order to save on one-time capital investment costs.

You can't get 100 mpg with power to pull your boat from a four cylinder Escalade - it's not that they don't make it - it's that it's not possible. So what do you want from your car over the life of the loan? Luxury? Towing Capacity? Fuel Efficiency? If you don't tell your architect, you are going to get a Ford Taurus. Not too fast, not too efficient, not too much power.  Not a bad car - if it's what will meet your aspirations.

Given that we'll depreciate the cost of the Web Hosting platform over time, we ought to be sure that the architecturally-based quality attributes are aligned with the business aspirations over the same period.

CIOs, you have a strategy for a few years out. Make sure your architects fully understand the business aspirations and goals so they can ensure you have the capabilities to meet them.

Monday, May 24, 2010

Keep it Simple, Stupid

"Make everything as simple as possible, but no simpler." I'm not sure if those are the exact words of Albert Einstein, but he has been credited with them for so long I assume it to be true. Often times the best pieces of advice are the ones that, when stated, are mind numbingly obvious.

I've written before on the perils of over-architecting a solution, most notably when trying to build systems that replace humans. As I see it, we are either the result of Divine intervention or the outcome of 4.5 billion years of evolution. Electronic digital computers have been around for about 50 years give or take - so I'm just guessing they're not ready to terminate us.

It is the intelligent integration of computers and humans that yield the best results. In 1990 I had the opportunity to design a new computer system for the USAir Control Towers; to be used in a number of their large hubs. We spent almost an entire year gathering requirements, observing the manual system that was in place, and flying all over to observe how other airlines across the globe approached the problem.

The general consensus was that the decisions necessary to manage the flow of aircraft to and from gates, with fuel trucks, catering vans, baggage, and crew traffic was just too complicated for humans. The airline business had grown too big too fast for human processing to handle it all. My team saw it differently.

This was not a situation where we wanted to replace humans with computer programs and artificial intelligence - even though that was all the rage. We saw it as an information visualization / assimilation problem. In short, if we could harness the processing power of the computer to render the planned state of the airport, along with the current state, highlighting conflicts and mismatches, then humans could easily assimilate the conditions and adapt. The manual process required about six weeks of on the job training to master. The solution we designed could be understood in about an hour, and mastered within a work week.

At the most fundamental level this was an architectural issue, and choosing wrong could have led us down a rabbit hole of Expert Systems, Artificial Intelligence, and Rules Engines long before the technology existed to support them. By focusing on the user needs, and understanding the problem domain, a solution was delivered that was as simple as possible, but no simpler. I think Al would have approved.

Monday, May 10, 2010

A Steaming, Heaping, Pile of Architecture

For just a moment, I want you to think of New York City as it was in the year 1900.  The population was 3.6 million, if you count the 200,000 horses that lived and worked there.  The horse is a beautiful animal, one that can work hard - and at the turn of the century, horses definitely earned their keep.  They were used for every mode of transportation, including personal carriages. trolleys, fire 'trucks', and more.  They were literally the engine that moved the city. 

Of course, they also produced waste.  Dung.  Lots of it.  On average, a horse produces 24 pounds of manure a day - given that New York City had 200,000 of them - that means 5 million pounds, or two and a half tons of horse poop.  Every day.

Where does one put 5,000,000 pounds of horsey-poo when one knows that another 5,000,000 pounds is coming tomorrow? Vacant lots in the city had piles of the droppings 60 feet high.  The next time you admire the elegant steps adorning the front of a New York  brownstone, remember that the first floors of these homes were elevated to get the windows higher than the piles of equine evacuates. 

This was not a humanitarian and ecological disaster for New York alone.  Every major city in the world was suffering the same fate.  In fact, in 1898 the world's first urban planning conference was held for ten days in New York City, with the primary focus being, "How do you solve a problem like too much horse dung."  The conference ended after only three days because all attempts at solving this crisis were deemed fruitless.

In 1900 a New Yorker was twice as likely to die in a horse accident as was his great grandchild in 2007 by an automobile.

And then - it just went away.  The slow steady advent of automobiles reduced the use of horses, and their 'output' and in a span of twenty years significantly improved the environmental conditions of urban living, including a reduction of feces-based disease and illness, unbearable odor, and unimaginable noise. 

Remember that the automobiles of that era were not the complex human cocoons of today.  Some didn't even have four wheels or a roof.  No; cars of the early 20th century were pretty basic machines - simple by almost any standard.  In short, a world-wide crisis of epic proportions was solved with a relatively simple solution.

Other examples abound where we tend to think that because a problem is big, the solution must be equally big. H. J. Heinz had a terrible problem in that customers demanded thicker and thicker ketchup, but habitually complained about how long it took to get it out of the bottle.  Even the rubbery squeeze bottles didn't solve the problem.  Thickness and gravity were enemies and no amount of engineering, physical or chemical was ever going to make them friends.

Until someone thought of putting the opening of the bottle on the bottom.  Simple.

IT professionals live in a complex environment, and the complexity is increasing and accelerating.  We must constantly fight technology inertia - that constant force that promotes ever-increasing levels of complexity.  Just because a problem seems insurmountable doesn't mean the solution must be equally significant - in fact, the best solutions are the ones that are elegantly simple.

Wednesday, May 5, 2010

One Size Doesn't Fit All

"You go find out what the users want, I'll start coding." Believe it or not, those words, or at least that approach, takes place everyday. Look, most applications are delivered as web sites, and most web sites follow a familiar architecture; three tiered, user interface, business logic layer, and a database. A development team could, quite literally, establish certain application constructs before knowing a single business requirement.

Assuming the platform of choice is Java, we know we're going to need a main servlet, a way of handling errors pages, a CSS file, a JDBC connection, a properties file, a build script, folders for test scripts, a logging framework, authentication plugins, and a whole host of other "general purpose" utilities. All of this can be established before the first requirement is gathered.

In most of the better shops there is an established standard application starter package that contains all of this. It is no wonder then that architects fall into a pattern (we love patterns) that every application looks the same. So why then, do we spend so much time in our Architecture Review meetings, going over the business context before looking at the blueprints.

Consider this picture taken during the construction phase of Three PNC Plaza in downtown Pittsburgh. You'll note the criss-cross of steel I-beams that are typical for a modern office building; in this case the fireproofing has already been applied. But if you look more closely you'll also note that one of the I-beams is considerably larger than all of the rest. Like whoa baby! Did they truck that thing in, or did they just over-fertilize it right here on the spot?

The size of this beam is even more perplexing when looking at the rest of the skeleton, which I couldn't fit here. This was the only beam of this size in the whole of the structure and it wasn't even centrally located. It's not like this was the central support beam for the 23 story building. So why? Why do we have this, why was it needed?

Let's consider the business requirements as depicted in a writeup of the building:

Three PNC Plaza will be a 780,000 sq. ft. office/condo/hotel/retail/parking complex. Designed to meet Leadership in Energy and Environmental Design standards established by the U.S. Green Building Council, the 23-story building is planned to be the largest environmentally friendly, mixed-used building in the United States. Pittsburgh's first new high-rise in 20 years will include: office space; a Fairmont Hotel with "green" guest rooms; 28 condominiums; a restaurant; retail space; underground parking garage; and a pet-friendly public park. A 6000 sq. ft. hotel ballroom will reside on the 2nd floor, overlooking Fifth Ave.

Do you see anything in that description that would indicate a need for the father of all I-Beams? Imagine the steel skeleton of a typical sky scraper, focusing on the vertical beams that support each of the floors. Under what circumstances would a vertical beam cause insurmountable problems? Typical offices deal with vertical beams all the time, no issue there, but a ballroom simply cannot have visual obstructions.

If Three PNC Plaza was to be a typical office complex, the super-dee-super horizontal cross beam would not be necessary. But, because of the mixed use nature of the business requirements, specifically the inclusion of a hotel (which would almost certainly need a ballroom), the architect had to figure out a way to sustain 21 floors of weight above a section of the building where there wouldn't be any vertical support. Thus, the inclusion of a specially manufactured (you don't think this is standard issue do you) beam that is so tall that they couldn't bring into downtown through the Fort Pitt, Liberty, or Squirrel Hill Tunnels. For those that understand how Pittsburgh is laid out, that becomes a logistical nightmare.

Understanding the business requirements is absolutely fundamental to developing a workable architecture, regardless of any prevailing wisdom as to how things should be built. Architecture reviews must begin with the context (business purpose) that the architecture is supposed to support. Otherwise we'll be bumping into ornate pillars when we're dancing to the Blue Danube.

Monday, April 26, 2010

Are you smarter than your GPS?

I've never been great at names, but I used to be able to recall facts and trivia with the speed of a..., you know..., one of those... um,  fast... thingies.  Rats!  As I've aged, my brain requires much more sleep, nutrients, and caffeine than Earth has hours, money, or Starbucks.  Fortunately, having the ability to recall the compatibility matrix for the last three combinations of JDBC, Oracle, and WebSphere is not as important as understanding why loose coupling is critical to system reliability. 

Raw facts, like a compatibility matrix can be Googled, whereas experience, intuition, and instinct is likely in the perpetual human domain.

Author Clive Thompson of Wired Magazine recently did a piece on the Cyborg Advantage, the melding of human and computer capability.  In it, he talks about how Garry Kasparov was defeated in a chess match by an IBM computer (Deep Blue) in 1997.  For many, this signaled the beginning of the age of Orwell complete with Big Brother and Minority Reports. 

But it got Kasparov to thinking about the intrinsic strengths and weaknesses of humans and machines.  Rather than battle one against the other, what if we combined them instead? In 2005 an on-line chess tournament that pitted human teams against humans/computer teams yielded an interesting result.  Not only were the cyborgs disproportionately victorious, but the grand champion was a pair of twenty somethings aided by off-the-shelf chess programs.

This should not come as a surprise. In my car I have a Garmin GPS box that I use to navigate in unfamiliar territory.  I've lost count of the number of times the little witch has told me to turn left when I knew very well that was a bad idea.  Rather than blindly following her formulaic verbalizations of longitudinal lunacy, I leverage my age-enhanced reasoning skill.  She eventually recalculates based on my actual position and provides advice from there.

The point is that the computerized GPS system is used to augment, rather than replace human judgment, perspective, observation, and decisions.  Some of the world's busiest traffic intersections are managed by computer controlled traffic signals.  Still, drivers are permitted to make right turns on red - automation augmented by human judgment.

The architectural point here is to avoid over architecting a solution; essentially removing humans from the equations.  Human processing, observation, and experience can augment computer automation.  Pitting one against the other is a sure fire way to lose the best of both.

Follow by Email