Cohesive Architectures

From Geostandards

Jump to: navigation, search


Contents

Enterprise architecture

Enterprise architecture is the field that deals with the cohesive designing of the organisation in all its aspects.

Enterprise architecture offers a framework for organisations that want to change summarised, in headlines, in a cohesive and consistent description of the desired situation. This description offers hard and soft boundaries that try to restrict the space available for design at the lower levels in such a way, that the changes are made in accordance with the goals of the whole organisation. Enterprise Architecture takes the lead and offers concrete tools for the testing of changes. Enterprise architecture is, therefore, often regarded as an important steering instrument.



Architectural frameworks

Part of the job of an architect is to use architectural frameworks. These are structured collections of issues that may be dealt with during the creation of an architectural design. Frameworks predominantly have two dimensions that are sometimes completed with an extra dimension, to include, for example, themes such as the safety of information.

An architectural framework might be a useful tool that supports the architect when doing his or her job, especially when describing and communicating ideas about the architecture. The main goal of an architectural framework is to offer a way of organising and presenting architectural descriptions and visualisations.


Architectural frameworks, among other things, could help to:

  • guarantee the completeness of an architectural description;
  • make explicit the cohesion in a design;
  • discover the ‘blind spots’ in the design;
  • make architectural descriptions more transferable.


There are a lot of architectural frameworks in circulation. Which framework is the most suitable varies from case to case. There are, for example, frameworks that pay specific attention to various parts of the architecture and the building bricks of an organisation or the stakeholders (i.e. planner, owner, architect, contractor, sub-contractor). Other frameworks chose to include the dimension “time” to make the dynamic of the architecture visible (i.e. yesterday, today, tomorrow).

Using a framework has disadvantages too such as:

  • concerns, issues and relationships that are not seen;
  • interests are lost sight of;
  • over description;
  • over simplification;
  • description too early / too late;
  • giving visualisations a lower priority than descriptions.

 
















The IAF (Integrated Architecture Framework) is used as an example.


IAF consists of the following four layers:

  • Business architecture;
  • Information architecture;
  • Application architecture;
  • Technical (infrastructure) architecture.

They are described in order below.



Business architecture

The vision, mission and strategy of the National Geo-Information Infrastructure (NGII) is important here and above all GIDEON. Influential NGII law and policy are mentioned in so far as they are important to the geo-information infrastructures project. Political requirements / wishes that play a part in the framework of the NGII (GIDEON) are recorded based on their influence and the consequences they have for the geo-information in the infrastructures project. Information policy is mentioned as well, such as the free, or under conditions, distribution of government information play important role in geo-information infrastructure projects. Also record the strategic, business principals.



Concept (what?)




Organisations and processes (how?)

For the creation of the NGII it is important to know about the playing field of organisations which play a part in the geo-information infrastructures project. As well as the organisations that the business collaborates with, the organisation of the NGII-playing field is also important.


Processes





Information architecture

The architectural impact that the project has on the field of the information, or geo-information is recorded below.

Marking out

Data in the NGII are exchanged based on standardised information models. A basic model and various sector models are available for NEN3610. For the data from the GII project, the elements (classes, relationships, attributes) are mapped to the information (application) models (mostly a sector model). When there is no sector model available, it is advisable to consider developing one.

Policy, guidelines, standards

Principle 1: The data of the NGII is, by preference, modelled by /making use of/referring to information models.
Principle 2: All data of the national GII are provided with metadata. Metadata of the information 

(geographic datasets and dataset series) will be published on the national geo register.

Consequence: In the project plan, GII projects have to adopt the position that data will not only be published

via their own geo portal or geo-application, but will also be available via the national geo register.

Application architecture

Marking out

The application landscape of the NGII consist of the various GII portals and GII applications that are available on the Internet. We mention:

  1. Atlas leefomgeving (http://www.atlasleefomgeving.nl)
  2. RO online (http://www.ruimtelijkeplannen.nl)
  3. DINO (http://www.dinoloket.nl)
  4. Bodemdata.nl (http://www.bodemdata.nl)
  5. Nederlandse Oil and Gas portal (http://www.nlog.nl/nl/home/NLOGPortal.html)
  6. DUIN portaal
  7. NODCi
  8. BIELLS
  9. New map of the Netherlands (http://www.kaart.nieuwekaart.nl)
  10. ...

It is important for a Project Start Architecture (PSA) to mention the interfaces between the applications. Interfaces within the NGII are geographic web services which can be found via geo portals or which are publicly available because the applications were offered on the internet. In general, public web services that are published via geo portals and/or used in geo-applications are shown via the national search service for geo-information www.nationaalgeoregister.nl (NGR). This means that all national web services can be consulted via the NGR.

Policy, guidelines, standards

Principle 3: All geo applications and their underlying public web services will be published in the national geo register at www.nationaalgeoregister.nl

Consequence: In the project plan, GII projects have to adopt the position that public web services will not only be published via their own geo portal or geo-application, but will also be available via the national geo register.

Principle 4: All public geographic web services are provided with standards that conform to the framework standards of the Dutch GII.

Consequence: GII projects include in their project plan which web services have to support standards in order to guarantee GII interoperability.


Technical (infrastructure) architecture

System








Data storage








Network








previous Cohesive Architectures next
Personal tools