What is Testable Architecture?

The SAVARA project has been established to build tools for Enterprise and Solution Architects. The unique aspect of this project is that it is based on support for a new methodology. called "Testable Architecture", developed by Red Hat and Cognizant Technology Solutions. For a presentation on the background behind Savara, and information on how the methodology is being used, see Savara - Formally Verifying SOA Designs Against Requirements.

This methodology aims to ensure that any artifacts defined during the development lifecycle can be validated against other artifacts in preceding and subsequent phases. This ensures that the final delivered system is guaranteed to meet the original business requirements. Through runtime governance, it is also possible to ensure that the running system continues to meet those requirements.

As a system evolves, through subsequent enhancements to the business requirements, having such a precise understanding of the system, from requirements, through design, implementation and deployment, enables more sophisticated change management techniques to be considered.

The following diagram shows the highlevel aspects of the "Testable Architecture".

Scenarios

Scenarios represent 'use cases', defined in conjunction with business users, to represent specific outcomes through the business process they are wanting to define.

The scenarios are represented in the form of UML sequence diagrams, with example messages attached. This enables the business analyst to gain an understanding of the principle participants (people, systems, databases,, etc) that involved in the process, and the nature of the information being exchanged between them.

Global Model

A Global Model is a description of an 'end to end' business process from a neutral perspective. This means that the description of the process does not consider individual sends and receives, based on the components (i.e. services) involved, but instead just considers the process from the point of view of interactions that occur between distributed components (i.e. services).

This enables the architect to define the overall system, without having to consider what types of technology may be required for the individual components.

There are currently two standards that can be used to define such a globla model, WS-CDL from W3C and BPMN 2.0 (currently going through its finalization phase).

As shown in the diagram, the Global Model can potentially be derived from a set of Scenarios. It will not always be possible to fully automate this step, but with user guidance it should be possible to speed up definition of the Global Model.

The diagram also shows that the Global Model can be checked for conformance against the Scenarios. This can be achieved through simulation.

Local Model

As previously mentioned, the Global Model represents the component neutral view of the 'end to end' business process. Therefore the Local Model represents the component specific view.

This description represents the observable behaviour associated with a particular component, describing the individual message sends and receives that occur, to enable it to interact with other components.

The Local Model only defines observable bebaviour, and is intended to define the behavioural contract for the component (i.e. service). It does not define any internal (or non-observable) implementation details. It is intended to be a transient description that can be used to ensure conformance against a Global Model (as shown in the diagram above), and can be generated using a technique called "Projection" from the Global Model.

Although in general this Local Model representation does not need to be persisted, it can be used in conjunction with a Registry/Repository to enable services to be located based on behaviour. In this case, the Local Model will be associated with the service within the Registry/Repository.

Service Designs

The Service Design phase represents the elaboration of the Local Model representation with implementation details (i.e. the non-observable aspects).

Depending upon the nature of the 'service', this could be using BPMN2 to define the details of the service, or if the service represents a database, this could be defining the database schema.

As the design is evolving, it will be conformance checked against the Local Model.

Service Implementation and Testing

Once a service has been designed, the next step is to get it implemented. However, in general it can be difficult to ensure that a service implementation meets it design and more importantly its responsibilities in terms of the overall architecture and business requirements.

With "Testable Architecture" it will be possible to use previous artifacts to help ensure that the service implementation meets these objectives. When certain implementation languages are used, that enable the communication structure to be inferred, it will be possible to statically conformance check the implementation against the design. Where this is not possible, or in addition to, it will be possible to use the Scenarios defining the business requirements as service unit tests.

Additional, once the overall system is deployed into a test or production environment, it will be possible continously monitor the interactions to ensure they continue to conform to the architectural specification (Global Model).

Runtime

The runtime environment is continously monitored to ensure that the business processes are executing correctly in accordance with the business requirements and architecture.

This mechanism can ensure that business processes execute as expected, but it also provides a valuable source of activity monitoring that can be analysed by the business to understand how their processes are performing and can improve (i.e. BAM).