How many software development organizations are still re-inventing the wheel? The unfortunate answer is generally most organizations still re-invent or duplicate software logic adding to the growing burden of software maintenance.
With years of software development experience including in-house development, commercial software development, and contracted consulting engagements, this software maintenance issue is always a continuous burden to IT in almost every organization.
Partial solutions to this dilemma have been developed over the years with “Component-Based-Development” (CBD) being the most successful. However, most organizations and IT Management have not realized the efficiency and cost effectiveness of this approach. With government regulations, competitive pressures, and changes in technology creating almost constant software maintenance requirements, it is understandable why our industry spends large percentages of the IT budget on software maintenance year after year.
Now, let me relate how to greatly lower this universal burden. Part of the answer is software components. Each of these components are generally specific logic to do sometime correctly the first time and optimized to execute this logic very efficiently by any calling program, in any application that needs to perform this logic. Now, as part of any requirement, you must inform all developers, including contractors where to locate and call this component to keep them from duplicating something already done! This is very effective for “global” functions such as generic data validation on input no matter what the source or application. Yes, this requires mapping requirements to your available components before any development begins, to prevent “re-inventing the wheel”, duplicating already existing functionality with less efficient code, and generally continuing and exacerbating an already huge software maintenance nightmare!
The other part of the answer is another rather obscure technology called “business rules”. Remember, all businesses large and small in every industry have specific business rules reflecting their business policies and behaviors. Historically, only a few industries such as Banking, Credit Card companies, Government and Insurance have used formal “business rules” and the rule engines to automate often very complex business logic and processes.
Now, let me digress for a moment to other real-world examples of other industries that have benefited by components and the “business rule” approach.
SBC Communications, Inc. is the second largest telecom company in the US market. They have been very active in the mergers and acquisitions arena over the last 5 to 10 years. This has created a development team of thousands, located in several locations around the United States and many, many projects to absorb and standardize these new operations. How much IT budget can be saved by all developers, including contractors of which I was one, being prevented from “re-inventing the wheel”? The answer is hundreds of millions!
An insurance company that processes many insured members for eligibility and claims every day. One particular daily process comes to mind that took large HP servers approximately 6 hrs to process, again every day! This particular process was part of the eligibility application, and consisted of primarily Oracle stored procedures. This 6 hour daily process was reduced to 10 minutes on the same servers with the added benefit of all future maintenance being reduced to simply adding or changing a few “business rules”, in place of months to figure out where to start affecting the required changes in a heavily regulated industry. Again this was a fairly recent contract gig that I was heavily involved in.
Object oriented technologies provide a separation of software lines of code into at least three tiers (client, business logic, and data). This is again part of the answer. If you have your business logic isolated in the middle tier or “layer” (Microsoft), most software maintenance involves scanning only the middle tier code base. However, there might be thousands of programs in this middle tier!
Ok, now let’s take it to the next level! Instead of duplicating some business logic in the thousands of programs in the middle-tier, let’s create our business rules and rule-sets in one repository and call a rules engine to interpret our business policies, procedures and behaviors. In our middle-tier we mostly have “component” programs that do specific tasks or functions that look to the rules for the current business parameters, variables, etc., that encapsulate regulations, management and business customers or users needs and desires, competitive pressures, etc., that are the primary sources requiring perpetual software maintenance.
This approach results in most changes requiring software maintenance being quickly accomplished by simply adding or changing one or more rules. You will normally never change a single program (component) as these are course-grain programs that look to the “rule(s)” for the very specific details to execute all your business logic.
Program and software maintenance has just been reduced by a magnitude saving precious IT and company budgets, every day, week, month and year into the future.
After years of working on this approach on a client by client and application by application basis, I decided to develop an affordable, enterprise-class solution that is generic that applies to every size business in any industry. Each client provides their specific business logic which is reduced to XML business rules and interpreted by an infrastructure of optimized Java components including a rule engine.
Manage Business Change with Agility!