No Plumbing (Don't Build Your Own)

Experienced IT architects don't reinvent the wheel. They devote the project's energy on the unique requirements of the solution they are constructing, and let proven products carry the rest of the load.

Consider this a corollary of Use Proven Products.

 

When you have a talented team, there are times when you’re tempted to re-invent a key component of your solution. For example, your brightest programmer may:

• Design a new custom file format more logical than XML, JSON, etc.
• Design a new secure protocol that doesn’t have the complexity of using SSL, SSH, etc.
• Design a new object-relational solution that’s more efficient than … you get the idea

And the chances are, your programmer has a great idea. However, you were not tasked with re-inventing base technologies (what I call, plumbing). Almost always, the better approach is don't do it, don't build your own. Live with an existing proven product that works well and move on.

 

Why? You have to manage the project's energy. You just can't afford to expend significant amounts of energy on function that already exists and works well. And of course, you can't afford the additional risk.

 

For me, I like to build my solutions on top of great existing technologies (great plumbing). That way they have the best chance to survive the long term since they inherit the improvements of their components. I've leveraged these improvements for some fantastic service releases over the years. This best practice is a major project success factor – use it.

 

Lesson Learned: To minimize risk and accelerate delivery, use standard plumbing for your solution (don't build your own). Focus the project's energy on end-user functionality.

Use Proven Products

Experienced IT architects construct their solutions with proven products.

Why? As the IT architect, you are 100% responsible for the technical success of the solution. If the solution doesn't work, it's your fault - not the users, not the project managers, not the programmers, just you. Pack your things; you're done.

This is why your mentor said "NO" to your idea of using the newest and hottest technology. IT architects just can't go with an unknown quantity as a key component of their solution. The consequences of failure are just too great; causing great harm to many. Here are some guidelines on how to apply this best practice:

1. Construct your solution with proven products:

• Make sure each product serves a well-known product space (i.e. a relational database)
• Play products to their core strengths - don't use them in strange ways
• Look for products with healthy development activity - new versions on the way
• Look for products with strong support communities
• Look for products with great documentation
• Avoid new products - v1.0's are deadly
• Avoid products dying on the vine (i.e. ownership changes, deprecation, etc.)

2. If no proven product exists to fill the role you carved-out for it:

• Rework your solution - try to simplify it
• Don't build your own, rework your solution - no platypuses!
• When forced to consider an unproven product, don't buy or commit to it - prototype it quickly with your best and brightest, put it under realistic operational scenarios, then decide if you can live with it

Lesson Learned: To minimize risk and accelerate delivery, construct solutions using current, well-known, and proven products with strong support communities.

BTW: I think platypuses are way cool. Not to be confused with the clumsy metaphor above.