In this situation, I need to ask again: Is your core business IT System crucial? Added up to that question, Can your enterprise systems evolve? The reasons for software evolution are varying but they all serve one ultimate purpose: to make sure the business continues to survive.
What you think will happen if one day they need to:
1. Add a new functional module to existing system
2. Customize existing workflow
3. Deploy a feature enhancement
4. Patch a found bug
5. Interface with a new external authority party
6. Optimize runtime performance
.... And so many else.
As many real world examples pointed out, many enterprise projects are unsuccessful due to one main reason: They can't evolve in a way that's effective, efficient and minimized risk.
Enterprise applications are totally different from many other sorts of software. As an enterprise architect, you gotta think in a macroscopic level and execute in microscopic details.
In past one month, I was involved in such a scenario where a team of programmers is assigned the mandate to evolve a business core system, mainly in the area of bug fixing and functionality enhancement.
Some of my findings are summarized as below:
The Good:
1. Architectually, the system is well designed with plenty of design patterns applied and plenty of property files (It might not be good, heard about XML configuration hell?) available for attaching loosely coupled and late bound components.
2. Well known open source frameworks and components were used. Struts, Hibernate, Apache Commons, Log4J, WebDoclet, etc.
3. Presentation tier and business tier are relatively well encapsulated with defined access points.
4. The use of ThreadLocal for managing Hibernate session
5. The use of dynamic proxy to manage DAO method invocations (Though the implementation is less than satisfactory)
(Trying very hard to think out more.... But can't seems to find any other good point)
The Bad:
1. Running on IBM WebSphere 5.1, developers actually mixed the usage of Struts TagLib and JSTL. Personally, I wouldn't do that, as many of JSTL functionalities overlapped with Struts related taglibs and since JSTL is not part of the JSP 1.2 yet, my advice is to stick with Struts only. Putting in JSTL in this case will make the deployment difficult and future upgrade to newer version of J2EE container more troublesome.
2. Unnecessary coupling between the core framework classes with web application related classes. Imagine one of your core engine class actually reference your /WEB-INF/classes's class. Cyclic dependencies cause the original ant script to fail.
3. Existence of two separate mechanisms to obtain database connections. One is using hibernate session, another is direct JNDI lookup. Hey dude, can't you just use one? In the new version of the system, I refactored the codebase to use only the hibernate session because previous JNDI lookup mechanism involved plenty of property configuration files, each for different components (HUH?).
And more....
The Evil: (We got our winners here)
1. Drag and drop deployment mechanism
- I was fainted when first saw this deployment process. To deploy new classes to the production server, you "drag and drop" your classes directly through FTP interface to their respective directories. Imagine you got 10+ updated and new classes in different java package need to be deployed, how inefficient it is to find each of the respective directory, drop the file, cross your finger and hope the container load it properly and continue with the next.
2. Minimal or no documentations
- Well, no need to speak much about this. Even the business process is not properly documented and most of the time you will like "Huh, how come the button still disabled? Do I need to perform anything anywhere else?"
3. Not a single unit test
- Without unit test, how can you confidently perform your integration test? In fact, high latency was resulted from the minor configuration issue like miss out a mapping entry in hibernate configuration file, which is suppose to be discovered during unit testing.
4. Business requirements not properly logged.
- From time to time, developers and analysts asking themselves: Emmmm, this looks familiar, was it implemented before? Oops, I can't really tell, grant me 2 days to trace through the code again.
5. Problematic concurrent transactions
- Lost Updates did happen. E.g. Stock quantity discrepancies
6. Poor Exception Handling
- I don't even want to mention about this
To be continued. Stay Tune. :)
