26.12.2012 Views

Australian Government Architecture Reference Models Version 3.0

Australian Government Architecture Reference Models Version 3.0

Australian Government Architecture Reference Models Version 3.0

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

architect should plan to provide these services for the transactional, authoring and document repository<br />

quadrants.<br />

� Notification Services: automatically alerts another service or an end user of changes to the content of a<br />

repository in accordance with a predetermined policy or profile. The architect should plan to provide<br />

these services for the transactional, authoring and document repository quadrants.<br />

7.8.2 Guidance<br />

As stated in the Overview, once the Data Context and the Data Description standardisation areas for a COI have<br />

been defined, the COI should then plan and implement common capabilities to enable information to be<br />

accessed and exchanged.<br />

Enterprise architects and data architects supporting COIs may use the following table as a guide to plan<br />

implementation of data exchange and access services for each data asset under management within the COI.<br />

Data Sharing Service Requirements Matrix Table<br />

Supplier Service Requirement Consumer<br />

Data Asset Identifier (see<br />

abstract model below)<br />

Data Exchange Service Type<br />

(e.g. Extract, Transform, Load)<br />

―(populate as needed) ― ―<br />

Data Asset Identifier Access Service Type (e.g.<br />

Context Awareness)<br />

―(populate as needed) ― ―<br />

Data Asset Identifier<br />

Access Services typically support many<br />

consumers. Generally, there is no need<br />

to populate these cells.<br />

Once the architect has populated this matrix, he or she has a clear understanding of the types of data access<br />

and exchange services that they should provide to support a COI’s information sharing requirements. Once these<br />

requirements are captured, the architect may use the Data Sharing section of the DRM abstract model to fully<br />

document the data access and the exchange services required to support the COI.<br />

7.8.3 Data Sharing Section of the DRM Abstract Model<br />

The Data Sharing section of the DRM abstract model covers two primary aspects of data sharing:<br />

� Data Exchange: fixed, recurring transactions between parties, such as the regular exchange of<br />

environmental testing data among federal, state and local entities. These exchanges, as described<br />

above, are implemented with data exchange services.<br />

� Data Access: requests for data services, such as a query of a Data Asset 35. These requests, as<br />

described above, are supported by Data Access Services.<br />

The Data Sharing standardisation area is supported by the Data Description and Data Context standardisation<br />

areas in the following ways:<br />

� Data Description: uniform definition of Exchange Packages and Query Points supports the capability to<br />

effectively share them within and between COIs.<br />

� Data Context: categorisation of Exchange Packages and Query Points supports their discovery and<br />

their subsequent use in data access and data exchange.<br />

35 The term ‘data asset’ is synonymous with ‘data source’. It is described within the Data Context section.<br />

<strong>Australian</strong> <strong>Government</strong> <strong>Architecture</strong> <strong>Reference</strong> <strong>Models</strong> <strong>Version</strong> <strong>3.0</strong><br />

225

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!