Outline of ProgrammeX

8.1 Introduction

The most critical issue in the delivery of the ICT solutions in the 21^st century will not be the hardware but rather the software, the applications that support the new forms of business like Web Enterprises. The developments in hardware and networking will provide enough processing, storage and communication capability. However with the current approach of software development it will take many years to deliver the applications that really support reinvention of the business and take maximum advantage of the capabilities of the information and communication technology.

Software development is still a 'craft' industry. Programmers build tailor-made applications from scratch. The problems are the long development time and high costs for new applications and the reality that the resulting systems usually do not fully meet the business requirements. These difficulties affect even more the adaptation of existing systems. Development time and costs of modifications tend to grow over the years. Eventually it becomes impossible to meet the changing business requirements with the existing system. A total replacement with a new system is necessary.

Solutions for these problems are sought in packages or in better methods and tools.
Application packages are an alternative, but still need costly implementation projects and adaptation of the business processes to the functionality of the packages. Packages have their own architecture, which is not always adjustable to the structure of the business. Normally a package does not support all business functions in the supply chain. So it is necessary to extend the functionality with other packages or tailor-made applications. Packages do not integrate well with existing applications and the package may need ICT infrastructure other than the current installed one. Maintenance of existing package-based systems is still expensive and time-consuming especially with regard to the necessary upgrading caused by new releases.

Methods and tools have streamlined the design and development process and realised a first industrialisation of the application delivery. But methods and tools did not improve the adaptability to the business of the resulting applications. Reason is that methods and tools strongly focus on the improvement of the development process and not focus on an adaptable construction of the applications.

The only way to bridge the application gap is to reinvent the construction of applications. The car industry is a good example. This industry realised a shorter life cycle of design, development and production of their products through standardisation of the product components. The car industry is also able to mass-produce cars that within certain limits can be customised to the wishes of the client.

Application developers also need an application construction, which is based on components. Cap Gemini believes that the solution for coping with the challenge of application development in the 21^st century lies in a new approach of the application construction: Component-Based Development (CBD)

CBD is a new and rapidly emerging approach for application development by plugging together previously built components. This paradigm is not something new. It has already been endorsed by many industries.

Most application developers do have some notion of the essence of a component. It has encapsulated functionality and a well-defined interface providing some service. But in practice a wide variety of different types of components exist, because the value of components depends on the beholder. For example for the IT engineer components are a persistency manager for objects or a transaction manager for secure transactions. For a business architect components are a pricing pattern or a financial product. An application developer is more interested in components like an order window. Apparently the concept of componentisation applies to all levels of abstraction, from business models to technical components and from design models to software coding.

However, the way that all these different types of components can be adapted to meet specific requirements and how they interact with other components has not yet been demystified. The solution in our opinion is by no means just a matter of precise specification of a single component. The solution also is not an approach where developers freely choose their components and simply have a working software system in the end. Components should not be regarded as solitaire phenomena. Instead, they must be bound to a specific context to ensure proper construction and operation.

Cap Gemini believes that the metaphor of a marketplace where developers buy their components only can be realised with the concept of frameworks that offer an appropriate context for the assembly of components.

In this chapter we introduce the Cap Gemini approach of CBD. This approach is based on the following concepts:

• The component as the basic element for application construction.
• The framework as a special component that provides context for component construction.
• A Component Architecture prescribing the use of components and frameworks in design and construction of applications

The Component Architecture is part of the Information System Architecture. The Information System Architecture focuses on the role of applications in the business (the function aspect), whereas the Component Architecture focuses on how applications are composed from software components (the construction aspect).

8.2 The Car Metaphor

The construction of cars can act as a metaphor for the ideas about application construction with CBD. Also the car industry was at first a "craft'' industry. Every car was individually designed and hand-made in accordance with the requirements of the customer. This was a very time-consuming and expensive way of building cars. The first step in industrialisation of the car industry was mass-production. Mass-production is based on standardisation of both the car and the production line. The result has been fast and cheap production of a uniform type of car.

But customers want a greater variety of the product. They want a car that fits their wishes and which they still can afford. So the next step is mass-customisation of the product and a flexible production process. An important principle in mass-customisation is a better choice of the granularity of the reusable components.

