Data mesh: Airport’s perspectives on modern day data sharing’s challenges
- Like
- Digg
- Del
- Tumblr
- VKontakte
- Buffer
- Love This
- Odnoklassniki
- Meneame
- Blogger
- Amazon
- Yahoo Mail
- Gmail
- AOL
- Newsvine
- HackerNews
- Evernote
- MySpace
- Mail.ru
- Viadeo
- Line
- Comments
- Yummly
- SMS
- Viber
- Telegram
- Subscribe
- Skype
- Facebook Messenger
- Kakao
- LiveJournal
- Yammer
- Edgar
- Fintel
- Mix
- Instapaper
- Copy Link
Posted: 10 November 2023 | Anders Alfarrustad, Inge Abrahamsen, John C Paulshus | No comments yet
Avinor’s Business Developer, Anders Alfarrustad; the Head of Business Intelligence and Data Analytic, Inge Abrahamsen and Avinor’s Enterprise Architect, John C Paulshus, discuss the sharing and consumption of data and what this has meant for Avinor.
Oslo airport serves as a hub for many other Norwegian airports. Data exchange and analysis is crucial for efficient operation. Credit: Avinor
Today’s situation: increasing availability and demand for data
Avinor, a publicly-owned company that runs 45 airports in Norway and operates the Norwegian ATM services, has seen an increasing availability and demand for accessing data. Internet of Things (IoT) devices, smart phone apps, connected units in the traffic and increased digitalisation of manual routines are all driving the increase of data-availability exponentially. The data science and business intelligence department, being the ‘man in the middle’, is constantly lagging and becomes a bottleneck for insights and analytics. The demand for data, both by internal parties and external parties, is seemingly without limits. Many of the challenges are described in the 2020 ‘Data Mesh Principles and Logical Architecture’ written by Zhamak Dehghani.
Figure 1 shows examples of parties exchanging data with Avinor.
Fig 1. Avinor data exchange. Credit: Avinor.
In most business initiatives, like Avinor, data is emphasised as high value assets. Most of the processes for making the operation more cost-efficient are data-driven, including remote towers, autonomous vehicles for snow removal, common operation centres, remote screening of passengers and baggage, and making passenger prediction more precise. The introduction of artificial intelligence (AI) and machine learning promises great benefits across many areas but requires high volumes of data with expected quality of data to maximise the benefits.
Historical evolution of data sharing
Historically, the use and sharing of data has often led to data being mined directly into the productions systems. When the reporting load made production systems unstable, this was solved by mirroring the systems to replica databases. Weaknesses with methods used earlier, was often related to solutions being dependent on specific persons.
The need for reporting across single sources created the area of the data-warehouses, which separated the data from their systems and enabled a more data-centric approach. Additionally, with the data lakes, unstructured data could be managed in a more consistent way.
Avinor has decided to use the data mesh principles to make data available internally as well as externally.
How does Avinor understand and implement data mesh?
According to Wikipedia, a data mesh is defined as: ‘a sociotechnical approach to building a decentralised data architecture, by leveraging a domain-oriented, self-serve design (in a software development perspective).’ This definition by itself does not give much guidance on how to approach and implement a data mesh, so we must look elsewhere for some guidance.
Avinor has found it is beneficial to relate to the four principles of data mesh:
- Domain ownership
- Data as a product
- Self-serve data platform
- Federated computational governance.
These principles mean we must define data in a broader way than earlier, but also that responsibility is transferred to domain specific teams, which historically has less technical competence and interest. The domain specific people are more interested in business goals than technical aspects.
All the principles need novel approaches and considerations. For us, the principle of ‘Federated computational governance’ was the most difficult to explain and toaddress.
Zhamak Dehghani explains this principle partly, as:
“There is a need for these independent data products to interoperate and “a data mesh implementation requires a governance model that embraces decentralisation and domain self-sovereignty, interoperability through global standardisation, a dynamic topology and most importantly automated execution of decisions by the platform.”
How Avinor understands the challenges related to the “Federated computational governance”
‘Federated computational governance’ introduces the idea of interoperability through global standardisation. This is a challenge because a global standard simply does not exist. Many areas do not have standardisation models on a data product level. For airports, this is something that may be forwarded to the ACI ACRIS community, but Avinor is exchanging data elements that originates in industries other than the airport industry, so the idea of global standardisation is so far no more than an idea.
For example, when AVINOR catches data for prediction passenger flow in security control, the data comes from sources outside the aviation industry, such as from train, bus, and road information sources.
From a practical view we need to incorporate three main perspectives:
- Interoperability and standardisation within our company
- Interoperability and standardisation within the national transport sector
- Interoperability and standardisation with global perspective (such as SWIM…), international sector standardisation and recommended practices.
Avinor’s challenges with ‘domain ownership’
One of the challenges with ‘domain ownership’ is that the people in different domains have different degrees of data knowledge. Our hypothesis is that the user interface needs to be highly self-explaining and the IT-tech language must be as simple as possible to make the domain resources feel in control of the processes and making them as independent as possible of central IT resources. The domain resources may need some help, but we think the involvement of work from a central IT organisation is too large and that the central IT will become a bottleneck.
Avinor’s challenges with ‘data as a product’
Having ‘data as a product’ means both having the technical infrastructure to deal with data as a product, the user interface, and the understanding of how to do this. Technically, Avinor has chosen a platform called CKAN which is a data management system (DMS) to support features related to ‘data as a product.’
Avinor’s challenges with ‘self-serve data platform’
Having users catering themselves to data introduces a lot of challenges. One is that Avinor may not even know all the users of different data products; there are open and restricted datasets. For restricted data sets, the users need to authenticate themselves, and the data owners need to make rules for authorising access.
Data mesh, our experiences so far
Our findings have identified that:
- It takes time to build a data sharing culture and set up data teams
- Communication strategy is important for onboarding and executive commitment, and must share a common understanding
- Framework building can be costly and exhausting:
- It’s important to ramp up early with a value-driven approach and
- High value data objects must be identified early in the journey
- The tech platform must facilitate a high degree of self service and user orientation.
We also find that commitments at the C level, as well as business and tech stakeholders, are important key elements.
Summary
Our experience is that implementing and using data mesh is related to several challenges, involving domain resources requiring better documentation; more easily understandable interfaces and a collective understanding of terms and processes, which do create some more overhead, compared to the traditional method of having central resources responsible for data-availability and reporting. Some of the requirements are difficult for Avinor to influence, such as global standardisation.
But overall, we find that the benefits of data mesh are considerable larger than the downsides. The benefits include introducing a common technical platform and involving domain resources more than previously, which is reducing dependency on central resources.
At the end of the day, we think the data mesh approach is catering for more scalability and is a better way to support data usage and a higher degree of data quality.
About the authors
John Christian Paulshus has more than a decade of experience within Aviation. Working now as an IT architect in Avinor AS, he came from a position of Head of Operational IT solutions at Norwegian Airlines.
Before that he has a long track record of software development, process automation, digital transformation, and cost efficiency projects through different positions, such as Head of Software Development in a smaller software company.
He has focused on the importance of creating value through an IT architecture and IT policy that enables, supports, and facilitates the business strategy. John Christian has a Master of Science from Norwegian University of Science and Technology (NTNU), Trondheim and an MBA from Edinburgh Business School. John Christian is Chair of the workgroup for technical standards within the ACI-Europe, EOS and TSA joint initiative ‘Open Architecture for Airport Security Systems.’
Anders Alfarrustad has over 20 years of experience from the IT industry and was originally trained as a system developer.
For the past 10 years, he has worked with the development and implementation of solutions that will ensure efficient airport operations and good user experiences.
Inge Abrahamsen has been employed by Avinor for the past 12 years. He has a background in business intelligence since 1998. He is passionate about data-driven, data insights, data sharing and professional ownership of decision support.