The Business Network is a term introduced to embrace technical, operational and business networking, far more extensive than the current IT networks.
This is a natural progression from the isolated IT systems of the past, via the ERP, office and Internet systems of today towards a business oriented system. This will not be easy to accomplish because of the wealth of separate systems in existence, few of which were ever designed to be integrated with anything else. Even the highly successful ERP systems, dominated by SAP and Oracle have only achieved integration of specific functions in a business and are very difficult to integrate with anything else.
The core requirement to implement an integrated Business Network is a framework which can be designed to manage and control all the individual sub-systems. It is pointless to consider a totally new system because even though many of the current sub-systems are already obsolete, it is impractical to replace them overnight. It will take many years for instance to get rid of the legacy of Word documents, which desperately need replacement with XML based documents before any manageable integration can be achieved.
The integrating framework must thus be application neutral, based on standards and very flexible. It must support development and design tools to implement workflow, collaboration and data integration in the same way that tools are available to design specific IT applications. Much greater emphasis must be placed on business design tools than is the current case with application development; the component architecture must be gradually introduced to replace the so called integrated packages. Since all of this will take years it is important to begin today with the framework so that it is well understood and supported before it can become mission critical. It goes without saying that the framework must provide interfaces which can be tailored to allow legacy systems to be incorporated into the broader picture of the Business Network.
Since there will be such a mixture of applications involved it is essential that a message-passing architecture is used from the beginning. This “asynchronous” approach provides the versatility to interwork a variety of application types. A pair of back-to-back asynchronous connections can if needed create a synchronous connection (e.g. a remote-procedure call), but a synchronous, connection oriented system, cannot simulate asynchronous connections. Those selling systems based on synchronous connections such as client/server or web browser based will dismiss the importance of message-passing as technical hype. It is not, it is fundamental to the success of cooperative applications in a real world. Nor is it enough to say that asynchronous options are available as add-ons to the basic synchronous systems, the core system must be based on asynchronous technology from the start. This doesn’t mean that asynchronous systems like Web browsers, SOAP, ODBC, etc. are wrong, they are most useful, but not for the core integration framework.
Fortunately the Web has thrown up two key standards which I would claim to be essential to an integration framework, XML and Java; it is unwise to consider any other products. Further many major application vendors, SAP in particular are pushing their own integration tools, but this too should be resisted. The integration framework should be a neutral system, independent of any application. It must provide the tools to build integrated front-ends, workflow management and other operational and management applications, but not core business applications themselves.
The application framework must provide connectors to access the functions and data in the existing applications, standard ones for the common applications, tools to build the connectors for others.< BR>
Martin Healey, pioneer development Intel-based computers en c/s-architecture. Director of a number of IT specialist companies and an Emeritus Professor of the University of Wales.