Mass-production has standardisation of the parts. This is standardisation at the level of nuts, bolts, spark plugs and tyres. This is also useful for the efficiency of mass-production. The production of the parts is done by a number of suppliers, who mass-produce the parts at low cost. More suppliers can deliver the same type of part.

Mass-customisation is also supported by standardisation. But this is standardisation of components at the level of sub-assemblies of the car like the motor, the gearbox and the wheel suspension. This level of standardisation of sub-assemblies allows for different combinations of the available components, so customers can be offered a greater variability of the product.

A certain car type is currently based on a standard floor pan, which acts as frame for the mounting of different engines and different body types like a sedan, hatchback or wagon. Customers can choose the body-type, combine it with a certain type of engine and gear-box, choose a luxury level of the interior and the exterior colour and then fit the car with a lot of accessories. Thus customers can order a car that is customised to their wishes.

The car manufacturer needs a context for both the design and construction of these components at the level of sub-assemblies. In the component-based approach of Cap Gemini, we use the framework as the context for design and construction of application components. The idea of the framework is used in the car industry in the following ways:

• Framework as Construction Frame
  A frame is the part of the sub-assembly that supports the mounting of other components and parts. An example is the floor pan as frame for the whole car construction.
• Framework as Design Framework
  The car industry uses Computer Aided Design (CAD) for the design of new car types. This provides the opportunity to reuse the design of existing components in the design of a new car. The designer can adapt the design of components or let the component supplier design a new component. The designer can also reuse a design framework. That is the design of a complete sub-assembly of components like a complete motor, a complete wheel suspension or a steering-column. The framework defines how the components and parts of the sub-assembly work together. So the framework has already a lot of complex functionality, which is invented and designed earlier. The designer can adapt the framework and the components it already defines, for the design of a new sub-assembly for use in a new car-type. The result is a faster design of new cars and reuse of inventions, creativity and knowledge, which were developed earlier.
  
  

8.3 Component Architecture

8.3.1 The Role of a Component Architecture

When CBD is put into practice, it is necessary to divide the development organisation in component developers in the role of component supplier at one side and developers of software systems assembled of these components in the role of component consumer at the other side.

This division can only be effective when a common basis is provided for suppliers and consumers of components. A Component Execution Environment (CEE) like COM or CORBA provides a partial solution. CEE's mainly focus on the technical issues concerning the communication between running software components. A component architecture is needed to provide suppliers and customers a set of rules, standards and guidelines that prescribe what components are and how they are assembled in software systems.

8.3.2 Component Architecture Principles

A component architecture in our view is a set of principles and rules according to which a software system is designed and built with the use of components. This paper focuses on the principles that are independent from the business domain or the technology of the application. This architecture is the base for more specific architectures defining the principles and rules for components in a specific business domain.

The component architecture covers three aspects of a software system. These are:

• Building blocks
  The architecture specifies the type of building blocks systems are composed of.
• Construction of the software system
  The architecture specifies how the building blocks are joined together when developing an application. The architecture describes the role that the building blocks play in the system.
• Organisation
  Components are divided in categories based on their functionality. These categories are placed in a two-dimensional layering.
  
  

8.3.3 Benefits of the Component Architecture

The component architecture supports the developers in realising a coherent and consistent design of a component-based software system. Such a design based on the component architecture must be profitable for the following reasons:

• Flexibility
  The component architecture allows software developers to adjust a software system smoothly to changing business requirements and new technology
• Specialisation
  The component architecture supports specialisation of component developers. Technology-oriented people build technical components and business-oriented people focus on business components.
• Minimal impact of changes
  The component architecture separates in a software system the more stable components from the more volatile components. Most changes in a software system remain restricted to the more volatile components.
  
  

8.4.1 What is a Component?

A component is a piece of software or software design with a well-defined interface and hidden internals. The component is based on a concept, which is recognisable and of value for its user such as another component, a software system or a human user. The interface of a component contains its features, showing what the component can deliver. Examples of features are services, timer events, attributes, tools etc.

So, a user knows what the component can deliver, but does not know how the features are performed.

There is little to say about the size of a component. A component that keeps stock of a CD collection could be small. If the component keeps track of trends in music, register information about artists and relate the CD collection to all this, it is considerably larger.

The behaviour of a component has different aspects. The CD-component consists of a GUI that allows to enter data, it defines domain-objects such as 'CD' and perhaps 'Artist', it stores objects on your hard disk and it provides business logic 'behind the screen' to make it look intelligent. All these aspects may be combined in one component. However a complex component is more flexible and easier to maintain when it is constructed as a collaboration of a number of components, each realising some specific aspect of the total behaviour.

We prefer to assemble our applications from components at the level of sub-assemblies that support a specific business or technology role and not from components at the level of parts like the screws in the car metaphor.

8.4.2 What is a Framework?

The literature provides different definitions of frameworks.

The Butler Group defines:

"A framework is a pre-built assembly of components, together with the glue logic which binds them together and is designed to be extended. A framework is designed to offer a large number of related services centred on a broad theme. The framework may also be treated as a component by other clients which use its services, so the whole framework may offer its services through IDL specified interfaces."

The definition of Jacobson adds an object-oriented flavour:

"An abstract subsystem is a subsystem that contains abstract and concrete types and classes designed for reuse." and "Ideally a good framework is designed so that specialisations can be constructed from its abstract types and classes with ease."

 

There is a harmony in the different definitions of what a framework is. Both definitions say that a framework creates a context for the assembly of components in an application.

A framework is a special kind of component. It has the interfaces of a component and it also offers plug-points on which other frameworks or components can build.

A plug-point prescribes a role that must be played by a component or framework that uses the plug-point and it defines the rules that the developer must obey when developing a component or framework that plays the role.

Plug-points represent concepts defined by the framework that provide a context for development of applications. A framework creates de facto standards because developers must follow the rules that are put down in the framework. Therefore these frameworks are powerful elements for organising component-based software development.

8.5 Construction Principles

The construction principles prescribe how a software system is composed from components and frameworks.

8.5.1 Dependencies between Components

CBD has construction principles that prescribe how applications are composed from components and frameworks.

Component and frameworks can make use of another component or framework in two ways:

• through the interface
  The component or frameworks calls the services of the other component or framework that are defined in its interface.
• through a plug-point
  If the used component is a framework the using component can create a special relationship with B by plugging into B's plug-points. There are essentially three types of relationship possible between a component and a framework:
  • Component extends framework
  • Component uses framework
  • Component inherits from framework

  These three types seem sufficient to describe the way in which a framework can give context to the construction of components.
  
  

8.5.2 The Extends Relationship

In the extends-relationship the plug-point represents an interface. The plug-point defines services that the component using the plug-point should deliver. The functionality of the component is an extension to basic functionality delivered by the framework.

An example is the Windows printing framework that plays a small but important role in many Windows applications. The printing framework provides the basic functionality that is common to all printing services such as printing and viewing of a document. The framework does not deliver the specific functionality for all the different printer types that Windows users utilise. Therefore the plug-points of the framework prescribe abstract components such as printer and viewer that must extend the functionality of the framework for printing and viewing services for a specific type of printer. The plug-point provides a clear definition of these components, their interfaces and standards that printer manufacturers must follow when developing the printer and viewer components for their specific printers.

8.5.3 The Uses Relationship

In the uses relationship the plug-point represents a class, which can be abstract or concrete, for instance the class Person. The plug-point defines the common behaviour of all persons. The component that plugs into the plug-point creates an 'alter ego' of the plug-point-class, for instance the class Customer or Employee. These classes are roles that persons can play in the organisations. The 'alter ego' Customer uses the functionality of Person and adds own features for the Customer role.

The uses relationship is useful for shared data. In many, if not all organisations registration of persons is centralised. When the only issue is the sharing of data, person can be an 'ordinary' component and other components simply share the person-data by calling the interface of this component. The uses relationship offers more: alter ego's can have their own attributes and associations.

8.5.4 The Inherits from Relationship

In the inherits from relationship the plug-point represents an abstract class in the framework. Plugging into the plug-point means creating a specialisation of the plug-point in the component.

An example is an 'Agent' framework. The components in the framework support complex task management functionality. A plug-point provides this functionality through an abstract class called 'Agent'. Developers realise business components with agent functionality as a specialisation of this class such as task managers or workflow managers. This Agent components have the behaviour for controlling tasks, delegation of sub-tasks to other Agent components, handling conditions and more. The components can suspend a task and 'freeze' its state so that it can be continued at some other time.

