Saturday, April 21, 2007

Hard-coding vs Soft-coding and Misc

Stumble up on this. Talks about hard-coding vs soft-ccoding, rules engines, config files and all that. Even I have got into few of the assignments which leads to similar decisions. It does stimulate ones software engineering senses. Are Enterprise Rule Engines (aka Business Rule Engines) really have a fit in every enterprise applications. Or Languages like Java, C++ are the Business rules languages and their compilers are the very engines we are talking about.

Agile software and likes are mantra of the day. Everything needs to be decoupled. SOA (Service Oriented Architectures) is driving it in some form. But whats' the optima? Where's the nirvana? Does too much of agility leads to fragility? Too much of integration points makes it slow or increases the chances of failures? Does all this still needs time to get mature enough and weed out hype and husk? Business is changing in the lightning speed and so should the IT systems. And what makes it happen is IN.

All the above and the ones following are some of my random thoughts. Some think-food. I dont' advocate anything. There are some architectures which fits better than other in particular situation. Everything has a reference, everything has a context. This post does not have one though ;).

Configuration files vs UI's to configures business rules/parameters vs Hard Coding in the source code vs Rule Engines vs.. Ain't hardcoding same as config files.. just the protocol changes or the environment where you plumb them changes or DEPLOYMENT changes. And ain't config files are nightmare to maintain as article says when you have piles of such kind. Isn't it better to keep them in the source code? Probably its not. High time to bring in Open source here... You get the source of MySql..change it to suit your needs.. you don't need my.cfg file to change the MySQL engine. Get into code.. and change. Grueling ?.. Works? You need the whole set of libraries, compilers at your disposal and sound knowledge of the source tree to do that. This I guess is the other extreme. We don't want that.. We want other wise.. Everything decoupled.. all the parameters are open for one to configure ..and in very friendly manner.. With out much effort.. without much implications.. Easy to maintain..Easy to Extend..

I am mixing system parameters with business rules/business logic (which the original post talks about). But to some extent they are part of same breed.. We have gone through many iterations of software development methodologies.. we talked about OOP, then AOP .. Component Oriented programming, Container Programming and what not. The mantra that time was "Just focus on business logic..". Now even that we are moving out to rule engines which business Analysts or Users can modify and maintain.. So what will be there for developer? Just to dvelop the glue between DAO (Data Acess Objects), Rule engines, other or even that would come from Application containers. A couple of years back there was talks about modeling the software rather than coding. Specially the Business Apps.. It seems that we have climbed the ladder from Assembly programming, C, Java, Workflow, business process management and modelling tools, etc. Isn't this the high time to sit down and think about all this and really decide on what fits for what needs?

All these configs, system parameters, rules are at different level in the software. If we ramify them in proper way the better of we are in taking a decision on where they should go. Some are meant to control the system parameters (server IP, memory parameters etc.) Typically all this goes to a config file or System Config UI. There are things which are to do with Applications. Good example of this is the tons of setups which goes in implementing ERP modules like GL, Inventory etc. Things like Currency Type, Conversion rules in GL and Costing Type (Average or Standard) in Inventory are very application specific. On top of systems and application configs are the Rules which should govern business process or some decision in the business process flows. Probably all this needs to go into Rule engines. Is it so trivial to decide all this?