Two computer scientists at the University of Illinois, Brian Foote and Joseph Yoder, have studied the computer architectures used by a large number of companies. They found that most companies use an architecture that they have named "Big Ball of Mud" alias "Shantytown" . Utica National is among the majority. A “shantytown” exhibits a number of characterists:
Foote and Yoder pointed out that many of the characteristics of “shantytowns” can also be found in the computer architecture that is in use by most companies. “Shantytowns” soon reach a limit to their growth – they aren’t very scalable. The only way to rise above the “shantytown” level is to invest in infrastructure.
The integration of multiple programs and systems across an enterprise presents any business organization with the most complex, and costly Information Technology challenge it will ever confront. A wise investment in a small amount of infrastructure that improves the manageability of the integration challenge will pay huge dividends. Such an investment can raise the system architecture above the “shantytown” level, and permit a substantial improvement in the scalability and reliability of the system, both internally and in its ability to integrate with outsiders.
A simple description of the integration problem can be stated as follows: “Each subsystem must be able to ‘talk’ with all the other subsystems, and with many outsiders.” If your computer “system” has only two subsystems, then the problem is a very easy one to solve. You simply need one connection, with a total of two connecting points that need to be programmed and maintained. If you have 40 subsystems, however, you have a much larger problem: you need up to 741 connections, with a total of 1,482 connecting points to program and maintain. As each new subsystem is added, the number of point-to-point connections grows geometrically. The overall system rapidly degrades, and additional growth becomes more costly and difficult until , ultimately, additional growth becomes impossible.
There must be a better way, and there is. Replacing “tight coupling” with “loose coupling” can reduce the number of connecting points to a manageable level. By using a hub and spoke model, the number of connections in a system with 40 subsystems is reduced from 741 to 40. The number of connecting points is reduced from 1,482 to 80. This is much more manageable, and results in a system that is much more scalable.
(A large portion of the remainder of this proposal contains direct quotes from a white paper written on July 7, 2003 by Sean McGrath and Fergal Murray of Propylon. I had originally written this proposal based on many of Sean’s past writings, as well as the writings of others. The recent white paper stated the problem and its solution so much better, however, that I decided to replace portions of what I had written with direct quotes from their material. I highly recommend that you read their entire paper.)
"This can be difficult with IT where life cycles of specific technologies are measured in years, not decades. Individual computers are obsolete in about 3 years. Back-end applications and databases have a lifespan of about 2-5 years before needing costly, complex upgrades. Programming languages and system architectures (dumb terminal, client/server, web browser) last about 10 years. Irrespective of lifespan, there is certain to be a broad variety of systems, languages, and applications [in use in any enterprise] . . .at any given point in time. This makes it impossible for any long-term integration infrastructure to be based on a specific application, language or system architecture."
"The only way to build an integration infrastructure to last is to base it on the one thing least likely to become obsolete – the data." No matter what happens to technology, people will continue to buy insurance. The data elements required to sell, price, underwrite, process, issue, and service insurance policies will remain relatively constant. The data elements required to completely model an insurance policy throughout its life cycle are not much different today than they were 50 years ago. A large number of additional data elements have been added of course, and a few have fallen into disuse, but, by and large the fundamental data structures required to create and service insurance policies have not changed very much.
An insurance company’s IT infrastructure should be based on the data it needs to store and process. Computer programs and specific technology implementations should be considered expendable, and should not determine the integration infrastructure in any way. "The goal must be to ensure that when they are inevitably replaced with something faster, simpler or more powerful, the replacement causes minimal disruption to [the enterprise IT system]."
"One rarely has a choice in the way data is stored within individual applications but it is relatively immaterial to the overall [enterprise] framework. The key is to ensure that the data can flow between systems . . . in a format that can easily be understood by all."
"Luckily, there is widespread global consensus on the best way to exchange information – a format known as XML (eXtensible Markup Language). XML is the obvious choice because unlike other formats, humans can read it, all computer systems can be modified to understand it and it can contain not only raw data, but information about what the data means through embedded data-description tags." There now exists an ACORD XML standard for property & casualty insurance. Currently, at least eight companies have implemented the ACORD XML standard on a production basis for at least one line of business, and many more have projects in development. At least four vendors have also incorporated this standard in one or more products. The ACORD standard addresses the communication of policy data between agencies and companies. A company specific "envelope" can be defined to wrap around the ACORD standard to accommodate internal needs of an insurance company. The standard is young, and undoubtedly will need some changes based on its first year or two of use, but that can be dealt with gracefully. There will always be some differences among computer systems where different tags are used to describe the same data. "It is certain, however, that translating the tags as messages pass from one system to another is a trivial task compared to translating internal data formats used by different systems."
XML is the ideal way to model the data, and to communicate it between the various systems that need to process it. Its major advantages are: 1) It is open: it is not owned by any organization; 2) It is Transparent: it can be read by any computer or person; 3) It is Responsive: new tags can be added as necessary to describe new types of data.
As Tim Bray, one of the original designers of the W3C XML specification puts it: “XML Can Represent Pretty Well Anything. I don't need to expand on this very much except to note that XML has been used to represent, without loss of information, algebra, bibles, computer programs, database records, email, filings to regulators, GIS data, human-resource data, iTunes collections, journal entries, KR data, logic, manuals, network maps, ontologies, purchase orders, queries against databases, remote procedure calls, schemas, transactions against commerce servers, update logs, vector graphics, winecellar inventories, XXX movie metadata, yearly calendars, and Zen koans. OK, I don't know for sure about the koans.”
We must be careful, however, to be sure that the XML is used in an open manner. "There are ways to use XML and other open standards while perpetuating technology lock-in. It is no secret that technology vendors seek to build technologies that make it difficult for their customers to switch to another vendor. Indeed technology lock-in is one of the most powerful competitive weapons of technology vendors."
It is impossible for purchasers to totally eliminate lock-in, but it can be minimized, controlled, and contained. The two major ways for a vendor to lock-in its customers are data lock-in and Application Programming Interface (API) lock-in. The key to avoiding data lock-in is to own your own business level data structures and standards. The key to minimizing API lock-in is to keep different systems loosely coupled. The strategy is to carefully define high-level interactions as XML representations of real business documents (e.g. policy, claim, endorsement, or substantial chunks thereof such as vehicle, driver, location, etc.) that flow between systems. "Modeling the integration strategy on real data and processes is orders of magnitude easier than modeling it on specific API’s, and breaks the direct dependence on fragile volatile interfaces."
It is important to maintain a clear level of abstraction between a permanently open, transparent and responsive set of processes on the one hand, and the often closed and proprietary technologies that necessarily support it. With XML representations of business data as the core of the integration infrastructure, you can clearly demand compliance with your detailed business-level data standards as a part of your functional specification of any vendor supplied software.
Vendors are sophisticated in the way they implement open standards and protocols entwined with their own proprietary “improvements” to lock-in customers. For additional insight into this problem, read this then read this. As a company, we should have our own vision for how applications will work together in our enterprise for the next decade or more. We should make sure that we do not become slaves to anyone else's vision.
It is recommended that Utica National invest in a loosely coupled, data-centric and customer-centric integration architecture that follows the principles described above, and in this PDF version of a power point presentation. We should follow the principles and methods of an actual integration plan designed by the same people who articulated most of the ideas expressed above. It is used by a system recently installed for the Irish government by a company named Propylon. Please note the Integration Diagrams and the Integration Principles described in that document.
This architecture draws upon lessons learned from the spectacular success, simplicity and scalability of the World Wide Web. It was designed and articulated largely by Sean McGrath, an expert who was involved in the growth and development of XML since its inception. (Mr. McGrath has written about 50 enlightening articles on XML and over 3 dozen equally enlightening articles on E-Business in the Enterprise for IT World.) It is based upon tightly defined data, loosely coupled with an infinite number of processes identified by Uniform Resource Identifiers (URI), using a reliable messaging and translation mechanism. The PropelX product from Propylon provides that reliable messaging and translation mechanism. We should also consider hiring Propylon’s consulting services to help define the finer details of our data-centric integration architecture.
It is further recommended that a project be established, staffed and funded to design and implement the details of this vital, long-range investment in the Company’s future.