Sometime in the last 15 years the way systems were developed began to change. Or rather, the purpose of the systems began to change. The big box system, that massive application that “did everything”, completely covering the functionality of the company (such as ERP systems or CRM systems) or the functionality of the large business department (such as Billing), began to decompose.
Business people started demanding a level of detailed functionality in what were previously niche areas of the big system. The niches became complete systems of their own. Whether a logical break off of the big box system or independent smaller systems of their own, suddenly supporting business functionality was outside the box. And real integration began.
Conceptually integration is nothing new. The billing system has been passing data to the accounting system (for example) for the past 40 years. What has changed is the type of integration and the significance of the integration.
Previously (as an example) the billing system would package up the financial data after a billing run and send it over to the accounting system for appropriate corporate financial updates. The billing system wasn’t dependent on sending the data, and the accounting system would continue to operate just fine (if somewhat out of date) without receiving the update. They remained independent systems, neither directly affected or reliant upon the other.
However (as an example) when the customer management system was developed and the business responsibility for maintaining and managing the customer data moved out of the billing system, the billing system could no longer operate without a direct customer feed from the customer management system. Systems became directly dependent upon each other (aka tightly coupled) and the importance of integration moved from a minor component of the IT environment to a key operational factor.
This has been a gradual shift with many an IT shop not realizing the true impact. They have developed an accidental enteprise integration and an associated accidental integration architecture.
We'll explore what this means in the next article.
Business people started demanding a level of detailed functionality in what were previously niche areas of the big system. The niches became complete systems of their own. Whether a logical break off of the big box system or independent smaller systems of their own, suddenly supporting business functionality was outside the box. And real integration began.
Conceptually integration is nothing new. The billing system has been passing data to the accounting system (for example) for the past 40 years. What has changed is the type of integration and the significance of the integration.
Previously (as an example) the billing system would package up the financial data after a billing run and send it over to the accounting system for appropriate corporate financial updates. The billing system wasn’t dependent on sending the data, and the accounting system would continue to operate just fine (if somewhat out of date) without receiving the update. They remained independent systems, neither directly affected or reliant upon the other.
However (as an example) when the customer management system was developed and the business responsibility for maintaining and managing the customer data moved out of the billing system, the billing system could no longer operate without a direct customer feed from the customer management system. Systems became directly dependent upon each other (aka tightly coupled) and the importance of integration moved from a minor component of the IT environment to a key operational factor.
This has been a gradual shift with many an IT shop not realizing the true impact. They have developed an accidental enteprise integration and an associated accidental integration architecture.
We'll explore what this means in the next article.