Tuesday, November 18, 2014

Who is your Chief Architect?

If you work in a moderate to large organization there is a better than 50/50 chance someone there has the title of Chief Architect. That's too bad, 'cause it's probably wrong.

There are a number of descriptions for Enterprise Architecture. The one I like says, Enterprise Architecture is the discipline that aligns business aspirations with business capability. For most companies, 'business capability' is driven and delivered via technology.

Given the heavy dependence on technology, it is not surprising that a number of Enterprise Architecture Groups are lead by individuals who have a background in Information Technologies. The leader of such teams are often called Chief Architect.

If your organization has a team called Enterprise Architecture, ask yourself if they are really architecting the enterprise. Or, as I often find, are they performing IT architecture for the enterprise? In many cases this title, "Enterprise IT Architecture" is a better, more descriptive title for the team and its function.

There is nothing wrong with that, by the way. Enterprise IT Architecture is an important and valuable function.

But, if there is going to be a person and or a position that carries the title, Chief Architect, for an organization; who should hold that title.

In most cases, it should be the CEO. The Chief Architect for the organization is the person that determines the foundational and structural elements of the organization, and determines what functions are necessary for success. That's the CEO, president, founder, or other top-of-the-pyramid person.

There are as many permutations of organizations and structures as bullets in Jack Bauer's gun, so your individual situation may be a good exception, but most of the time - the title of Chief Architect belongs to the CEO.

Monday, July 14, 2014

Fred Flintstone, Architect

I love the story of the two architects who were walking in the woods when they came across a disgruntled mother bear. The one architect asks, "do you think we can outrun her?" The other one replied, "I don't have to, I just have to outrun you." Ah, yes - understanding the problem in context.

At the end of every episode of the Flintstones, Fred would attempt to put the cat out. The cat (apparently smarter than Fred) would immediately jump through the open window beside the door. This explains why Fred never became an architect.

Missing the obvious is a human attribute for which we all fall victim from time to time. Psychologist Dr. Richard Wiseman conducted a study whereby participants were asked to count the number of photos in a newspaper. Most of the people were able to complete the task in a few minutes, some took longer because they rechecked their counts. They needn't have bothered because page two of the newspaper contained a headline with a typeface 1 1/2 inches high which read, "Stop counting, there are 43 pictures in the paper."

I love this picture and use it frequently to make a couple of points. First, take a close look and make sure you can spot the gate arm that is supposed to stop cars from entering and exiting the parking lot. Now note that as a car enters the lot (from the top of the picture moving downward), there is no place to insert a ticket or otherwise identify the car or driver. Therefore, the gate must just open automatically. For everybody. Well, maybe this is a heavily trafficked area and the gate serves as flow control. Hmmm, the serenity of the narrow streets and grassy lawns would seem to suggest that traffic congestion is not an issue.

Of course, there is the obvious indication that the gate merely impedes traffic for no apparent benefit, as evidenced by the turf marks clearly seen in the light snow. Good designs just work. This one doesn't. No one planned for this gate to be useless, in fact, there may even be a good reason for it. But, this particular design fails. If you are interested in application security, this would be a good example of how a bad design only considers the users that want to follow the rules.

If you are a user interface designer, this is a good example of how an 'intuitive' solution can be misused. Oh, the lessons that can be learned from this one photo are nearly endless. How about this; when a important task is at hand (in this case, maybe... getting home?), people tend to use the path of least resistance. Think about the solution you are designing right now; is the use of the solution (in the eyes and hands of the user), the path of least resistance?

Monday, July 7, 2014

How Much Progress is Enough

There are days when you just know you are right. It may not happen often, and certainly not with every topic, but it happens - and there is nothing more frustrating than knowing to the depths of your knowing-place that the path upon which others have set is incorrect, poor, or well... wrong.

It's not that you are a genius, have special cognitive powers, or stayed at a Holiday Inn just last night.  No, in this particular case the Gods of insight have bestowed upon you the analytic mind of Sherlock Holmes, conviction from Joan of Arc, and the confidence of Cliff Clavin.

