MetadataShow full item record
AbstractEnterprise architecture is undergoing considerable change with recent developments in client server technologies and middleware. Each in turn has a significant impact on the way systems are designed, and a more component-based approach to development is beginning to emerge. While we now have the Unified Modelling Language as universal notation for design modelling, there is currently no consistent standard for the definition of components. A pragmatic architecture for application development is needed that delivers business benefit without the need for significant investment in tools and training. It should minimise risk and maximise return on investment by leveraging investment in legacy systems, and provide the means to more closely relate business requirements to each phase of the development process. This paper suggests that a better way of controlling technology is by adopting a service based approach to design and development, concentrating on pragmatic techniques and models that add value through reuse within a sound architectural framework. Given a set of business requirements, the focus is on business oriented component modelling techniques (e.g. process models, use cases, service allocation), and the delivery of a complete component design specification (e.g service definitions, service package architecture). Unusually, this does not involve the definition of a domain class model, but rather a definition of implementation independent, and therefore reusable, services (or contracts) that component packages will deliver. The component package is regarded as a ‘black box’ from which components will be designed and built by specialists in the technology of the component domain. This approach also provides the means for legacy and packaged applications to be reused in the same way. The methodology was evaluated by a peer group of six senior IT professionals from the insurance and IT services sectors, who together represent over 110 years of industry experience. The methodology was presented in the form of a case study and questionnaire, and from the feedback it was concluded that there was merit in the approach. Reservations over how it would scale to larger systems have been addressed by the agreed need for a suitable repository for the documentation of data and business rules, and the need to separate the definition of technical non-functional requirements.
TypeThesis or dissertation
The following license files are associated with this item: