Taming Complexity
The complexity of a project is an intrinsic variable ultimately determined by the business processes. Keeping in mind the key dictum that a technology solution can never be of lesser complexity than the underlying problem it solves, you should first ensure that prior to automation, the business processes are as optimized as possible[1]. Many technology projects end up being unyieldingly complex because they try to tackle what is in essence a mash up of chaotic business rules.
Having said this, there is no reason why the technology solution should be more complicated than necessary. For instance, poor technical decisions or the use of inappropriate software tools can add unnecessary complexity to a project.
Recognizing that a project has an intrinsic complexity framed by the business requirements, your challenge is to efficiently tame this complexity within the realm of the technology and budget available to you. Here we have the “Law of Preservation of Complexity”: N = S + U; where N is the total complexity of the solution (as determined by the complexity of the business problem), S is the technology system complexity, and U is the complexity that the user faces when interacting with the system. Given that the intrinsic complexity of a project is “N”, it is your decision how to apportion the complexity between the system and the user.
Thinking about it, the simpler the user interface, the more complex the technology backend that supports that iteration is bound to be. I’m fairly certain that the underlying software supporting the Apple iPhone is quite complex, given that it is a device universally recognized as providing an extremely-intuitive interface. Alternatively, simple technology implementations tend to deliver solutions that are more manual in nature and hence more complex for the user. A complex solution that delivers an easy-to-use implementation is bound to cost more to develop, but its operational costs, due to reduced support and training costs will be lower. A simple solution that places the burden of complexity on the user can typically be developed more rapidly and at lesser expense, but its operational cost will be higher.
Taken to the extreme, the simplest automation solution is one in which automation ceases to exist and all business processes are manual. The most complex automation solution will probably involve the use of a sophisticated, artificial-intelligence system that is able to take on all automation burdens[2]. This capability, however, has yet to be invented.
In the end, it behooves you as technology leader to ensure that no unneeded technical complexity is introduced into your projects (watch out for that young bright, software maverick who pushes for that “cool”, dynamic rules engine to do the payroll!). Always keep in mind that the single most important independent variable in apportioning complexity is the understanding of the key business priorities and the true capabilities of technology.
The trick is to strike the proper balance in the deliverable. A good technical delivery will endeavor to place the bulk of complexity inside the solution black-box, making the interaction with the software simpler and more user friendly, but not at the cost of creating an un-implementable solution.
Many people confuse complexity with over-automation. If the complexity of the technology solution does not ultimately simplify the interaction with the user then you are not improving things. A personal peeve of mine is the recent “popularity” of so-called voice-response systems. If they were used only for simple voice driven selections, then there would be no problem. The issue arises when these interactive-voice-response (IVR) applications are forced to carry more complex interactions. The fact is that technology is not yet at the point where it can support these interactions in a seamless manner. In the end, the only purpose these “voice-recognition” systems accomplish is to weed out customers’ access to the support staff, at the price of lowered service levels, and also heightened customer dissatisfaction. The manner in which companies use these systems is a typical example of adding complexity for the wrong reason.
[1] In fact, one of the intrinsic benefits of IT Transformation is that, just like the act of smiling can make people feel happier via backward neural influence, this transformation can also serve as a trigger for much-needed business transformation.
[2] As I write this, I’ve come across the announcement that IBM is starting a project funded by DARPA to build a new type of computer that simulates the way the brain operates. A multi-disciplinary working team that includes Neuroscientists and other disciplines will work on this project. I doubt this type of approach will work (men finally invented airplanes when it stopped trying to emulate the way birds fly), but who knows?
Labels: Business Rules, Complexity, Interfaces, IT Transformation Defined, IVR, Project, voice recognition
posted by IT Transformation with SOA @ 11:41 AM
