Sometimes being able to do something is not a good reason to actually do so. When playing doubles in tennis, one is encouraged to poach at the net. Poaching is when the player at the net rushes over to cut off a ball heading toward their partner who is likely back at the baseline. The idea is to reduce the opponents’ reaction time by sending the ball back to them more quickly than expected.
However, if poaching, one should either put the ball away for a winner, or at least force the opponents to hit a weak shot back that can then be put away on the next swing of the poacher’s racquet. If poaching will result in a poor shot by the poacher that allows the opponents to have the ability to hit a winner or a shot that leaves the poacher and their partner only able to hit a weak shot back, then the better course of valor would be to not poach on that particular shot.
Knowing when to poach or not to poach is a skill; it is not something simply done regardless of the circumstances. In other words, just because you can do something, does not mean you should do it. Similarly, caution should be employed in building one’s IT portfolio.
For a Portfolio of IT Soutions, You Need a Roadmap
When building up a portfolio of IT solutions, one needs a roadmap, an architecture, that lays out how things should work, how differing components should interact. A plan should exist that expresses how data migrates across the enterprise’s solutions. And as a general rule, solution implementations should follow those guidelines. If a reason exists to follow a different course, that option can be considered. Should the reasons for doing things differently be compelling enough, then that exception may be executed.If the reason for altering the course of data implementation is simply to reduce time/cost under this one circumstance, that may not be a particularly good reason. Because when the bar is set low, then it is easy to jump over it. Likewise, in building any solution, skirting standards will almost always allow for time or money to be saved.
And if that is enough reason to approve an exception to the rule, it hardly seems possible that a time will ever happen where the rule is followed and enforced. Like poaching a ball that you know will only be hitting a bad shot back, ultimately one is setting up one’s own side for poor performance. The resulting solution portfolio will likely be a mess of every possible technique and approach gnarled up across the enterprise.
An architecture derives its strength from a level of consistency in how things are implemented. However, that is not to say that a mindless devotion to absolute consistency is a good thing. Times will arise when exceptions to almost any rule are necessary. The skill, the art, the balance in applying decisions that result in a good data architecture across an organization are based on a prudent use of when to conform and when an exception is needed. If there are too many exceptions, it can rightfully be declared by observers that there are no rules and that chaos reigns.
Too much conformity and one may waste excessive effort in simply jumping through additional hoops to create that actuality or illusion of conformity. Balance is key, allow just enough exceptions, but not too many. One may, at least informally, develop an internal set of rules to use about when to break the rules. As hard as it seems, following rules is good, and breaking rules is good, but knowing when to follow which approach is pure gold.