A frequent question is – how simple should things be ? this is with regard to implementing a solution with the right balance between complexity and functionality. This would of course require the person to wear multiple hats – often leading to a collision course… A typical scenario :- The current flow of events warrants that some one steps in to manually approve certain transactions that are above a certain value. When modeling the same into the system : 1. Do you go about modeling the same As-Is ? 2. Do you ‘Anticipate’ future requirements and build in the intelligence for the process to do an e-mail approval ? 3. Where does the business fit in to this picture…?? Modeling the process As-Is would mean that someone somewhere later on would definitely mention to the business that something like this is possible ( oops…) Option 2 would require a lot of complexity by way of configuration , security , integration etc etc behind the scenes. Option 3 is more far reaching when you have a technically marvelous solution that the users do not understand!! Which one of the above do you choose ? essentially saying that do you promise the moon to the end user and go all out trying to give them the same resulting in ( not always but most of the time ) in a complex maze of interfaces that are tough to interpret and debug or simpler still.. give the user a simple configuration with the perceived message that further refinements in terms of user experiences are possible but would require a lot of technical jugglery and might impact the regular flow of events ?? Many a time the hat of a Business Analyst or BPX would prompt you to take option one whereas the Designer in you is screaming murder in terms of development effort and complexity .. which ones do you address? There is an interesting quote from E.F Codd – the father of the RDBMS concept… Attempting to force one technology or tool to satisfy a particular need for which another tool is more effective and efficient is like attempting to drive a screw into a wall with a hammer when a screwdriver is at hand: the screw may eventually enter the wall but at what cost? - Providing OLAP to User Analysis – Hyperion – 2006 The same applies to good design concepts as well especially when we tend to go overboard with simplification or trying to force one thought process for a requirement that does not quite fit the current design.. The question again comes to What do you do ? My 2 cents on the same would be : 1.Simplification is a long running thing and it could be looked at in a longer time frame compared to giving the users a working satisficing solution for now with the promise that further tinkering would be done post delivery. – This essentially achieves two things – one is to understand the user psyche as to what they want and what more do they want and another it that the client is aware that we are looking at further tinkering and the same could be rolled out with any further requirements / modifications. 2.The question that needs to be addressed is – are the users ready to adopt satisficing solutions that address their immediate needs or is Business and IT deciding that users should get the best solution possible at the first shot – here a proactive IT business relationship goes a long way in smoothening things and also reinforcing the view of business that IT can deliver and the team is good at it. Here the BPX would be a necessity by way of : 1.Adopting good design practices by donning the design hat 2.Controlling requirements – by adopting the business analyst hat. All that needs to be done would be to effectively juggle the hats around and make sure things go on time and in full…
