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?

Friday, April 06, 2007

Random thoughts and some Oracle E-Business suite learnings

Chilling out on this Friday afternoon of Singapore. A bright sunny day. Weather has been so for last few weeks with some shower now and then. Guess the Easter long weekend has come at the right time for me. Its been long I have catch up with whats happening around and the feeds from my favorite blogs. Its even longer I have posted last on this space.

Last few months were busy at social front. At work its usual stuff. Though I have started with new project since last few weeks and things are getting busier.

Off late I have been doing assignments in Oracle Applications aka E-Business Suite(mainly in the capacity of technical consultant) and it has been a rich experience. Though I have been working with Oracle Apps for some time, it was more with the perspective of extracting data for reporting and data warehouse applications. But This time it involved working head on with some of the core modules of E-Business suite including OM, Inventory, Financials etc. Technology has always fascinated me and tech stack of Oracle Apps was no exception. Lot of interesting learnings.

ERP are huge apps with so much to explore in terms of functionality, business process, technology components, software architecture and organization dynamics. Working in implementation project Oracle Apps really brings you close to all this aspects. I do prepare some random notes of the interesting things I come across about any software product. Some of the key things I discovered/learned about E-Business suite in the last few months of engagements:

  • Ad-Utilities for managing middle tier components.

  • Integrated data model. Example: there’s one entity hosting customer data which is referred by all the module ranging from Customer Management, Order Management, Advance Shipping

  • Open Interface tables to flow in or out the transactions from one module to other. The same interfaced tables could be used to bring the data from other not E-Business suite systems

  • APIs corresponding to virtually all the online functionality. The is key for any ERP application. Integration needs always requires creating master data and transactions from the scripts or programs. APIs make this simpler to approach since it will be impossible for any way to go and update all the underlying base entities without breaking the integrity. APIs have always been powerful since they centralize the business logic and all sort of integrity checks at one place. I will stop on API here. Every one knows about the advantage reusability, modularity, refactoring, OO and other core aspects of software designing.

  • Approaching integration with third party applications. This really requires proper planning for developing the custom scripts, testing and rolling out the customization.

  • Consistent UI. Consistent usability and user interactivity.

  • Power of Concurrent request manager.

  • I came to learn about CUSTOM.pll, which allows in non-invasive manner you put the custom hooks in the standard forms.

  • There were lots of learning on how to go abound customizing E-Business suite apps. CUSTOM.pll, database triggers, modifying standard reports (though not recommended), defining custom Application, DFF and KFF, lookups etc.

  • Coding standards. E-Business suite taught me some of the nifty coding practices.

  • One of the big learning was the philosophy and thinking that goes behind designing and developing packaged applications. The E-Business suite apps are perfect for business needs across industries and wide range of business requirements from different organization. This is achieved by the flexibility, setups and configurations provided by E-Business suite applications. On top of theses, there are avenues to do additional customization to achieve very specific business need. Sometime back I did post on how the development of software product differs from the custom solution, but Oracle E-Business Suite holds a special place. Lot of expertise, effort, planning and experience goes in developing products like E-Business suite.

There were many more though. E-Business Suite is huge and the above list in no way wants to undermine the complete set of functionality that it offers. These are just my personal learnings. One should check out E-Business suite Documentation to appreciate the sheer size and richness of E-Business suite applications at In process I also came across few of the blogs on E-Business suite including Oracle’s Steven Chan’s blog on E-Business suite technology, Chris Muir’s One Size doesn’t fit all and many more.