Now what? You've used your best Engrish, color coded the white board, wasted three good napkins, and even developed a PowerPoint that will get honorable mention in the Picasso home for the symbolically senile. You've said "yes but" more times than a filter inspector at a Marlboro factory. Still - the wisdom of the masses, or maybe the blindness of a single individual stands between you and perfection, ... or mediocrity, or ... not-as-much-suckiness.

In 1943, author Ayn Rand (a name I still cannot pronounce with sufficient confidence) wrote a book called the Fountainhead; which was the quintessential treatise on the intersection of architecture and individualism. The struggles of the main character, Howard Roark, are as notable today as ever.

Roark would feel right at home as an IT Architect - ever striving for perfection, delivering absolutely perfect designs that are guaranteed to function even after all the Internet tubes are filled up.  Roark would understand.

IT Architects are constantly in a position to see our solutions implemented at less than full design. We are perpetually perplexed with how hard to push, how much purity to pursue, and how much intellectual pollution we can pardon.

It is understandable that some of our best people just stop caring, and as such, stop being our best. The hardest part of being an IT leader is that you have to balance the internal fire and drive that makes you care against a personality for which others couldn't care less. Winning one technical battle today can lead you to a path that loses the war of opportunity tomorrow. Remember that even a little progress counts as progress.

Advocate. Push. And while you may need to give in from time to time, don't ever stop caring.

Monday, June 30, 2014

Architecture Purity

What would you get if you put a drop of sewage in a barrel of wine? 

Pretty much the same thing you’d have if you put a drop of wine in a barrel of sewage. i.e.  sewage.  Personally, I wouldn’t drink from either barrel. There is something to be said about contamination, even a tiny bit of it, rendering a solution as sewage.

We should always strive for perfection, especially in wine and art, or even in architecture. That being said, we can get carried away with the notion that architecture exists in only two states; perfection and sewage. While we should strive for perfection and avoid sewage, we should accept any endeavor that causes a state which is an improvement over a previous state.

In the Architecture Review Board we’ve seen hundreds of solution proposals going back almost ten years. I don’t know that I’ve ever seen one that was considered perfect. I like to say that every solution has “an ugly” and that you want to try to minimize the uglies, and if possible, put all the uglies in a single spot (a drop of sewage?).

Still, we hear from some architects that “it’s not perfect.” “It could be better.” They’ll say, “The ARB should not approve an imperfect architecture.”  OK, let’s stop business while we (A) argue over the definition of perfection, (B) find the funds, timeline, and resources to accomplish the as yet undefined perfection, and (C) convince the rest of our market space, including all our vendors to stop innovating because that tends to change the details of the still undefined “perfection.”

Or how about this; let’s define road maps.  A road map offers a series of incremental improvements over time that allow us to change with market and technology conditions so that we advance both the business capability as well as the architectural soundness.  That might not sound as bold as “Re-write from scratch” but it has the added advantage of being continually re-accessible - you can correct your course based on the prevailing and changing conditions.

We should value perfection, but we should value improvement even more.  Road maps enable a team to achieve improvement while remaining flexible to market dynamics.  Hmm, sounds almost perfect.

Monday, June 23, 2014

A Mild Mannered Architect's Advice on Policy

I'm a reasonable guy. I understand that I am not capable of being an expert in everything. It's hard to be a expert in any one thing, let along two or three. Forget being the voice of authority on hardware, and software, and warp drives, light sabers, radioactive spiders, and the wingspan of an African Swallow.

As a passenger on an airplane, I don't need to fully understand the mathematics underlying aerodynamics, lift, and drag to know that $5.00 is too much for a can of Coke. My appreciation for the rings of Saturn is not based on the Newtonian model of gravitational force. I get it, I don't need to know every detail to have an appreciation of the forces and rules that govern our lives.

But...

Do not negate my questions with, "It's policy." When I ask why the best blog site dedicated to addressing tough Javascript issues is blocked, don't just snort, "It's policy." When I inquire about adding an extra video card to my Developer Workstation, do not say, "Can't have it, it's policy." And when I want to know if I can use Open Source Software, don't even try the Jedi policy mind trick on me. Consider me Toydarian!

"Policy" is not an answer; it's an admission of inadequacy. It's shorthand for "The answer to your question is beyond my limited vocabulary which prohibits any form of intelligent response." Policies exist for a reason, and if a policy mandates or prohibits a particular action, then anyone and everyone in a position to enforce the policy should have the three neurons necessary to articulate the reasons on which the policy is based.

