In typical digital transformation scenarios, there may be existing external applications and data repositories that have to be integrated with Govstack initially, to provide a gradual transition from disparate monolithic implementations to the reusable building-block based approach of Govstack architecture. Several third party software components and application providers may also be interested to achieve compatibility with Govstack specifications and demonstrate integration of their components in Govstack.

Information mediator (IM) building block provides interoperability between building blocks to secure access to services and data between Govstack compliant building blocks wthout dwelling into the inside of the information payload being exchanged between a service provider and consumer (building block/application). However, for meaningful interoperability between a service provider and consumer, the protocols and formats for data exchange also have to compatible. In this context an Adapter facilitates transformation of data formats and protocols in between building blocks. While this idea seems simple, in practical, large scale implementations integrating GovStack with several heterogeneous applications and data repositories become very combursome to define, implement and maintain dedicated adaptations.

This drives the need to define the Adaptor building Block (ABB) to enable definition and stacking of reconfigurable protocol and data transformation rules for different pairs of incompatible apps/BBs. The ABB can instantiate transformation pathways between data paths of app/BBs so as to establish meaningful data exchange in that sense. If there are custom built third party adapters available for specific cases (e.g. HL7 adapters) then the adapter BB may may access such an adapters and abstract away the complexity of such interactions from the building blocks in getting the transformation done.

Terminology