CTO Articles
Published in IT World
May 2, 2007
More praise for design constraints
Some time ago in this column[1] I argued that constraints - be they constraints related to time, money, memory, disk space or whatever - can have a positive affect on the amount of innovation juice flowing through your average engineer.
I have since had cause to ponder the power of constraints again. This time, my focus has been on the power of constraints to facilitate change in corporate structures, rationalizing existing workflows, re-engineering existing work practices and so on.
Imagine a scenario where an organization has an existing business unit that is not working so well. Perhaps it takes too long to execute customer requests. Perhaps it is too expensive to operate. Perhaps it cannot handle the demands of new market conditions. Perhaps the quality of product is not high enough. Whatever.
The business unit hires some IT folk to see if computerization can help....
I pause here for a reason. The cracking sound you heard in the background is the sound of the universe forking into three separate universes. In the first universe, the business unit hires developers with low level (but highly flexible) skills related to programming languages, GUI design etc. In the second, the business unit hires developers skilled in a high level (but limited) business application toolset. The third universe is where we now stand, commenting on the fates of the other two...
In the first universe, the developers - quite justifiably - claim that they can automate anything that can be expressed in terms of logic. No matter how crazy or complex an existing business process is, it can be computerized with their tools. It may take a long time, but it can be done.
In the second universe, the developers know that their toolset can produce results quickly but only if the business processes being automated fit common patterns. Their tools are really good, for example, if a problem can be reduced to a combination of tabular data entry, data storage, data modification and data reporting. The developers know that if (when) the existing business processes get crazy or complex the tools can run out of steam.
In the first universe, the theoretical lack of constraint has a way of veering attention away from improving existing business processes through rationalization. It tends to focus all efforts of improving the existing process - however baroque - by computerizing it.
In the second universe, the clear and present constraints manifested by the application framework have a way of veering attention towards changing existing business processes. Changing aspects of how things are currently done may be the only sane way to computerize the process as a whole.
It seems to me that the scenario painted in universe two represents an interesting and useful pattern. If your sense of an existing process is that it needs to be changed before it is computerized (if it is computerized at all), then you need to be careful what tools you put in the hands of those looking at the problem. Tools with constraints that focus attention on simplicity can be excellent catalysts for change.
Of course, in this industry, all swords have two edges. If a business process truly is complex and beyond the reach of a boil-in-the-bag application framework, then forced use of an ill-fitting framework will surely give birth to a monster. The trick - one that cannot be automated unfortunately - is to determine which universe you are in as quickly as possible and be willing to switch between them as your knowledge of the existing process grows.
[1] http://www.itworld.com/Man/2672/nls_ebiz_innovation061003/