Agile enterprise, Component software, CIM

Abstract

Recent developments in global commerce has meant that manufacturing enterprises are required to be more customer focussed, get their products to market faster and be willing to co-operate with others in order to remain competitive in bidding for projects. This paper considers the characteristics and properties of next generation software systems that will be required to support the agile enterprise. It proposes a component-based approach to system development based on an underlying architecture that positively supports the requirements and characteristics of an agile enterprise.

1. INTRODUCTION

A recent study by a group of American industrialists stated "The key finding of this report[1] is that there is a common infrastructure requirement for all agile manufacturing enterprises, regardless of their industrial sector. The common infrastructure will be used in different ways by different industries and different firms within the same industry. Consequently, companies and industries can work together to build the infrastructure, even while competing in the products and services it enables them to provide. The infrastructure will be used to tie production processes together and to integrate those production processes with other parts of the company, and with parts of other companies, and with parts of different companies, into a single system. When the system functions efficiently, it allows companies to easily and quickly meet the needs of a rapidly changing competitive environment. In effect, the infrastructure will enable the formation of agile manufacturing enterprises, capable of responding to the fast changing market needs and manufacturing demands of a global economy"

The focus of this paper is on software systems capable of enabling the development of the agile enterprise. In particular it looks at characteristics/properties that these software systems will have to exhibit. It considers various technologies which promise to enable more agile software systems to be created. Finally, a prototype model which is being constructed at MSI Research Institute is described and further work is detailed.

2. REQUIREMENTS OF NEXT GENERATION SOFTWARE SYSTEMS

Before considering requirements agile enterprises on next generation software systems, it is instructive to consider the current status of software systems and to see why these are not appropriate.

Berg[2] characterises current systems as "monolithic blocks made up of a large number of interrelated parts, with the relationships between the parts being mostly implicit". Berg here identifies key issues which constrain their use in agile enterprises, as follows.

• Monolithic blocks: characterisation here is of a black box approach to software, inputs and outputs are defined but in between nothing is observable by the user. The black boxes also contain functionality and data mixed together, which resides in one physical place (i.e. within a software process or on one host computer platform).
• Interrelated parts: characterisation here is of a tangled mess of parts reliant on other parts without any clearly observable structure.
• Relationships implicit: characterisation here is of a system which could not readily adapted or replaced.

It must be emphasised that current generation proprietary software systems have adequately supported and automated enterprise operations in the past and continue to do so where rates of change are low. However their continued deployment will limit the response times of enterprises wishing to compete on the basis of their agility.

In agile enterprises "..., the software must be able to scale up or scale down to accommodate these changes. As the operations of the enterprise are redistributed geographically, so must the information systems that serve them. As business processes are reengineered, the information systems must be able to immediately adapt, so the software must be flexible enough to accommodate new functional requirements and be reconfigured without long system development cycles"[3]. System Software Associates Inc (SSA) have identified some of the properties required from the next generation software systems. Namely these systems will need to be:

• Scalable: the scope of the software system should have the ability to grow (and contract) with the enterprise.
• Distributed: it will be necessary to locate the software (functionality as well as data) where it is required and most effectively deployed.
• Adaptable: this is the ability of the systems to be driven by the enterprise rather than what currently often happens in that the enterprise operations are modified to suit the properties of available software systems.
• Flexible: relationships between elements of the software system need to be explicitly defined but loosely coupled together so that new relationships can be established as required.
• Easily usable: focus is not on user interface issues (although that is important) but rather on how the software fits with the users knowledge of their domain

Whilst these above characteristics for software systems are the focus of this paper, there are other important features of software systems which typically be required support the agile enterprise such as:

• Platform neutrality
• Security
• Maintainable
• Fault tolerant

Nagel and Dove[4] reiterate the above requirements but add another requirements dimension for next generation software systems by stating "The enterprise integration enabling software in the agile manufacturing enterprise will be ..... accommodating to entrenched legacy systems and subsequent migration strategies".

3. CURRENT APPROACHES TO SOFTWARE SYSTEM DEVELOPMENT

