# Saturday, 15 December 2012

Technical Architects make many tough decisions on a daily basis, often with incomplete information. Colin Powell's 40-70 rule is helpful when facing such situations.

He says that every time you face a tough decision you should have no less than forty percent and no more than seventy percent of the information you need to make the decision. If you make a decision with less than forty percent of the information you need, then you're shooting from the hip and will make too many mistakes.

The second part of the decision making rule is what surprises many leaders. They often think they need more than seventy percent of the information before they can make a decision. But in reality, if you get more than seventy percent of the information you need to make the decision, then the opportunity to add value has usually passed, or the competition has beaten you to the punch. And with today's agile development and continuous integration (CI) methodologies, you can afford to iterate on an architecture with incomplete information.

A key element that supports Powell’s rule is the notion that intuition is what separates great Technical Architects from average ones. Intuition is what allows us to make tough decisions well, but many of us ignore our gut. We want certainty that we are making the right decision, but that's not possible. People who want certainty in their decisions end up missing opportunities, not leading.

Making decisions with only 40%-70% of the information requires responsibly communicating the technical architecture + how changes will be implemented as more information becomes available.

Architecture + Continuous Integration Process = Agility.

Architecture alone is not a sufficient solution and can leave a solution inflexible to change. "Release early and often" is the new mantra in cloud development.

The best way to manage risk as a TA with 40-70% of the information is to constantly ask yourself 2 questions:
1) What is the simplest possible solution to the current problem?
2) How will future changes be implemented?

Within the realm of Salesforce, a Technical Architecture conducive to CI is achieved primarily through 3 design patterns:
* Declarative configuration
* Custom Settings
* Hybrid apps / Web Tabs / Canvas

1) Declarative configuration. First and foremost, it's the obligation of a TA to maximize the point-and-click configuration of any solution. This is done by using as many out of box features as possible.
2) Custom settings: When coding is required, externalizing the behaviors and conditional branches to custom settings gives System Admins and Business Analysts the ability to fine tune a solution as more information becomes available. For example, rather than hardcoding a callout URL in a trigger, move the URL to a custom setting.
3) Hybrid / Web Tabs / Canvas: For ISVs and custom application development, an IFRAME wrapper to an app hosted on Heroku provides the greatest agility to pivot on a solution. Code changes can be pushed several times per day without having to go through the AppExchange package and review process. Matching the look and feel of Salesforce within a Hybrid or canvas app can provide the best of both worlds; a native Salesforce business application with code managed on a separate platform.

Comments are closed.