Imperatives for externalisation
By: Jurgens Pieterse on 06/08/2000
Organisations must differentiate between their internal architecture and externalisation architecture. The design principles and decision parameters for an internal architecture versus externalisation architecture are very different from each other. Successful e-enablement of an enterprise depends on the design principles underlying its externalisation architecture. Externalisation is a strategy to develop tighter connectivity with external entities like value chain partners, customers and intermediaries by leveraging from the internet. Internal architecture is focused on the efficiencies in transactional processing and data management.
The objective of externalisation is to collaborate effectively in an extended value chain by coordinating activities to gain effectiveness. In the past such value chain designs were very rigid locking organisations becoming into value chain configuration. Externalisation secures value chain flexibility to allow fluid changes in value chain configuration. Flexibility allows the value chain to continuously reinvent itself, based on the value contribution of each component.
In the past architectures developed with an internal perspective with the aim of integrating internal applications and activities. Even well designed internal designs are often weakly designed in terms of external connectivity. The externalisation challenge is to gain increased levels of external connectivity and flexibility without having to replace or invest into new internal a new internal application architecture. Well-designed internal architectures usually leverage from data integration where applications are developed to use a common central database. In weakly designed internal architectures disparate operational systems, multiple directories, lack of common standards and different databases are typical elements that constrain externalisation.
Data integration is feasible for an internal architecture because the designing enterprise has full control over the format of the data structures. This approach cannot work in an externalisation architecture where the data design is not within any single enterprise’s full control. In fact an attempt to integrate data for a value chain might leads to sub-optimisation of the individual value chain components and undermines the objectives of the value chain. The critical design parameters for externalisation are flexibility to adapt to a changing environment and the speed of changing the configuration. The success of externalisation is defined by its ability to integrate into a wide variety of applications and data sources and managing access to information.
· Externalisation must adhere to a few basic design principles. Firstly enterprise application integration becomes the centre focus for externalisation.
· Secondly externalisation demands a single log-on facility and access to information and information technology services for all the participants in the value chain.
· Thirdly a platform must become flexible enough to allow for the plug & play application selection for externalisation applications i.e. customer relationship management and procurement applications.
Externalisation flexibility demands a much more componentized application architecture and leverages from a flexible common data exchange format like XML.
The primary role of application integration is to map different data formats and to route messages between different applications feeding from different data sources. The role of enterprise application integration is to make communication possible between the partners within a value chain irrespective of their internal architectures. Key externalisation issues in selecting an application integration solution are: Secure document exchange, integration into business processes and the flexibility to handle different transfer protocols.
Traditionally enterprises controlled only access of employees to network resources. In externalisation every application within the internal architecture might become a potential information technology service for a value chain partner. Access must be given to diverse value chain partners with diverse needs. Externalisation requires that a network operating platform be selected that provides a single log-on facility from where any external party can get access to any internal network resources without compromising the security infrastructure of the internal architecture. Key externalisation issues in selecting a platform solution are: The number of independent software development for that platform, the platform that will most likely be adopted by the other value chain partners, the manageability of such a solution to define and change access rights and interoperability with other operating platforms better suited for the internal architecture of the different value chain partners.
Externalisation applications are more visible to value chain partners than internal applications. Plug & play flexibility is needed in externalisation to ensure that organisations can switch to new software solutions without any disruption in the interface with value chain partners. Key considerations for plug & play applications are the ability to operate from a 3rd party operational data store, publish information to the web or any wireless devices and utilising a 3rd party directory to manage access to its information services.
In summary organisations must differentiate between internal and externalisation architectures. The drivers for selecting the architecture components are different for the two architectures. Internal architecture requires tight data integration and application stability. Externalisation emphasises enterprise application integration, manageability of access control and flexibility of plug & play applications.
Bottom line: Organisations must use the different architectural principles for designing their internal and externalisation architectures.
© Jurgens Pieterse 2001
