Article

Construction principles for the information professional

3 min read
November 27, 2023
Construction principles for the information professional

In its simplest form, this gives rise to a matrix with four elements. One element represents the architect of the organization as an information-processing entity, or the information professional architect. Additionally, there is the architect responsible for the means of information processing, known as the computer science architect. Regarding the constructor, the same distinction applies: an information professional constructor and a computer science constructor.

This classification remains relevant today when considering all the designations of IT specialists. It helps to better identify the quadrant in which someone operates based on their role and discipline. Moreover, individuals may be active in multiple quadrants as long as they remain aware of their position.

For the execution of their profession, they all apply principles.

The information professional architect determines which information principles are applicable to the design of the information-processing organization, while the constructor applies them as norms during construction and implementation. Construction principles are more universal because each design materializes in the tangible reality through construction. Something either works or it doesn’t—there’s no in-between. This makes it clear that a construction principle cannot defy the laws of nature. An inadequate structure collapses.

The interaction between architecture and construction lies in the advancement of technology. Different technologies enable different constructions. Consequently, the architect gains the ability and limitation of making alternative choices.

In a series of short columns, I aim to address the still-valid information construction principles that guarantee better information structures. Over the past decades, the emphasis has often been placed on the possibilities offered by advancing technology for these structures. The information science aspect has been somewhat overlooked, resulting in occasionally unstable or poorly maintainable “information structures.”

The following information principles will be covered:

  1. Meaningless identity designation, read here.
  2. Decoupling points for complexity reduction and flexibility, maximizing independence of components, read here.
  3. Language consistency, read here.
  4. Clear distribution of responsibilities and functional separation for administration, read here.
  5. Delegating decision-making authority as low as possible, read here.
  6. Detaching authorization from identification/authentication, read here.
  7. Single registration of master data, read here.
  8. Separating data and metadata in storage and processing, read here.
  9. Applying standard patterns without deviations, read here.
  10. Separating application function from data storage, read here.
  11. Device-independent development, read here.
  12. Choose a Storage Structure, read here.
  13. No hidden interfaces, read here.

References:

[1] EAN 9789026721557 (*this book is only available in Dutch). He still makes the valid distinction between the study of information technology (computer science) and the study of information processing.

Rutger Gooszen
Rutger Gooszen

Principal Architect

Rutger has over 15 years of experience as a Lead Architect/Business Architect in complex chains and in coaching a team of architects to develop and…
Discover more

Related insights

Construction principles for the IT architect (11) Device-independent development
Article
2 years ago | 5 min read
Construction principles for the IT architect (11) Device-independent development

In this series of blogs, I will reflect on the still valid information science construction principles that guarantee better "information structures". This 11th blog in the series continues with the second informatics principle (see my starting blog for the distinction ). Why and when to develop device independently? It's always so nice in the architecture principles at company level or in a policy document "Our employees can work independently of time, place and device". But the impact of the desire to be able to work device-independent on the design of the IT landscape and the software to be developed is not small.

Construction principles for the IT architect: (10) Separating application function from data storage
Article
2 years ago | 5 min read
Construction principles for the IT architect: (10) Separating application function from data storage

In this series of blogs, I dwell on the still valid information science construction principles that guarantee better ‘information building’. This 10th blog in the series continues with the first informatics principle (for the distinction, see my starting blog ). This one is about the construction of data processing. We don't dwell on it but every screen we process information on hides an underlying construct that extracts data from a storage and allows us to access or modify this data or add new data. If the processing function and the data storage are separated, this has great advantages. In fact, this is the information science principle of decoupling but applied in computing.

Construction principles for the information professional (9): Apply standard patterns without deviations
Article
2 years ago | 2 min read
Construction principles for the information professional (9): Apply standard patterns without deviations

Standard patterns exist in both information science and computer science. The elegant thing about a standard pattern is that it is a standard. But in practice, there appears to be a reason to deviate a bit each time. The result is a user who no longer understands the user interface or a no longer interoperable concept, lower maintainability of a system and loss of time.

Construction principles for the IT architect (12): Choose a Storage Structure Based on Requirements
Article
1 year ago | 6 min read
Construction principles for the IT architect (12): Choose a Storage Structure Based on Requirements

In this blog series, I delve into timeless principles of information science that ensure better "information constructions." This 12th blog in the series continues with the third computer science principle (see my introductory blog for the distinction). Why and when should you choose a relational structure (RDB and SQL), and when is linked data (RDF and SPARQL) a better storage option? Most people think of data in terms of tables to organize it, but this also imposes certain constraints when you want to later modify the structure. What trade-offs exist between the possible solutions?