|
1 The Need for Functional Re-use
Businesses in fast moving markets need the capability to respond rapidly to changing market conditions, and flexible IT systems are crucial in enabling the business to respond quickly and cost effectively. This is a major business motivator for reuse, where existing functionality can be leveraged by multiple processes, and new processes can be facilitated by the building of composite applications using an amalgamation of existing functions. Monolithic applications do not help in this regard as they provide little capability to respond to rapid changes - each new process requires new coding, as well as hard connections both within and across applications. However, with a set of services that provide common business functions useful across all the different applications for developers and users to take advantage of, new applications can be created or current applications extended rapidly.
The traditional monolithic application development approach also means that identical (or at least similar) functionality gets replicated numerous times across applications in the enterprise. This has an impact on management, overall cost of licensing, and even computing capacity requirements, and as more emphasis is placed on the utilisation of technology within the organisation, we are fast approaching the position where the real estate, power and cooling requirements of even a basic infrastructure becomes a significant part of the IT budget. Not only is such reinvention costly in terms of time and effort, but perhaps more significantly, also is prone to introducing errors that could impact the organisation's capacity to transact business. Single instances of functionality are inherently more manageable, as reusable services are not only ?build once? but also ?maintain once?.
Historically, there has been little in-built capability for other applications or processes to make use of the functionality embedded within existing applications ? highly expensive, often proprietary approaches for systems integration have been required, and any changes to one part of an infrastructure has generally led to the failure of the overall process as incompatibilities have been found. However, with the advent of web services and service oriented architectures (SOAs), we are now in a better position to look at how we can move to wards a more reusable approach to function, and so create a more responsive, flexible, manageable system that utilises more of the hardware assets we have at our disposal.
2 Background to Software Re-use
Software re-use is not a new concept. Although it did not enter mainstream software application development until much later, object-oriented programming has it origins in the Simula programming language of the 1960s, and the idea of software components was first espoused at a NATO conference on software engineering in 1968. Many vendors have tried to provide their own means of managing functional components in the past, generally through coding environments. Digital Equipment Corporation (DEC) had the Distributed Directory Service (DDS), where libraries of code could be stored, and vendors such as Borland, Rational and so forth provided the means of storing uncompiled code items that could be brought in to new code as required. However, these systems were highly vendor specific, with little capacity for interoperability, and still generally required a code compilation prior to any usage. Similarly, Microsoft's DCOM (Distributed Component Object Model), introduced in 1993 to enable interprocess communication in any programming language that supported it, was a proprietary platform that worked only on Windows.
The first real attempt at a fully independent capability for code reuse was with the Common Object Request Broker Architecture (CORBA) in the 1990s, which attempted to create a standardised environment for the exchange of information between discrete items of functionality. A standard defined by the Object Management Group (OMG), CORBA enables software components written in multiple computer languages and running on multiple computers to interoperate. Unfortunately, CORBA adoption was piecemeal, and the standards could not easily be retro-fitted into existing environments. While it promised to deliver much in the way code is written and software is constructed, CORBA failed to deliver on some of its promised features, sometimes even the most fundamental ones.
|
