As many of you know, I live on a peninsula on a lake near Atlanta called Lake Lanier. It is a beautiful place, and I really do love living and raising my family here.

One day I was driving over Buford Dam, which is the earthen dam that was constructed to create Lake Lanier. It generates power for the city of Atlanta, controls the flow of the Chatahoochee River through Georgia and into Alabama and Florida, and overall is very beautiful. Anyway, while driving over the dam I was struck with how steep the river-side of the dam (i.e. the side that isn't submurged). The dam itself is 192 feet tall, and the steep incline of the river side of the dam is breathtaking when looking down to the river below. The river side of the dam is sloped at a pretty steep angle - I would say at least 60degrees, and maybe even a bit more than that. The river side of the dam is covered in fescue grass - so the obvious question (ok, obvious to a geek) is, "How do they cut the grass on the river side of Buford Dam?"

The Wrong Answer
Unfortunately many engineers/architects/problem-solvers would approach solving this problem by wholeheartedly beginning to design some complicated lawn-mowing monstrosity. It would probably be very expensive, hard to operate, not very safe, prone to failure, and require specialized training to operate and maintain. Ugh.

Let me ask you: Does that sound like a good solution?

While this is an unusual example, the pattern is repeated quite often, every day, by many (most?) Problem Solvers in software design and development shops. Problem Solvers are quick to eagerly design some engineering monstrosity that (attempts to) solve the problem - and quite often has a few extra "bells and whistles" added in anticipation of problems you "may" (however unlikely) have.

Sound familiar?

Luckily the person who solved this particular problem was willing to look at all facets of the problem, and consider a wide variety of possible solutions - and a great solution was found. Let's get back to my little story....

The Elegant, Simple Solution
As I drove over Buford Dam I was struck with the question of how in the hell did they mow that grass? And then the solution became apparent.

OK, maybe "apparent" isn't quite the right word. The solution walked out from behind some trees on the side of the dam. Actually a small herd of solutions, to be exact.

Mountain Goats. The solution to the grass-cutting problem on Buford Dam is a herd of Mountain Goats.

Think about it. This solution is really quite elegant in it's appropriateness and simplicity:

• It is a solution that is particularly designed to solve the problem at hand.
• If uses resources appropriately - It cuts the grass at the appropriate height, so it continues to grow and doesn't die.
• It doesn't require special training or handling.
• It is very low maintenance.
• It is completely safe and is, in fact, environmentally friendly.

Lessons from this story apply in our world as well. I think that many of us in IT make the mistake of always looking to design something "new", "high tech", or "groundbreaking" - when quite frequently the best answer is simple, elegant... and often right in front of us. Our customers come to us for the right, best answer, and we are responsible for finding it. In order to do this we need to take the time to get outside of our techie think mode on occasion, take a step back, and look at the problem from different angles so we can look for the best solution - a solution that is "just right", or good enough.

Time for me to wander off on a diversion, at least for a little bit.

Time for a Diversion
As I have been thinking about simple solutions, "Good Enough" solution architecture (more on that in a bit), and so on I have began to formulate this concept that there is a range, or spectrum, of software applicability to the given problem. Take a look at the image below, and let me explain a bit further.

On the far left of the X-axis is our problem with "No Solution". Since this is "No Solution", you'll see that, along the Y-Axis, this takes 100% of our work effort - which makes sense. Then, as we love along the X-axis, you can see that there are various solutions, and their relative levels of effectiveness. A "Pretty Good" solution drops the work required down to 45% or so; and then there is the perfect "Just Right" solution that achieves the lest amount of work possible (in this example), 25% (assuming you can't get a solution that requires 0% work).

And then we begin to slide to the other side of "Just Right", where the solutions become more and more over-engineered. A "Little Overboard" isn't too bad - it still saves a bunch of work as it requires only 60% of the original work used with "No Solution". But as the possible solutions become more and more over-engineered, eventually the worst-possible-scenario solution is reached - the "God Help Me" solution - which not only requires as much work as "No Solution", but it actually requires MORE work than originally required (in this case 130%)!!

The causes of this excessive work are varied, but usually revolve around a solution with too many configuration settings, too many moving parts, too much babysitting required, too much maintenance required, too vast a dataset size created, and so on. You get the idea.

The "God Help Me" solution types are all too prevalent in IT today, and even within the IBM/Lotus market. I hate to say this, but many facets of IBM are often the creators of incredible "God Help Me" solutions - some earlier incarnations of Websphere come to mind, as well as some of the solutions in the now-defunt (thank god) "Workplace" strategy. SAP is a very visible example as well, as anyone who has worked with SAP can attest.

So our goal, as IT professionals, is to attempt to create solutions as close to "Just Right" as possible - or at least between "Pretty Good" and "Little Overboard". If we're able to land in that zone with our solutions, then we will be serving our customers honorably, and not causing them more problems than we solve.

OK, enough with the diversion; let's get back to the main story, but keep this diversion in mind, because it does apply to the big picture.

Good Enough Solution Architecture
The concept of Good Enough solution architecture is fairly simple. Basically, Good Enough solution architecture states that the best solution is one that simply addresses the specified problem at hand, and nothing more. If more features are needed or additional issues arise and need to be addressed, then these items will be made apparent by your user base during the usage of the solution. During the initial design and development of the solution, the solution architecture should never be enhanced unless the enhancement directly services the stated goal of the solution. But, then, what is this "stated goal"?

Before you begin defining the design of your solution you need to derive a simple, common-language statement of the problem at hand. This definition should be no more than a couple of sentences - a paragraph or two at most - and should clearly express the problem. After the problem is simply stated, then create a "Goal" for the project, one that is based on the problem statement. The Goal should also state, in common language, what the project should accomplish. The Goal should be measurable, because this Goal is what will be used to decide if the project is successful.

Incidentally, when I say that the Problem and Goal statements should be in "common language", this means that these statements should be communicated more in the way actual normal people talk, and less the way we geeks talk (i.e. no "geek speak"!). These statements should definitely be technology agnostic as well - meaning that they shouldn't mention any technologies, platforms, etc. AT ALL, because this isn't how normal people talk. Keep in mind that you can define all the techie stuff later, when you're actually designing the solution.

There's one more thing I want to add to this "common language" talk. Please don't try to blind your clients with your brilliance (or baffle them with your bullshit!). They hired you (or, in the case of corporate developers, they've picked you for this project), so they already think highly of you. Blowing them away with language and jargon that they don't understand will simply make them feel uncomfortable at best, and piss them off at worst. It is better to let your work speak to your brilliance, especially in the elegant simplicity of your solution.

Lawn-mowing goats come to mind...

Conclusion, for Now
Later on I'll write another article that describes some ideas around how you get from Problem and Goal to Simple Solution; but for now I would like for you to think about the concepts I've introduced in this article, and let me know what you think, concepts and techniques you use that are similar (or different!) than these, and so on. We'll have a good discussion, and later on I'll publish the followup article to this one.

In the meantime, keep it simple, and keep it elegant.

UPDATE: I made some small grammatical corrections throughout the article, and then decided to add one more paragraph towards the end, in this color. **Rock
Rock