8.6 Organisation Principles

These principles focus on grouping of components and the boundaries between components to provide a basis for organisation of development and maintenance of components and software systems.

8.6.1 The Component Architecture is Two-Dimensional

Layered architectures based on frameworks, components and OO have proven to be very suitable to organise software, designed for change. Jacobson defines a layered architecture as a software architecture that organises software in layers, where each layer is built on top of another more general layer.

This paper proposes a two-dimensional component architecture. The first dimension defines a software system in layers of generality in conformance with Jacobson. The second dimension defines a software system in layers of volatility.

8.6.2 Components in Layers of Generality

In the layers of generality the upper layers contain more application specific components and the lower layers contain more general components. A typical layered architecture comprises three layers: a system utility layer, a business layer and an application layer, but more layers are allowed.

The system utility layer forms the bottom layer providing business independent system utilities such as printing, notify mechanisms, logging and so on. The layer contains components that provide generic components and frameworks that support concepts like agents and printers.

The business layer forms the middle layer providing components with generic business functionality and frameworks that define and support complex business concepts through their plug-points. The number of middle layers is not fixed. Sometimes a distinction between a common business, business, sector specific and company specific layers are suitable.

The application specific layer is the topmost layer containing the components that are only used in a specific application. These components are not used in other applications.

The system utility and business layer support reuse of general business and system utility components and frameworks in different applications. This accelerates the application development.

The system utility layer separates complex IT functionality from the business-oriented functionality in the higher layers. The developers can perform changes in business logic and system utility logic more independent of each other. The layering also supports the separation of the development organisation in IT oriented and business-oriented developers.

8.6.3 Components in Layers of Volatility

Volatility is a second argument for layering of software components. This layering is orthogonal to the generality layering.

The objective of this layering is to separate the more volatile functionality of software systems from the more stable functionality. The layering discerns the following components:

• Interface components that support on the most volatile part of a software system: the interface with human users and other systems.
• Process components that focus on processes. These components support for instance workflow logic and transaction processing.
• Domain components that support stable information and procedures in a certain business or technology domain.

There is a one-way dependency relationship between interface, process and domain components. Domain components are unaware of the process components that use them. The process components are independent of the interfaces that employ them.

The layers of volatility support independent changes in interface, process and domain components. Domain components supporting financial accounts are used in different transaction processes. New transaction types are added and existing transactions changed without changing the domain components. The same holds for the interfaces. The transaction processes are used by bank-employees through a Windows interface and by the customers through an ATM. New interfaces are easily added, for instance an Internet interface for the customer supporting home banking.

8.6.4 Applications in the Component Architecture

The Component Architecture leads to a new meaning of the concept application. In the more conventional approach an application is a program (thus a piece of software) that the user supports in the execution of a task.

In the Component Architecture an application is an assembly of application specific components and of business and system utility components and frameworks.

Moreover different applications share components and frameworks in the business and system utility layer. Especially the ICT functionality offered by components and frameworks in the system utility layer is shared by many applications.

An application exists as a cluster consisting of the design models of its components and frameworks and the implementations for different types of software/hardware platforms and the executables as installed at different locations.

8.7 The Impact of CBD

CBD will have a major impact on both the application delivery and the adaptability of the business.

8.7.1 Application Delivery with CBD

CBD will totally change the way in which developers deliver an application. The above figure depicts the activities of the developers when delivering applications for a business-domain in the company. The activities are projected on the layers of generality in the Component Architecture.

• Activity 1: developing the system utility components and frameworks
  This activity is performed by ICT specialists who design and build the system utility frameworks, which support the business components and frameworks. The implementation of the system utility frameworks is based on different types of technology infrastructure. The system utility frameworks are produced as software.
  By the way: the ICT specialists also build the software for the business components and frameworks when it is not possible to generate them from specification.
• Activity 2: developing business components and frameworks
  This activity is the task of business component developers who design the business components and the supporting business frameworks. The components and frameworks are specified in the unified modelling language UML.