If you're in a governance role having to implement policies, then you likely have to deal with schlucks like me who ask dumb questions and whine about why I can't get every little desire that pops into my head. Nonetheless, you have the responsibility to express the rationale, in consumer-centric language, for the policies you enforce. You have the responsibility to elevate understanding.

Furthermore, and this is dedicated to all of the future mall cops of America, all policies are based on a context. In the absence of the policy's context, the policy is null, void, unfounded, irrelevant, non-sequitor, perpendicular, passed on, expired, gone to meet its maker, a stiff, bereft of life, it rests in peace, its pushing up the daisies, its kicked the bucket, shuffled off its mortal coil, run down the curtain and joined the bleedin' choir invisible. It is AN EX-POLICY!

We need policies, they add structure to our world, and reduce our work-set, allowing us to focus on the unique. We do not need drones, anti-social misfits who aspire to spend more alone time with their Book-O-Rules. Advance the understanding of why we operate the way we do, and we all get better, smarter, and more effective.

Monday, June 9, 2014

How Do You Measure Up?

One of my life-long idols, Muhammad Ali is quoted as saying, “The man who views the world at 50 the same as he did at 20 has wasted 30 years of his life.” Can you point to a specific situation where you have changed your mind? On the topic of architecture metrics, I’ve come full circle - having changed my position. Twice. 360 degrees. How’s that for an industry that values consistency? By Ali’s criteria, I have made full use of the past 30 years!

I began with the assumption that you cannot improve that which you do not measure. My early career included six years as a retail sales manager in a series of department stores where I learned to read and appreciate the Statement of Operations each month to evaluate my progress against goals.

I’m a numbers guy, and like hard data, stats, and graphs. Trendlines are my friend. It’s a bit geeky, but I am what I am.

I created an IT Architecture program about ten years ago and began looking for the elusive stats to demonstrate both value to the corporation and progress over time. Activity-based metrics were easy; number of projects reviewed, number of hours engaged, number of standards established.

We put everything on our internal web site and tracked usage to show, for instance, that a pool of 300 architects, Lead Developers, and executives hit the web material 60,000 times per year. This served as sort of a value metric.

Over time I became comfortable with the fact that we could never find the direct cause and effect numbers that would prove that our architecture program was delivering more than the cost of the investment. So, we establish this response:

The value of the EA program is not expressed as a number.

Isn’t that cool. It even sounds a little deep. If only it weren't wrong.

Still, we continued to look. I rejected notions like adding up the number of times a project team employed a reusable asset rather than build from scratch for two reasons. First, rarely did anyone build from scratch and so the concept was silly. Secondly, how long do you count using existing ethernet cables as “reuse.” In other words, when do you stop counting reuse as a savings, and start saying, that’s just how we do business.

Then I read Douglas Hubbard’s book How to Measure Anything where he makes the point that the REASON you measure something is to reduce uncertainty. That’s all - you don’t have to eliminate all ambiguity, just some. Architects (myself included) try to find the perfect measures; unassailable, unambiguous, direct cause-and-effect numbers. But what we need is any measure that simply takes us to reduced uncertainty.

With that as a definition it is easy to come up metrics, and we now post several on our executive dashboard. Everything can be measured once you free yourself from the notion that the measure must be absolute. Actually it just has to reduce uncertainty.

Monday, June 2, 2014

I have no idea what you want!

You’re not being clear. I need you to be clear.

I have no idea what you’re saying. Are you asking me to do something? Is this informational? Why did I get this?

Having a reasonable command of the Engrish language, I fully understand each of the words in your email; and yet the combination of characters and phrases results in a complete shutdown of my synaptic activity. I have no idea what you want.

In fact, I think I just lost IQ value as a result of your mind-numbing, time-sucking, spelling-challenged, participle-dangling, soul-killing stream of consciousness that DOESN’T HAVE A POINT!!.

For one example; I received an email that I had to print out, grab an adult beverage, and proceed to read like it was a legal contract. Eventually, after two refills I determined that the author thought he had too many servers in his Disaster Recovery plan (he didn’t).

For Heaven’s sake, couldn’t you just say that up-front? Three printed pages off-topic wandering prose filled with off-purpose “detail” that truly required clairvoyance to fully assimilate.

