Goals
The ADP Reference Architecture is an important link in the realisation of applications and the stimulation of reuse. The reference architecture supports easy maintenance of produced software, because it guarantees traceability of requirements and design to code.
In agile projects, software architecture is not necessarily an item on the agenda. We feel however that software architecture is a key enabler to developing high quality, maintainable code. The Accelerated Delivery Platform therefore offers three similar reference architectures, that are loosely described below, that facilitate a basic, but sound software architecture in three different scenarios:
- Database-oriented. A plain database-oriented multi-tier architecture.
- Service-consuming. A multi-tier software architecture for clients that consume (web) services of any kind, but still have their own business layers.
- Service-providing. An architecture to develop services according to the same architectural principles and best practices as the previous two architecture.
All of these three architectures are focused on implementing smart use cases.
The steps in the Smart process that appear in the
Scope stage, deal with absorbing these architectures, and just defining the delta that differentiates your particular project from the standard architectures.
Sander HoogendoornADP Core Team
Overview
Because “reinventing the wheel” costs unnecessary time and money, Capgemini created the ADP Reference Architecture, one of the accelerators included in the Accelerated Delivery Platform.
The ADP Reference Architecture is a layered architecture. The use of layers is a good way to distinguish between the different responsibilities of the architecture, which accounts for a clear software architecture. The ADP Reference Architecture is created because of the following main reasons:
- The reference architecture presents a clear vision on how to develop software and introduces standardization
- The reference architecture assures the quality of software being built under the architecture because the architecture contains fully tested and proven components
- The reference architecture stimulates reuse over projects.
- The reference architecture diminishes architectural work in projects; only the deviation to the reference architecture needs to be explored.
Layers
The following figure shows an overview of the ADP Reference Architecture. The reference architecture has four layers which all have different responsibilities. Besides these four layers there is also a layer called the outside world. The layers and their functionality are further explained in the paragraphs below.
Layered Architecture
Presentation layer
The presentation layer presents information to the customer in a Windows, web or even a mobile device application. Preferably, the presentation layer is a thin client which contains no logic, such as business logic or process logic, from other layers.
Process layer
The process layer is responsible for executing the use cases in the application. Every use case in the model is represented as a task, and the process layer manages these tasks. The process layer separates these processes from the rest of the application, making them flexible. In practice the process layer and the presentation layer are closely related, so sometimes it is inevitable that some of the process logic is enclosed by the presentation layer.
Use cases
The problem with most development techniques working with use cases is that the use cases often have a different level of granularity. The Accelerated Delivery Platform uses smart use cases, which are all of almost the same low granularity.
During a ADP project a use case diagram is made for every elementary business process. In most cases this diagram consists of a single user goal level use case assisted by sub-function level use cases. Use case diagrams are used to leverage the complexity of functional requirements.
Business layer
The Business layer is the most important layer in the reference architecture. This layer contains al the business logic which is offered to the upper layers. The business classes are located in the business layer. The business classes are derived from the domain model of the application. Every class in the domain model is represented by a business class in the business layer.
Data / Services layer
The Data / Services layer isolates the connections with databases, services, packages and other applications from the upper layers. This layer provides the internal status of the business objects in the business layer. For every Business class in the Business Layer there is a Table or Service class in the Data / Services layer.
Outside World
The Outside World is everything in the surroundings of the application that is somehow connected with or has influence on the application. This “layer” represents the interfacing between the application and the outside world. Examples of components of the outside world are Siebel, CRM, SAP, Web Services, Databases, etc.
Blends
The ADP reference architecture can be implemented in a couple of blends which are described below.
Database
The Database variation is the standard reference architecture of the Accelerated Delivery Platform. This architecture represents a standard ADP application which consists of a web based, Windows or mobile Microsoft .Net application, supported by a SQL server.
Standard Reference Architecture
Service Consumer
Service Oriented Architectures are a growing trend. The Accelerated Delivery Platform fully supports service oriented architectures. The figure below shows a reference architecture which uses services as data sources.
Service Consumer
the outside worlds in the figure shows, the application can access web services and use it as data source. The application can also easily access a bus structure which gets data from other sources which could be web services, applications, etc.
The only layer that has been modified in order to create this services client architecture is the Data / Services layer. Instead of Table classes this layer now contains Service classes in order to communicate with the service. Because of the layered structure of the architecture the other layers continue to function as if they were still using data directly from a database server. This example architecture contains multiple tiers; the application, the web service and the application delivering the web service.
Service Provider
The previous example showed a reference architecture which uses a service as the data source. What if we don’t want to create an application which uses a service, but an application which itself functions as a service. This is also possible within the Accelerated Delivery Platform. An example of a service architecture could look like this:
Service Provider
Looking at this figure we can see that the process and business layer are still identical to the standard reference architecture. In order to create a service the only layer that has to be changed is the presentation layer, instead of creating a form to represent the data a service interface has to be created. Again we can identify multiple tiers in this example architecture
The created service architecture can access data from a database server, but also from another data source. The above figure shows the different possible data sources in the Outside world en Data / Services layer. Because of the layered architecture all kinds of variations are possible.
The last figure gives a visual representation of some of the possibilities of applications in the Accelerated Delivery Platform. This picture shows a clear overview of how a service oriented architecture could be realised with the Acclerated Delivery Platform. The basis for every application is still the same; all these applications have more commonalities than differences.