• Activity 3: Design of the applications for a business domain
  This activity is the task of application architects who design the applications, which support a certain business domain within the company. In our example of a virtual bank in chapter 7, business domains are the administration of a financial product in the back-office, the distribution channel manager in the middle-office or the Internet distribution channel. A business architect has made the business design consisting of a design of the business organisation, the business processes, business functions and business information. The application architect uses this business design of the business domain as starting point for the application design. Application architects analyse the requirements and model the applications by means of prebuilt components and frameworks. The application is specified in the modelling language UML. The design also provides instructions for the development process, for example specialisation of existing components and frameworks and development of new components and frameworks.
  The application architect has the supervision of the application development.
• Activity 4: developing the applications
  This activity is the task of application developers who realise the design of the architects. The developers purchase the necessary system utility and business components and frameworks from the developers, who perform activities 1 and 2. They develop the necessary application specific components. The applications developers assemble the application from the components and frameworks. They generate the software for the technical platform with the use of code generators and transformation rules. The developers perform the acceptance testing in co-operation with the end-users in the company.

The organisation of the application development follows the separation of the business domain and ICT domain of the Component Architecture. The design of the system utility components and frameworks (Activity 1) is based on the available support of information and communication technology. The design and the development of the application and the business components and frameworks in the application and business layer (activities 2,3 and 4) are based on the demands of the business. The business domain is technology independent and system utility domain is business independent.

The products of the business domain are models. The product of the system utility domain is software. The separation makes it possible to match business demands and technology support.

The organisation also makes a separation between the development of components and frameworks (activities 1 and 2) and the usage in a specific application (activities 3 and 4). This makes it possible to develop both system utility and business components and frameworks, which can be used for the development of specific applications in different projects. The component developers specifically design the components and frameworks for reuse in different situations.

The organisation also supports the division of the development in front office and back-office activities. The activities 3 (architect) and 4 (application developers) are front-office activities that are executed in co-operation with the customer. Architects and developers need communication with the customer for designing, developing and testing the applications. Developers in the back-office of Cap Gemini or other independent suppliers perform the activities 1 and 2 and deliver the components and frameworks to the architects and developers in activities 3 and 4.

8.7.2 Reduction of Development Time

We think that CBD in combination with a business-oriented design will strongly reduce the development time of applications.

An application, which now takes 9 months to develop, will be developed in 9 weeks or even 9 days. This reduction of the development time is possible in the following steps:

• The use of system utility frameworks that support the business applications. This results in business applications with only business logic and no technical logic. The executable instructions for a business application consist roughly of 20% of business logic and of 80% of technical logic. With the use of CBD the developer must still specify the 20% of business logic, but the 80% of technical logic is reused from system utility frameworks.
• The software of business components and frameworks is generated from a specification in UML. Programming of the software coding is no longer needed.
• Carefully design the business components and frameworks for reuse. Take the business functions and business information of a specific business domain for instance financial products as a base for the design and specification. The developers design a general framework for a financial product that defines all functionality that can be reused in the development of a specific financial product. The next time the bank wants to introduce a new financial product the developers only must specialise and extend the general framework. The result is that the developers must define some 20% of the functionality as new functionality. The rest of the functionality was already pre-defined in the framework.
  

8.7.3 Reuse Redefined

CBD redefines the reuse of software. Reuse is not new. But most forms of reuse are at the level of individual parts like screws and tyres in our car metaphor.

The new features of CBD are:

• Use of frameworks
  The older methods do not have frameworks, which contain the general business and system utility logic of the applications. Frameworks also make the assembling of applications out of components easier. Without frameworks there is nothing that holds the components in the application logically and technically together. Frameworks make it possible to define assemblies of components with more complex business and ICT functionality. Our approach results in flexible construction of components at the level of sub-assemblies such as the motor and the car-body in the car metaphor.
• Different hardware and software environments
  Many methods for reuse are based on a specific hardware/software platform, development tools and programming language. This makes reuse in other technical environments impossible.
  We facilitate reuse on different platforms in two complementary ways:
  • System utility frameworks act as a bridge between the business components/frameworks and the supporting software and hardware infrastructure. A system utility framework adds platform-specific system utility logic to the business components and frameworks that reuse it.
  • We specify business specific components and frameworks in a modelling language like UML and generate from this specification the software components and frameworks for the different technical environments.
    
    

8.7.4 Adaptability to Business and Technology Change