Look, some topics are hard and require context to understand. I get it. But don’t make me read through pages of narrative to infer your question. Put it right up front, then provide your background.

While I’m at it, would it be too much to ask that you re-read your mash of keystrokes before you hit Send?

As near as I can discern, you wildly stab at the keyboard while ducking poison darts hurled by Ninja Assassins; and with your last dying gasp reach up from the floor to submit a typographically encrypted message for which you require an immediate comment. Comment? I can’t even comprehend.

Spelling is nice; you should consider it. If only there were some spelling checking device built into our communication software. That would be cool.

I’ve written before on the value of Deliberate Practice; an approach that led me to read a new book of the Rules for Business Writing. One suggestion is to always start emails with a single sentence that clearly defines the purpose of the communication.

For instance, I could have started this post with:

You’re not being clear. I need you to be clear.

Monday, May 26, 2014

Find a Giant and Climb up their Back

Are you too old to be innovative? I don't mean, are you able to figure things out like the TV remote, or the microwave, or email. I mean, are you too old to be truly innovative.

A report by the National Bureau of Economic Research (NBER) indicates that for an individual to develop a new idea, they first have to learn and understand the information from previous generations in order to add to what is already known. Absorbing the level of learning required to innovate now consumes the first three decades of life. 

"If one is to stand on the shoulders of giants, one must first climb up their backs, and the greater the body of knowledge, the harder this climb becomes," says the report. See here. The NBER studied the ages of 55,000 patent holders for new inventions and concluded that the average age for true genius to appear is now just under 40, as an average.

Grace Hopper started at the age of 39 on an endeavor that became the first software compiler - ten years later. In her 50's she participated in the invention of COBOL. Benjamin Franklin began work on the Declaration of Independence at age 70; he'd get to inventing bifocals a few years after that.

The poet Robert Frost, did not publish his first book until he was 39.

Janet Rowley, a professor at the University of Chicago medical school, demonstrated that leukemia was caused by chromosomal abnormalities - she made her discoveries in the 1970's when she was in her late 40s and early 50s.

Steven Jobs founded Apple Computer when he was only 21 in 1976. He left Apple for a while but returned as CEO in 1996 - twenty years later, ten years AFTER that, he gave us the iPhone. Not bad for 55, huh! I don't consider myself in these leagues, but I earned my first patent at age 54.

The list goes on.

There is a story President Ronald Reagan once told about his days campaigning on college campuses. Someone said to him, "Governor, we want to talk to you, but I think you should realize that it's impossible for you to understand us - It's sad, but it's impossible for the members of your generation to understand your own children. You weren't raised in a time of instant communications or satellites and computers solving problems in seconds that previously took hours or days or even weeks to solve. You didn't live in an age of space travel and journeys to the moon, of jet travel or high speed electronics." Regan replied, "You're absolutely right. We didn't have those things when we were your age. We invented them."

A study conducted by the Ewing Marion Kaufman Foundation of 600+ CEOs and leaders of product development learned that the average age for individuals to found high tech firms was 39. Jack Benny would be so proud (take that Gen-Y'ers - Ha! Do you even know who Jack Benny was? Ok, so he's dead - sure, but still - Ha!). 39 years young; and that was the average - so some of these innovative entrepreneurs were much older (to account for the fact that some of them were pre-teen).

Author Clive Thompson has a piece in Wired Magazine titled "The Ages of Innovation", and makes the point that younger innovators tend to see ideas because they don't have a grasp on the full complexity of the problems. They are fearless, and have unlimited time and energy to spend (until, you know, they start dating). He says that twentysometing Web prodigies are fun and all, but the veteran visionaries will save the world.

Keep this in mind; young thinkers often have no idea that they are inventing something great - they have no plan, no goal, they're just permuting though ideas and sometimes one will stick. Big. Older innovators see the true complexity of the world, and if they can get past that daunting self-inflicted trepidation, it is the older inventor that can cause great change directed at solving specific problems.

Innovation knows no age, it is not limited by experience, in fact age, wisdom, and experience make innovation more possible. Don't let the complexity of the world intimidate you - feed on it. Find a giant and climb up their back.

Follow by Email