Good design is good business!

Ideas require favorable circumstances to flourish but facts can stand for themselves in all the situations, only difference being in adverse situations we start analyzing facts more closely. This statement is more relevant in today's scenarios when world economy is not painting very pleasant picture, client spending is shrinking, even out right good ideas are hard to sell. So what is the fact that can stand for itself even in such situation “Good design is good business".

Though design holds uttermost importance in any product lifecycle but here I am specifically referring to technical design of IT systems. So, why good technical design is good business?

Software services allowed businesses around the globe to expand beyond geographic and cultural boundaries, reaching to diverse customers in time and cost effective manner. But at the same time inability of IT solutions to respond to changing market place, completion and customers have forced otherwise successful businesses to shut down. Close analysis of any such successes and failures invariably points towards IT system design. In current economic scenario IT system design becomes even more critical for serving and served businesses.

Our organization serves customer all across the globe creating and maintaining client business support systems. For continuous business growth it requires organic (more business from existing client) as well inorganic (new client business) growth in client IT business. Moving up knowledge ladder of existing client's IT ecosystem provides vast opportunities for new business development and good solutions (read designs) created by us serves as steps in that ladder reaffirming client’s faith in our capabilities and delivery model. They are like Oscar trophies; next movie (project) can easily generate funding based on previous great work. So why good design makes sense for everyone involved?

In simple words, better design always translate into better code, making maintenance  and extension cost effective and easier to justify to anyone needing it. Thumb rule is good IT systems are self sustaining, making them favorite of higher up management and frankly who doesn’t like hassle free IT systems saving corporation millions spent on maintenance and failed attempts of extensions. Also, ability to scale provides business confidence to respond to changing market dynamics. Remember everyone want a piece of good cake i.e. interface with flexible, bug free (ok lets settle for almost bug free), stable system, scalable good design can help in giving each one a piece they deserve.

For serving businesses like our organization, good design is easier to code and providing most efficient resource and time utilization (if you include time and effort spent in coding (fixing) bugs for bad design). Good designs leaves scope only for small coding bugs, but save time spent on filling functionality gaps. Good system can be sold for extension even in bad times because they are built to scale with least cost, but other way (bad system) it is hard even in perfect times.

Finally in good times bad design may go unnoticed but in bad time good system (design) stands out so do the bad system and you would not want to be standing out with second one.

So let’s go over few simple rules for creating good design

• Traditional development model (water fall etc) requires design to start after requirement phase but starting early with high level design uncovers relevant questions in early stage saving repeated cycles of communications and documentation between business and technical teams. Believe me knowing business better and first hand always result in better technical designs.
• Design should justify each of participating technologies. Though it will be superficial to say technology decisions can be cost independent but key is to identify right technologies to use based on business requirements, evaluate various available options (products), quantify results, share with business, if not easy , won’t be impossible to get business sing your tune.
• Always design to services and components, map requirements to components/services and interfaces and things will start falling in place, giving you right kind of questions to ask.
• Don’t run to code, instead spent time on understanding requirement and creating right design else you will be spending more time filling functionality gaps later. Right design will ensure you are left with enough time to realize it in the best possible way.
• Don’t reinvent wheel, use best practices and patterns to save time and standardize your solution.
• A layer of abstraction solves hundred problems by making interface information clearer for each business component and consuming channel.
• Business components design should not be too coupled with consumer channel, remember web is not the only channel, it’s just one of them, if not code, design for business components with multiple interfaces to ensure system is capable of further extension with least impact.
• Functional and non functional are equally important, you cannot make system faster and scalar if you never created functional design for one. Believe me you will spend twice the time doing the same thing if you first code for functionality then for speed and scalability.
• Share design thought with developers to ensure high level design sync with low level realities.
• Always remember testing is not just a phase in development cycle it is equally important to designing or coding, bottom line if you can't find it, you can't fix it. Stress on allocating right amount of time, effort and tools for testing.

This all sound reasonable for new systems but what about existing ones, existing system enhancement and maintenance is bigger chunk of work we do for our clients. Existing system are great teacher for anyone willing to learn about what to do and what not to. There are numerous good and bad systems present in IT world giving practical examples of do and don’ts.

Redesigning any such system which is not build around good design practices is not an option most of the times but few techniques can still help in making future enhancements easier and less time/effort consuming.

• Analyze new requirements and existing system; remember code and data can tell you what business document may not.
• Create high level design with component contract specifications for new enhancements.
• Analyze interfacing with existing system components and identify ones that are violating your expected contract terms.
• Target these components for sandboxing. Create abstraction layer around such components to prevent design decencies with new design/code.

Lastly, no system is perfect but we can aim to reduce gap between real and prefect system to minimum by making good designs.