Connected architecture framework: emphasis on the organisation of data
Architectural approaches in the BI, analytics and data work fields, emphasise ‘what’ you should do. These approaches are technically based. They are all about blueprints and relevant methods. They prescribe how you should implement the solutions, the rules for data modelling and data logistics and how you can ensure that the solutions continue to function.
How you should organise things to achieve the what and under which conditions, is explained in connected architecture. This approach is rooted in human interaction.
This answer hasn’t just appeared out of thin air. We have seen many projects succeed technically, but with results which weren’t anchored in the organisation. It must be possible to do this better and through experience we have discovered how to improve on this.
Working with data has become more complex because there is more of it, and because it is available in many forms. The existing reference architectures don’t have a good answer to this issue. Barry Devlin has provided a new reference architecture with IDEAL and REAL. In contrast to other reference architectures, its starting point is how people work with information. We have added to this from our experience of applying this new reference architecture in practise.
The organisational dimension of architecture
Organisations are struggling with how you can ensure solutions are used, how you can manage changes in information requests and usage and the ensuing solutions. Within conventional BI and data architectures, managing change is limited to how you process changes within the solutions.
The connected architecture framework has been set up to:
- manage the coherence between information requests and usage as well as ensuring and managing the creation and adaptation of solutions and
- to guide how it is organised.
Existing BI and data architectures and data modelling methods can fit within the framework to shape the information component. In the alignment component, the suitable technical architecture is determined. Suitability is defined by human interaction, as it occurs in your organisation.
A visual adaptation
The framework is a visual anchor point. It helps you keep an overview of what needs to be organised.
In practise, it is difficult to keep coherence. New insights occur through human interaction when applying information. This often leads to new or additional questions. Then there is more human interaction needed to translate the requests properly and to test them on the data. This again, leads to additional or new insights during the production process of new information products. Application and development influence each other. A process of alignment is needed to focus these in the same direction. The framework helps to make that clear.
In the introductory article, the framework was represented in this way:
Three connected processes represent how you manage the information landscape. We learned from feedback that it wasn’t clear that the three coloured rows represent processes. So, this feedback has led to a new graphic:
What has been changed and why?
The scope of the data organisation has been made explicit and the interaction between the components has been added. This interaction has a knock-on effect on the processes.
A clearer differentiation has been drawn between the scope of the organisation of data, how you can design its governance within the scope and at which points governance affects the processes.
Human Interaction
The ‘agile collaboration model’ has been renamed ‘collaboration process for agility’. The model is the result of the process.
The use of the word ‘agile’ is not without risks; it has become an overused term which is not viewed positively by everyone. Agility is not a method, but a need felt by organisations. So, here that need is being expressed.
Alignment
’Architecture decision making process’ has been renamed ‘alignment and change process’. In terms of content, nothing has changed, but the word ‘architecture’ often conjures up an image of ‘technical implementation architecture’. In this framework, we mean architectural thinking.
Architectural thinking is a systematic process of ordering; you are constantly working on bringing about and retaining coherence in human interaction for the use and delivery of information and for the design process of the solutions. This is no static situation; it’s dynamic.
Environments are dynamic, and alignment and change processes need to ensure that changes are absorbed in the right way. Both in the organisation as well as in the solutions.
In this alignment process, the ‘just enough’ principle and the ‘use case’ approach are put to work. This is in addition to guarding the coherence between teams working autonomously using an (architectural) alignment principle going beyond the individual teams.
Information
’Data landscape design’ has been renamed ‘information design process’. The landscape design, the blueprint, is a result stemming from this design process.
Getting going with the framework
The diagram by itself is not enough to get started with. Various sub-aspects in this approach have already appeared here or are going to be published. A pragmatic approach to implementing the framework in practise, is the subject of a book we will be publishing in the (near) future.