CBD results in applications that are easily adaptable to changing business requirements. Business managers nowadays are confronted with rapid change. Competition forces them to renew their products and services or to lower the cost of production. Companies are deciding which activities are core to their business and which activities are candidates for outsourcing. Mergers are bringing companies together and forcing them to reorganise their operations.

In such an environment, current tailor-made applications and monolithic software packages are more inhibitors than enablers of change.

Our approach makes applications adaptable to business change in the following ways:

• The component/framework approach makes it easy to change existing applications by changing the assembly of components and frameworks and building new applications quickly from available components and frameworks.
• In chapter 7 we showed how the application architecture prescribes a distributed design of applications, which is derived from the network organisation of the business. Changes in the business are easily translated to the necessary changes in the applications. In the case of outsourcing of business activities it is easy to determine which applications are part of the outsourcing.
• CBD uses system utility frameworks that add systems management functionality for testing, deployment, maintenance and operation to applications.
• CBD also supports the adaptability of applications to changes in technology. The ICT specialists develop new or adapted system utility frameworks that make the new technology available for the applications. For the business components and frameworks that reuse the plug-points of the system utility frameworks two changes are possible:
  • The frameworks still offer the same functionality through the same plug-point but the internal processing is improved. For instance the frameworks show a better performance. The performance of existing applications that use the frameworks immediately improves.
  • The frameworks offer new or improved functionality through new plug-points. The company can take advantage of this new functionality by redeveloping existing business components and business frameworks and let them reuse the new plug-points. These changes can be accomplished gradually. The company can also develop new businesses and thus new applications based on the new system utility functionality.

The result of our application architecture and CBD is that applications systems change by adaptation and not by replacement.

8.7.5 Mastering the Complexity

CBD also helps an organisation to master the growing complexity of the application systems. Our example of a virtual bank in chapter 7 shows a far more complex system than current stand-alone back-office transaction systems. This complexity will grow exponentially when enterprises become virtual agile Web Enterprises of companies who are working together in ever changing patterns of co-operation in the delivery of products and services to the customers.

CBD helps an organisation to master the complexity in the following way:

• Hiding complexity
  A developer, who uses a component or framework in an application, must only know which services or functionality the component or framework delivers. The components and frameworks hide their internal logic for the developer. In doing so they also hide a lot of complexity. In our car metaphor, the tyre and the rim have a simple standardised interface. This gives tyre manufacturers the room for developing their tyres. In the last twenty years the tyre has become a very complex and high-tech product. With the use of computers the manufacturer has developed a lot of new knowledge about the construction of tyres. The same development has taken place in the construction of motors, automatic gearboxes and all other car components. So the whole car is now a very complex product but the basic construction from components and frameworks did not change very much. All new knowledge and growing complexity are hidden in the components.
  CBD will help to do the same with application construction. A standard construction based on components and frameworks with standardised interfaces makes it possible to develop more complex applications with a higher service level without changing the whole application. We only need to change the components and frameworks and hide all complexity in these components and frameworks. Good examples of such components with growing complexity and service level are frameworks in the system utility layer like transaction managers or persistency managers.
• Self-management
  A second method to master complexity is self-management of applications. The motor of a car has an electronic motor management system that controls the combustion process and the catalyst. Without this self-management it is impossible to fulfil the current environmental requirements for cars. The management system also has an interface to the maintenance diagnostics system in the garage.
  Self-management is extremely useful for applications and not only for built-in control of business processes, which is realised by agents. During the application life cycle there are a lot of activities and functions that are better realised with self-management. Deployment of applications is facilitated when components and frameworks have built-in functions for the control and execution of their own installation and version control. The result is "plug and play" software components. Operation is facilitated when components and frameworks have built-in functions for their testing, monitoring and remote operation.
  One of the important results of self-management is the growing manageability of the application system. Monitoring, testing and auditing of the processes is primarily executed by the applications themselves. So, errors and disruptions are detected earlier and can more easily be resolved.

CBD solves an important contradiction in the feasibility of applications:

How can I build an application that is both complex and adaptable while still being reliable?

In the history of car we see a growing complexity of the construction, a growing adaptability of the product to the wishes of customers and a growing reliability of the car in use.

CBD will help us to cope with the same contradiction. We can build ever more complex applications that are easily adaptable to both business and technological changes and yet are still reliable in operation and do not threaten the continuity of the business.