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.