Manage Learn to apply best practices and optimize your operations.

EAI maturity is a process, not a goal

Enterprise application integration (EAI) will be key as long as there are enterprise applications coming from disparate sources. It isn’t going away any time soon.

I have long believed that the ideals of software development can be distilled in a small set of basic principals. For example, the more abstraction the better (more power to the people), late binding beats early binding (defer decisions as long as possible, but no longer), high cohesion is good (everything in a module, component or object should be related to a single purpose or theme) and strong coupling is bad (too many dependencies resulting in ripple effects during maintenance). And, when it comes to integration, proprietary interfaces are bad (lock in, loss of flexibility) and open standards are good (encourage and simplify development and integration).

With that worldview firmly fixed in my belief system, the goal of EAI should be simple – buy or build only well-structured enterprise applications and integrate them using an open standard that should have evolved from the gooey mass of alternatives that has been with us since enterprise architects pulled us from the spaghetti-code tar pits. It hasn’t happened, and I confess that I don’t always practice what I preach.

Yes, as we close out 2010 and I ponder EAI trends, I am painfully aware of the fact that I have bet my personal infrastructure on a relatively closed platform (Mac, iPhone…) and have no intention of changing that to more open alternatives. That leaves me struggling to integrate applications (like Salesforce) that don’t want to take data from my proprietary Mac address book without jumping through hoops. Here are three lessons I’ve learned in over three decades of computing:

Every significant new system has to work with old systems and data, and that requires some form of EAI.  Businesses will continue to buy enterprise applications in perpetuity, but the introduction of new systems rarely results in the removal of another system of similar complexity. No significant enterprise application today is sufficiently open as to allow interoperability with systems from other vendors without EAI. It is the mortar to enterprise software bricks.

Enterprise applications vendors will always embrace standards, rarely fully agree on them, and never limit functionality to adhere to standard interfaces. As it was in the beginning, it will be in the end. From enhancements and proprietary extensions to the first ANSI COBOL compilers to ERP and CRM systems, the “secret sauce” of functionality will always trump the idealistic goals of interoperability. The results will be systems that require EAI.

There is always room for a new class of enterprise system, so imagining that your portfolio is complete and won’t need further integration is naïve. For example, enterprise energy/carbon management (EECM) software is emerging, and will mature from being an interesting concept to a must-have for compliance and competitive reasons in the next 5 years. Your EECM system will need data from existing systems, such as your ERP and HR systems, and will provide data to your compliance and planning functions.

If that sounds like doom and gloom just as the New Year approaches, I should mention three reasons for optimism. First, some standards for integration emerged, matured, and endured, largely due to shared interests and business dependencies. For example, SWIFT, the Society for Worldwide Interbank Financial Telecommunication, developed standards and a “proprietary communications platform” (from the Swift website) used by over 9,000 financial services firms in 209 countries. It isn’t going away. This stability was made possible by the underlying organizational structure of SWIFT as a highly collaborative member-owned cooperative. Since typical trades involve multiple parties communicating in a low latency environment, it is in everyone’s best interest to contribute to and use the results of the SWIFT team. Unlike commercial vendors, this is truly end-user driven and therefore far more stable than a product built to optimize quarterly balance sheet results.

Related to the collaborative motivation for SWIFT, my second reason for optimism is the relative stability of the open source software community that has brought solutions such as Apache ActiveMQ and ServiceMix, as well as OpenESB and others. When the common interests of so many organizations converge to spawn an enduring open source project, it portends well for interoperability with other open source projects and simplified EAI.

Finally, the emergence of the public cloud computing model provides strong motivation for vendors to simplify EAI requirements. As enterprise solutions are increasingly offered on a pay per service model, simplifying EAI to enable near real time changes in resource allocation and interoperability will mature from nice to have to must have, and vendors who cling to proprietary ways will ultimately lose share to more nimble competitors.

 

Adrian Bowles

Adrian Bowles heads SIG 411, LLC, an independent analyst/advisory firm covering green information management and other technology solutions.

 

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchAWS

SearchCloudComputing

TheServerSide.com

Close