A major hurdle to the development of agile enterprises is their installed base of software support systems. Typically such systems have been supporting the enterprise for many years. Hence they have known qualities and faults will either been eliminated or at worse they are known about. This will have incurred significant investment. However unfortunately as discussed in the previous section, generally they will not have inherent capabilities which support the development of agile enterprises.

Current practice in overcoming this problem corresponds essentially, to two options:

• Migrating the current system or
• Replacing current systems with more appropriate software system(s)

This paper recognises that the choice is not a simple one between migrating software as opposed to replacing. Short term gain from migrating an installed base of software so that it functions as part of a wider scope system should be viewed as part of an overall strategy, aimed at re-engineering an enterprise. On its own it cannot solve underlying problems ensuing from:

• Architectural discrepancies: generally the software architecture required by agile enterprises is different from the underlying architectures of many current software systems. The danger with any migration is that the new architecture will not be fully realised by the strategy and hence system developed will be limited. Current research[5] is seeking to identify common migration patterns to facilitate software migration but generally such work is in its infancy.
• Code identification process: it may be possible to identify a "block" of code that needs to be wrapped and used in a new system but in all probability this block of code will be intermeshed with other sections of code and so normally it will not be a simple case of "cut and paste". Current research[6] is examining ways for which this process can be automated but currently much of this work is more exploratory than practical at this stage.
• Maintainability: generally the process of migrating software so that it becomes part of a particular system is a linear process aimed at a fixed and pre-determined end-point. Unfortunately as the business world becomes the probability is that by the time a migration project is underway, the end-point will have changed and will continue to do so to meet new business requirements.

Therefore, this paper proposes that future software systems should be based on a more appropriate software architecture which positively supports the requirements of the agile enterprise as outlined previously.

4. A COMPONENT ARCHITECTURE

Recognising future requirements many major software vendors have adopted a new approach to software development. Cox[7] states it as "..the possibility that the software industry might obtain some of the benefits that the silicon chip brought to the hardware industry; the ability of a supplier to deliver a tightly encapsulated unit of functionality that is specialised for its intended function, yet independent of any particular application. The silicon chip is the unit of hardware reusability that has most conspicuously contributed to the hardware productivity boom. Might the Software-IC concept do the same for software?"

Carmichael[8] reinforces this view by stating "Building from components should at least allow systems to be constructed from pre-validated parts, and to be incrementally improved by replacing components with others which provide equivalent services but with enhanced performance or new features." Currently a number of technologies have been proposed as being suitable to underpin a component-based approach to software development. These include, Microsoft with their OLE/COM and DCOMs/ActiveX, OMG with its OMA and Sun with JavaBeans.

Whilst the availability of these technologies is an important move along the right path to facilitate the engineering of agile enterprises other complimentary advances are required. Current developments support systems integration at a syntactic level.. Agile enterprises require integration at a higher business level, i.e., at the semantic level with composable integration support at runtime. If this is to be achieved then components themselves will need the following capabilities, namely:

• Semantic integration
• Intelligent messaging
• Capability description
• Implementation description
• Context independence
• Dynamic configurability

4.1 Required Characteristics for Components

The following sections describe in more detail the above characteristics/properties and provide examples why they are necessary to enable the agile enterprise.

4.1.1 Semantic Integration

A popular means for enabling integration between two software components is by specifying a set of APIs (with description) or by using an interface description language which details the attributes and methods supported by the component. The providers of these components hope that by good use of variable and method names that their proper use will be evident. Consider the following API that was designed to support the notion of person1 buys house from person2 paying an amount of money (Example given by Halim Kirov in a presentation on semantics, OMG Meeting, Tampa, USA, January 1997).

Contract (house, person1, person2, money)

Whilst this seems relatively self-explanatory, another user could misinterpret this API as performing the following operations:

• person1 rents house from person2 for an amount of money per month
• person1 builds house for person2 for an amount of money
• person2 baby-sits for person1 for an amount of money per hour

Clearly there is a requirement that more of the semantics are captured in the interface description (or somewhere else) to enable the composability of systems contained within agile enterprises.

