Three of four automation initiatives run into serious problems with some combination of cost over-runs, integrating with existing systems, learning to use new technologies, understanding how to design components for a service oriented architecture, security, business rules management systems, business process modeling, and more.

Security

Security challenges take many forms: enforcing role-based security so that user access is limited to the web pages, functionality and data strictly required to do their job; securing messages and authenticating the request to consume a web service; single sign-on across multiple systems, identity management, integrating applications with LDAP such as Microsoft’s Active Directory.

Business Rules and Business Process Management

Business rules management system challenges start with understanding how to do analysis and then design in a way that enables understanding the business from the point of view of the business rules. The challenge really begins with the need to embrace a business process management paradigm: understanding the organization’s activities through the lens of business processes, the decisions made in the process, orchestration of the process and the decisions, and finally linking the business rules to the decisions.

Failure to Design Components

Too often we find that even large system integrators lack the ability to organize the results of their analytical efforts first into an object model and then organize their objects into components (coarse-grained objects.) Without this analytical discipline, design and development begin prematurely at the object level. Invariably, the same functionality (methods) winds up occurring in multiple objects that perform similar functionality.   A false sense of progress is possible because little coordination is required across the many development teams. Progress stalls when it comes time to do system testing and the project implodes during user acceptance testing. Errors detected during testing reveal that the same functionality exists in multiple objects. Fixing the first object with the error is easy, but when the error re-occurs as duplicated objects are tested is when the poor design begins to take its toll. Finding and fixing all the occurrences of the same method, or worse—different interpretations of the same method—will slow the project to a grinding halt.

We have seen projects defy good judgment and allow the system to go into production with duplicate objects (hopefully all implementing methods consistently but sometimes allowing errors to go into production with the rationale they will be fixed “on the fly” when problems arise in production). Either way the result is unreliable results in the production system and extremely expensive and slow modifications over time—with skyrocketing total cost of ownership.

Our job in these situations is to identify the duplicates and perform “refactoring”. Refactoring entails consolidating all the duplicates into a single instance of the object. We then see where objects can be organized into components. Messages sent between objects in a component are executed more quickly because there is less “overhead” in the security and network traffic. Exposing the interface at the component level rather than the object level also promotes future re-use as well as more efficient execution.

Database Performance

Database design modifications are inevitable following system deployment. We find that the team that designed and built the system is better suited to improve the database design than are we. The key is to give your project’s database team the permission to modify the pure logical database design (third normal form) with slight changes that may involve some duplicate keys in order to speed data retrievals. Of course, there is a whole discipline associated with studying the most frequently used search paths and adding indexes to enhancing searches—again this can usually be addressed by your existing team without outside assistance.

Data Conversion

Data conversion poses no end to challenges when migrating from an older system to a new database design. By the time we get involved, it is usually too late to add much value. The key is communication across the application design team, the database team, and the experts with the legacy database from the earliest stages of the project. The application team may design their data requests around a new, elegant database model that does not recognize there simply isn’t data from the legacy system to populate the new database design’s data fields or required data table relationships. The new system may populate all the required data fields and relationships, but problems will arise when attempting to work on data pre-existing and converted from the legacy system.