Message-ID: <531829044.12696.1411344831495.JavaMail.confluence@ece-vmapps> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_12695_515468606.1411344831495" ------=_Part_12695_515468606.1411344831495 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Statistics Norway's technical solutions shall be built mainly upon the p= rinciples of service-oriented architecture. Guidelines on this are presente= d in Norway's eGovernment plan. All solutions for external us= ers and most solutions for internal users shall:
=E2=80=A2 Have support for open standards.
=E2=80=A2 Be platform independent.
=E2=80=A2 Be component based.
=E2=80=A2 Have support for the packing in of data and functions in the f= orm of services (web services).
These are central principals in service-oriented architecture. By applyi= ng these principles, applications and services can reuse existing functiona= lity/components completely independent of the system they were developed in= . In addition, by use of this technique, we can extend the lifetime of olde= r applications, which have important functionality we wish to expose, just = by creating a service layer on top of these. This increases the possibiliti= es for collaboration between old and new applications in a completely new w= ay, which gives benefits in the form of shorter development time, increased= reuse and more consistent systems. This also enables us to replace systems= behind the scenes, because communication with these is not directly expose= d to the users.
For more information see: h= ttp://www.ssb.no/english/about_ssb/strategy/it_strategy.pdf
System architects are introduced for each of the following areas in the = top-level information architecture: data collection, metadata and dissemina= tion. The mandate for this role supports the system architect's responsibil= ity to ensure that IT development projects are in line with the IT strategy= .
Solution architects are appointed for each new development project to en= sure that the systems development is in accordance with the current IT-stra= tegy, architecture principles,recommended tools and practices.
All our master metadata systems have Oracle databases. Links are mostly = hard-links between these databases. Our web applications obtain metadata fr= om our service library for metadata systems.
Our classifications system is an implementation of Neuchâtel Termi= nology Model Part 1 Classifications v2.0 with the addition of an attribute = on the Correspondence Item for Item Change from v2.1.
We are contributing to a task force looking at a revision of the Neuch&a= circ;tel Terminology Model Part 1 Classifications v2.1
Our variables system is a partial implementation of Neuchâtel Term= inology Model Part 2 Variables. The extent to which we follow ISO/IEC 11179= , is best described by the figure in the attachment to this chapter wh= ere the number of instances of the objects per 2012 are given in the bracke= ts.The figure in the attachments illustrates that there is little re-use of= data elements or value domains in the current archive. This is a situation= that we hope to address in the coming years.
We are considering using DDI in connection with micro-data for researche= rs.
We have used definitions of key metadata concepts from SDMX MCV where po= ssible.
We have contributed to the development of GSIM (Generic Statistical Info= rmation Model) v1.0.
We are contributing to a task force looking at the flow of GSIM v1.0 inf= ormation objects in GSBPM v4.0.
Metadata have valid to, valid from and last updated.
Program code for web-services is checked in and out of subversion.
Some data models and XML-schema can be made available on request.= p>