4.1.2 Intelligent messaging

Currently most systems utilise a very simple model of messaging. This model allows for peer-to-peer, broadcast, blocking, and non-blocking modes of operation. The result being that systems built using this model use mechanistic, design specified interactions alternative behaviour is limited. In the agile enterprise, there has to be some notion of intelligent messages such that components on entering the software system can notify others and can advertise capabilities. In our contract example this might entail the initiation of a dialogue with a banking object to transfer the funds

4.1.3 Capability description

One of the essential features of any future component-based development system is the ability for components to be able to advertise their capabilities to all other components at run-time. In our contract example, the component may advertise these following capabilities:

• support the house buying process
• support the general notion of transfer of ownership between two people
• support only the purchase of private property and not commercial property

4.1.4 Implementation description

Another important issue to be resolved in the types of software systems required to support the agile enterprise is the ability of the component to advertise how it is intended to be used. This quality is different from the semantic integration issue as it provides design and intent information on the component. In our contract example the component might need to show:

• does it initiate the transfer of funds between the respective banks
• does it check that person1 has the money it says it has
• does it check that person2 is the legal owner of the said property

4.1.5 Context independence

A fundamental notion is that if designed correctly component re-use becomes a reality. In practice the context is embedded within components and this limits the scope for re-use. In our contract example the component has been specifically designed for a house buying process whereas it might be possible to design a more generic sale component which can obtain information from the house buying process.

4.1.6 Dynamic configurability

The notion here is that systems should have the capability to change over time either in response to changes in the component soup or by a particular user re-configuration.

4.2 A Component Model

One of the difficulties in using the term component at present is in the lack of a formal description. Drawing from the characteristics/properties outlined in the previous section, Figure 1 provides a model to which components should be developed and used.

Figure 1. UML Class Diagram for Component Architecture

A number of points should be noted about this model:

• It has this notion of composable systems i.e. systems consist of sets of components
• A component may play multiple roles within the system
• Components may require other components before the desired system is realisable
• The underlying infrastructure required to support this type of composable system is significantly different than typically exists to-day[9]

5. CONCLUSIONS

In conclusion, it is the premise of this paper that current generation software systems will not actively enable the agile enterprise. The agile enterprise requires a responsive software system to both change and its environment. One approach to this is by the use of components based on the model proposed in this paper. Further work at MSI will continue to explore these issues and develop systems based on this architecture.

ACKNOWLEDGEMENTS

The author would like to thank members of MSI for their help in formulating these ideas and in particular Prof. Richard Weston for his comments on this paper. The author would also like to thank CDP/EPSRC for their continued support in this area.

REFERENCES

[1] Nagel, R. and Dove, R., 21st Century Manufacturing Enterprise Strategy. An Industry-Led View, Vol. 1, ISBN 0-9624866-3-9, 1991.
[2] Berg, K. Component-Based Software Development: No Silver Bullet, But More Than a Vision, Object Expert, Vol. 2(3), 1997.
[3] System Software Associates Inc., BPCS Client/Server Distributed Object Computing Architecture, 1995.
[4] Nagel, R. and Dove, R., 21st Century Manufacturing Enterprise Strategy. An Industry-Led View, Vol. 2, ISBN 0-9624866-4-7, 1991.
[5] O'Callaghan, A., Software Architecture and Object Migration, Object Expert, Vol. 2(3), 1997.
[6] Ning, J.Q., Engberts, A. and Kozaczynski, W. , Automated Support for Legacy Code, Communications of the ACM, May 1994.
[7] Cox, B. J., Object Oriented programming. An Evolutionary Approach, Addison-Wesley, ISBN 0-201-10393-1, 1987.
[8] Carmichael, A., Seeking a Unified Component Model, , Object Expert, Vol. 2(3), 1997.
[9] Weston, R.H. and Coutts, I.A. Integration Infrastructures for Agile Manufacturing Systems, in Handbook of Information Systems Architecture, Springer-Verlag, tbp 1997.
1
2 This model is an alpha version of the component model being developed by the author and is liable to change.