Even in the most disciplined organizations, most software projects are never planned out holistically. You know the drill: The state requires regulatory changes within six months, SOX auditors want remediation, a recent judgment requires workflow tweaks, or marketing wants to implement a new product line.
But with your software team drowning in high-priority compliance projects, they can't work on the marketing department's competitive projects. Your business agility is impacted by your applications agility.
Insurers are slaves to the inflexibility of software. The only real long-term solution is business applications agility, an integration approach that can help make your previously rigid systems more capable and agile without a lot of pain and bloodshed.
The lack of agility in business applications is attributable to application sprawl and complexity. Insurers have a long tradition of lengthy and expensive system upgrades and enhancement projects, but the level of complexity has never been greater.
Instead of managing every aspect of business in one monolithic system, as we did on an old mainframe, or with a suite of client-server applications, the trend in the industry has been to increase the number of specialized apps.
When adding a new line, many companies have found it cheaper and faster to add a new application, or a new copy of an old application, instead of customizing the current application to support multiple lines. Along with acquisition comes inherited systems, and consolidation can seem impossible.
Now we require legacy systems, as well as new browser-based and software-as-a-service applications, to work together. Complex integrations, rules, formulas and years of transactional data compound the pressure, and each project's development time is extended due to the complexity of the preceding project. This is where integration architecture can help.
Complexity
Companies often have immature and or even haphazard integrations based on a myriad of technologies—point-to-point data transfers, FTP files, batch jobs, custom coded intermediaries, Web services calls, extract-transform-load tools and direct database access. With fewer systems and infrequent data exchanges this may be sustainable. But as the complexity grows, they can become unmanageable.
Adding or upgrading an application might require you to completely rewrite all the integrations, and companies frequently decline upgrades for fear of upsetting complex or "brittle" integrations, those that break rather than flexing and absorbing changes.
There are many possible approaches to creating the well-designed technology standards that define an integration architecture and approaches will vary to account for the factors that define your system environment: applications, languages, databases, physical location, internal vs. external, transaction times, workflows and even business culture.
The optimal approach to integration architecture will provide you with reliable communication in addition the most flexibility to add, remove, change and upgrade business applications without impacting any existing systems.
Resolution
One of the more popular models is service-oriented architecture. This approach defines all applications as services (a.k.a. end-points) with an intermediate message broker, generally called an Enterprise Services Bus (ESB), to relay data and messages between systems.
Regardless of your applications' functions, they are programmed to communicate with and be aware of only the ESB interface. All operations are then modeled around the business workflow, such as: "Get phone number for Customer Acme Corp;" "Submit Payment for Policy #1234;" "Update address for vendor #7654."
The application doesn't need to know where the response to its request comes from, only how to submit a request to the ESB and, if there is one, process a response. The ESB only needs to know how and where to transmit the requests and responses.
This mediation between business applications reduces interdependencies based on design, programming language, or data format. Changes in one application will be less likely to introduce errors in others. Software project designs now only need to be concerned with how changes impact the ESB interface, vastly simplifying the project.
By investing time and money to lay out the integration architecture, you will reduce development time and expense, interdependency and risk. This enables your software team to make changes much faster and cheaper, while increasing both your application and business agility.
Phillip Grove is CEO of Confluex Inc., which specializes in integration architecture and development.
