The target audience
The cover of NORA versions 1.0 and 2.0 describes the document as being “for and by architects.” Whereas NORA 3.0 was written “for the directors of organisations that perform government tasks, but in particular for the portfolio holder for information policy.”
This shift in target audience fundamentally changed NORA, meaning it was no longer a document that contained “principles, models, and standards for the design and establishment of an electronic government,” as described in the preface of version 1.0.
Principles and requirements
Before we get into too much detail about what these changes mean, it’s important to make the distinction between ‘design requirements’ and ‘construction principles’ – two terms used throughout the documents.
In this context, ‘requirements’ are the demands that users place on a system, whereas ‘principles’ dictate the construction of the solution designed to meet those requirements.
Or, in the words of Emeritus professor Jan Dietz: “There is a fundamental distinction between the function of a system and its construction.”
The current version of NORA also loosely adopts this definition, stating that “Basic principles (BPs) describe the quality of government services from the perspective of the wishes of society, the citizens, and businesses.”
It goes on to say that “The derived principles give more concrete substance to the basic principles. They can be regarded as a checklist of quality characteristics of government services and provide handles for the operational level by their elaboration in concrete implications.”
The definition of basic principles therefore corresponds to the idea of requirements. However, the derived principles cannot generally be seen as construction principles – namely how the requirement should be met. Let me illustrate this with an example.
Derived Principle 26: "The customer has access to his own information and the use of it." This principle describes a requirement; not how this requirement should be realised within the government.
More generally, it can be stated that the derived principles tend to lean towards a specialisation of the user requirements as expressed in the basic principles.
Unfortunately, the current version of NORA lacks these construction principles. This may also explain the end of the relationship with over 200 standards in the earlier versions of NORA, which were an extension of these construction principles.
Again, for illustration: in the nine-level model there is a reference to six derived principles within the “Messages and Data” field. It is surprising to note that a principle for “messages” is missing, as messages are an indispensable link with modern information management.
As a result, no relationship is made to, for example, the Common Message Agreement, or standards such as StUF, SuqiML, ebMS, Digikoppeling, or NEN3610.
Demarcation and scope
The current version of NORA seems to be primarily written with the buyer of services in mind. The implicit assumption seems to be that citizens, and possibly also businesses, are the most important recipients of services. This is essentially a B2C (Business-to-Consumer) model.
The result is that the B2B (Business-to-Business) aspects of Nora are given short shrift.
Originally, NORA also had a focus on enabling chain collaboration. Versions 1.0 and 2.0 had the subtitle “Cohesion and cooperation within electric government.”
The emphasis in these editions is on improving continuous, unambiguous service provision to citizens, businesses, and local authorities. And the key takeaway is that the more unambiguous agreements that are made about chain architecture, the better the government can function as a single entity.
It’s worth noting that NORA online contains an extraordinary amount of information, sourced from multiple versions of the initial documents that were judged to be “too thick” for publication.
Despite this, the scope is limited. It still requires updates and additions to include the recent developments of GEMMA, Common Ground, the Dutch Digitalisation Strategy, and the Development of Digital Government manifesto.
Parallel activities, such as the Federatief Overleg, which deals with Common Agreements on Messaging, and the Banaan working group, in which architects from the Manifesto Group work on a government architecture, also indicate that NORA has too stringent a demarcation.
Ultimately, the original idea behind NORA – coherence and cooperation within electronic government – is evidently not sufficiently realised.
A changing landscape
There are also signs that NORA may be falling behind the times in terms of the subjects it covers.
It’s interesting to look at the recent booklet, The Future of Digitisation in the Netherlands, in which 35 government administrators and CIOs are asked to talk about the projects they are working on and subjects they are involved in. A small selection of subjects mentioned includes:
- Data-driven operations
- Data science
- Data analytics
- Self-learning systems
- Business rules
- Process mining
- Robotic process automation
- Natural language processing
- Edge computing
- Digital twins
- VR and AR
- Multi-hybrid cloud
Using NORA’s online search function yields almost no hits for these terms. This raises the question of whether NORA is still connected to the community of managers who are in the process of digitising the government.
Despite the great interest in NORA, I think that some important changes must be made for architects to provide managers, administrators and CIOs with the right advice for their organisations.
Here are four key improvements that can be made.
1. Remember the target audience
Let NORA return to being a reference piece or guide for enterprise and information architects, and ensure the nature of the principles and models are suited to these roles.
The strong desire to include managers and administrators would be better met with a document specifically tailored to this demographic – something short and accessible that appropriately supports decision making.
2. Establish construction principles and link with standards
High-level requirements are only the beginning of an architect’s work. After that, the real work starts: establishing the construction of what needs to be made.
This includes specifying how citizens and companies can make use of government services, making agreements about communication protocols and message composition, establishing guidelines for data networks and information security, and so on and so forth.
In this way, we can develop the building blocks of modern government.
3. Broaden the scope
NORA and its subsidiaries should provide a coherent design for the Dutch public sector. The government consists of many relatively independent organisations, and it’s down to architects to bring a level of coherence to this.
This coherence not only concerns services to citizens and businesses, however. To be able to realise requirements such as “no wrong door” and “one-stop shopping,” it is important that NORA contains agreements on chain cooperation at the level of service provision, business process links, information exchange and infrastructure.
By entering into smart coalitions with developments such as the Commonwealth Government Architecture, Common Ground and Banana etc., NORA can become the overarching and integrating link between all these separate initiatives. An umbrella that preferably also connects and takes influence from the European Interoperability Framework.
4. Ensure alignment with current developments
How do the latest developments such as data analytics, AI and digital twins fit into government architecture? It’s important to achieve synergy by making agreements on these subjects within the government. Directors, managers, CIOs and CDOs will be grateful to architects for good support in these areas.
If you’re currently pursuing new digital initiatives, or looking to bring new capabilities to your organisation and would like some advice, get in touch to talk to one of our experts.