New Approaches towards User Research and Software Architecture in Research Software Engineering: A Humanities Example
CC Attribution 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Pohl, Oliver
Notroff, Andrea
The "Census of Antique Works of Art and Architecture Known in the Renaissance" is a research database containing cultural heritage information. Currently, we are working towards a reconception of the "Census" and face the following two challenges. First, we know very little about the Census users' behavior. Second, it is necessary to steer towards a paradigm shift regarding the software architecture design of the current Census web application. In our talk we would like to present our findings and thoughts about user research in Digital Humanities (esp. focussing on art history) and discuss an approach to modular and sustainable software architecture for object- and image database application in the Digital Humanities.
 Thank you. And after corpus linguistics and aerodynamics and partial differential equations, I think I'm kind of the exotic bird here in the room or maybe also in this conference because I don't come from the STEM side. I'm a research software engineer in the humanities. Well, and the humanities can be a little broad in this project here. We are focusing on art history. So very exotic, maybe. And I work for the census LOD project and know it has nothing to do with the big controversy back in the 80s where the German state tried to inquire a lot about the German population. No, it is about art historical reception data. Basically, what did artists in post-Antique times, for example, in the Renaissance, know about art in antique times? For example, ancient Greece, so we can basically collect data to answer questions like what kind of artworks did Michelangelo see and how did it influence his work? And this database dates back into the early 80s in the US and then later migrated back to Germany and has been in a very, well, for some people, usable state, but somehow also for some people not so usable state because for a long time this has been a long-running project for about 20, at least the funding phase was, I think, 20 years until and then the funding ended. The people contributing to the project applied for another grant to continue using this kind of website, to continue this database, collect more data and reach it, but the grant was rejected. And one of the reasons was, well, your application is running on a commercial system that is kind of out of date and the graphical user interface is very difficult to use because this might look very familiar to you, like this is how maybe websites looked in the 90s or early 2000s with a lot of fields where you can put stuff in and get stuff out. However, people have been Google-ified and now they're, you are accustomed to more, let me say, easy approaches to information retrieval. So what I want to talk about now is how are we going to fix that problem with that kind of database I just showed you because we are in the fortunate position that the City of Berlin granted us another three years to come up with new concepts and recommendations, how to go from there and to apply for that kind of grant for once more. And this is not three years, not six years, but 25 years. So we have to think about the software consequences in a more long-distance future. And unfortunately, my colleague Andrea cannot be here today who focuses on the user-centered design in the agent art history or in general user research, but I will try to summarize her key points anyway. And later on, I will also discuss a little about the software architecture evaluation we did for this project. How do we go in the future there? So we have this database, there were some users and they have been used. The user number are not very high, but in the art history community across the world, our database was always seen as a kind of treasure, what you can actually do with the data, how to use that data, for example, for your own research, for publication and so on. But for some users, it was not always clear what do you actually collect, what is in there and why is it in there. And these kind of conclusions we could only do by doing some user research on conferences, talking to art historians, what their goals were, what their actions, what their means were to do their research. And I have, can you read those papers? Just the notes from my colleague. And oops. But times are changing and people are getting accustomed to more modern solutions to look things up on their phones and to actually want to have the data in a pure format, which in the humanities is we are going there, but in not every subdiscipline, we are there. So we have talked to a lot of people, what they want from us, so we can take this into consideration. But since we are only, well, we're not really software engineers per se, that's not our background. I come from information science, my colleague actually from gender studies, so we're both just kind of whittled in there and just learned, well, software engineering on the go. We were kind of, well, now we have this information, what do we do with it? And since our time is short, and well, resources are always kind of small, we also thought about, well, if we don't have the expertise, maybe somebody else has. And we did a rare thing to do for Humanities Project. We actually got in contact with UX designers. And now we're working with her to understand our users better, to observe them and to accompany us along the process of creating the kind of new prototypes, applications, user profiles, and so on, so we get to the goal we want to go. But unfortunately, I cannot summarize it as well as my colleague would have, so I skipped to the software evaluation part because, well, where did we come from and where do we go now, right? As I said, the software, the database is based on a commercial product provided by a company in Cedars-Berlin called Programme Fabrik. So basically, Programme Factory, if you want to translate it literally, and they offer a digital asset management solution called EasyDB, or EasyDB, however you want to pronounce it. And particular for our case, this EasyDB instance has been modified to the max, so it's really hard to upgrade it to newer versions and to develop new things from there. And on top of that, it's not even open source, so, well, I can understand why some reviewers of our grant application said, well, you should go open source, dude. And so what we basically did is, well, what are other people doing, right? This is the first thing you usually do when you're diving into a new subject. We looked at our colleagues in the fields of digital humanities and art history, what kind of database solutions they were using, and they listed a few of them on the left side there. And basically, we just started trying them out. And I don't mean, well, I am now a user and I click here and I click there. No, it means actually, well, how easy is it to install this into our local server infrastructure? Is it easily deployable? Is there well-documented code? Is there long-term support? Who are the maintainers? Is there a big community? And so forth and so on. The Software Sustainability Institute also provides a good guidebook and catalog of criteria on how to evaluate software for those kind of projects, which helped us a lot. Other factors were like because a focus on a project also was maybe we should go into a graph database or linked open data to also look at the capabilities of that. And well, there were some solutions like Research Space, which provided, well, very, very nice user interface and query ability, if that's the word, where you can query complex graph data in a very open format. However, there were basically, there was one or two big walls in the way of actually testing it the right way. And this was porting the data we have. Well, it is in a Postgres database. But, well, if we want to just take our data, put it into a different system, we would have to do a lot of adoptions that it actually works there. So this was also not a good idea to actually go in the long run. Well, what could we do now? Well, just a few days ago, we had a meeting. Well, we kind of have to scrap that kind of every relation approach there. And we somehow have to do it differently because, well, the recommendations we say now have impact for the next 25 years. And I will, how am I doing with time? Okay. Okay. Like, if there's still time tomorrow, I will showcase some of the system, but I think that's not the main point here. And, well, since who, maybe one or two of you have delved into like DevOps or something. And if you do that, you come across the rugged manifesto. And I'm usually not a big fan of reading quotations out loud in presentations. But since this is being recorded, and so people can listen, I will do it anyway. So the third point in the rugged manifesto means, as it says, I recognize that my code will be used in ways I cannot anticipate. In ways it was not designed and for longer than it was ever intended. And I think we've all been there, that we've kind of used some application, not as it was intended. Totally different differently. And I have anecdotes from the humanities. Maybe I just drift off here because I'm, yeah. Okay. So where do I go? Yes. For example, in another project, my two colleagues of mine are working very hard on. They are creating a digital edition and geographical information system about historic data about the Prussian state, or more like the royals in Prussia and what's called the important people. And since people, they wanted to start entering data right away, they did not use some kind of database, or even like XML or something like in a structure format, no. Well, they say, okay, we want to create org-organigrams. What do we do? We take Excel and create clip arts. And now if you want to use clip arts for a web application, for example, well, at least it's XML-E, so you can go from there and start migrating the data. Another example is people creating transliterations of Quran codices in Word documents using, well, some kind of template, but it's not always very pure. It's like, okay, it works, but it doesn't work really for if you want to have pure or data from the fair principles. So, well, this is basically the problem. How do we actually go against this kind of misuse? And how do we make sure that we have the data and the applications robust enough so they last at least 25 years? Because, well, if you think back, who was computing 25 years ago? One person, right? And it has changed a lot, right? Well, and so I don't know what the future brings. I can't even tell what the new features of Android phones will be like in the next two years. It is very hard to anticipate how technology changes and how this technology again changes user behavior. So what are the recommendations we can actually provide? Everybody's very tense now, right? And there are only a few. Well, although we have this kind of runtime of 25 years, the grant will only contain a developer position for like, what's it called, a halftime or like maybe two-thirds position. So while the actual art historians are collecting data, doing their research and so on, there's this one gal or guy who has to keep this service up and running. And it is no option actually to just keep the old version of this database up and running. So what do we do? Okay, we could of course upgrade it to the newer version, which means at first it costs a lot of money. Well, it is a little more extensible, but we're still faced with a problem. Oops, still not open source. So that's basically a no-go. And so it has to be maintainable for basically research software engineers in the humanities who has to not only understand, has to also be in the mindset of an art historian and a proper research software engineer or a software engineer in general. You kind of have to create a more modularized approach of your whole software. I don't think that still having a monolithic software architecture for web applications is still, is not proper anymore for these kind of kind of run times. And I don't think that I'm speaking anything in you here for some of you people. So basically if we started, for example, migrating, do we have a point as you just want to use it? No. Where's the... So basically, by modularized approach, I mean just break it up into different components and then replace it when it needs to be replaced. Right now, everything is one application like basically the database is connected to the CMS, which directly outputs the data. We have no API, no means of extensibility. But if we would have to start redesigning the software tomorrow, an idea would be, well, we keep the current easy to pick up and running since it is configured to enter the data properly in the current way. And it works. And then we start maybe to create a REST API or GraphQL API, talking directly to the database, providing APIs for the open source community and humanities community, and the better usable front end for, well, the art historians and interested people in the world. And if we have done that after a few years, maybe we can then say goodbye because actually implementing the front end is actually not the hard part. But since this is so intricate data, redeveloping all the features to enter all the data we need in the proper way for the researchers in the project would just take another two years. So it is not a sensible approach to start there, I think. So, going from there, we always have to have in mind a kind of trade-off of sustainability and up to date-ness to always take the approach of the minimal effort in the long run so it stays maintainable, but you always also want to have an up-to-date code base with the best principles and a testable suite and so on and such. So it's very hard to find the up-to-date-ness, to really be up-to-date with their code then. And I'm really looking forward to how this will evolve in the next years, in the hopes that the grant will get accepted. So where do we go from now? We're currently in the process of actually creating our own project website where we will share our findings. We are hoping to get more insight about UI and UX in complicated research applications and we will start prototyping our new research approach, or information retrieval approaches in a few weeks with our UX designer so we maybe might be able to produce the first prototype at the end of the year or maybe since we have to consider other projects as well, maybe start of next year. And with that, I want to thank you for staying this late and I'm thankful for questions that you hopefully have. Thanks. Thank you very much for the talk and we have two questions, I see. So yeah, I'm working in mines in an archaeological research institute, so you're not the only humanities guy here, and I know all the problems you mentioned. I just want to know one thing, you should be part of the Union of Academies in Germany, right? So did you get in touch with the Academy of Science and Literature in Mines with the Digital Academy inside? Because there are a lot of people and they have a lot of ideas about all that things. Have you talked to them somehow? We have been talking to them a lot because I'm also working with Torsten Schrade and Sarah Petrov at different projects and yeah, so we are in contact. Thank you very much. One comment or question, I know also humanities is not like physics where you have a lot of money, but still if it's a 25 year project and just outlined how much work has to be done and you have a buzz factor of less than one, shouldn't you kind of say, well, this is a large project, we want to have two people, or this thing is kind of impossible in the landscape of research funding, because it seems like so much work and also like a work for the actually 25 years. Yes, we are still in the process on what to recommend and the current state is that they actually want to insert like a two third position, but we urge them to do actually more because the long tail will be that the architectures and the whole application will get even more complicated in the future because I don't know what will be there like VR, AR, maybe this, that might be where people are in a few years. And unfortunately, like just from experience within the humanities and digital humanities world in the, the Union of Academies, there are no projects that have been accepted for like with the full one full time position, but usually if you apply for more, they just say, yeah, because the main focus there is in those projects is not on the digital side but still on the humanities side of identifying the the art historical data doing publications and complete a corpus of maybe let me just make something up of all antiques situated in a specific part of Italy. So this, you have to find a trade off. And but, and another thing is that the this person employed then might not be there for the whole 25 years since the contracts are not necessarily bound to the whole runtime of the whole project, but to phases of evaluations which take place every three or six years. So, and so other people can also adapt you have to create a good kind of approach to your code to make it maintainable so other people in the future might as well take over. Does that answer a question. Yeah. Okay. We have another question. Yeah, my daughter from Humboldt University, just wondered why you're talking just about application sustainability and giving a time frame of 25 years I would just talk about data sustainability because it's for sure that you will have to change your applications every 10 years latest. I mean, no, if looking back 25 years that was one 1994. And if you try to use software from 1994 that won't be too successful today I suppose. So why not just talk about some data sustainability and then change your software stack every 10 years as it's normal for many infrastructure organizations. Well, data sustainability or in general research data management is also a thing we we have on our minds. And also the Academy we have now two people also focusing on that so we have this ball is rolling. And yes, like changing your application every, every decade or so well this is kind of normal. But the problem that I personally experience within my my team of now still I think 15 people like 15 people like me in different kind of projects. And is that as these as the funding of these projects run out there right right now. The we are still inclined to keep those services up and running so we have to keep kind of maintenance and we don't also want to And we cannot change the basic the basic UI and you you you X because there's no time for that. So these are basically the challenges we face there. Of course if we have a proper day research data management plan and corresponding repositories and export the data in a human machine readable format, we can go from there. But this will also be, I think a step that is that has to be taken within these 25 years to to make to part this data into that kind of format actually. So please don't.
 Thank you. And after corpus linguistics and aerodynamics and partial differential equations,  I think I'm kind of the exotic bird here in the room or maybe also in this conference  because I don't come from the STEM side. I'm a research software engineer in the humanities.  Well, and the humanities can be a little broad in this project here. We are focusing on art history.  So very exotic, maybe. And I work for the census LOD project and know it has nothing to do with the big controversy  back in the 80s where the German state tried to inquire a lot about the German population.  No, it is about art historical reception data. Basically, what did artists in post-Antique times,  for example, in the Renaissance, know about art in antique times? For example, ancient Greece,  so we can basically collect data to answer questions like what kind of artworks did Michelangelo see  and how did it influence his work? And this database dates back into the early 80s in the US  and then later migrated back to Germany and has been in a very, well, for some people, usable state,  but somehow also for some people not so usable state because for a long time this has been a long-running project  for about 20, at least the funding phase was, I think, 20 years until and then the funding ended.  The people contributing to the project applied for another grant to continue using this kind of website,  to continue this database, collect more data and reach it, but the grant was rejected.  And one of the reasons was, well, your application is running on a commercial system that is kind of out of date  and the graphical user interface is very difficult to use because this might look very familiar to you,  like this is how maybe websites looked in the 90s or early 2000s with a lot of fields where you can put stuff in and get stuff out.  However, people have been Google-ified and now they're, you are accustomed to more, let me say, easy approaches to information retrieval.  So what I want to talk about now is how are we going to fix that problem with that kind of database I just showed you  because we are in the fortunate position that the City of Berlin granted us another three years to come up with new concepts and recommendations,  how to go from there and to apply for that kind of grant for once more.  And this is not three years, not six years, but 25 years.  So we have to think about the software consequences in a more long-distance future.  And unfortunately, my colleague Andrea cannot be here today who focuses on the user-centered design in the agent art history or in general user research,  but I will try to summarize her key points anyway.  And later on, I will also discuss a little about the software architecture evaluation we did for this project.  How do we go in the future there?  So we have this database, there were some users and they have been used.  The user number are not very high, but in the art history community across the world, our database was always seen as a kind of treasure,  what you can actually do with the data, how to use that data, for example, for your own research, for publication and so on.  But for some users, it was not always clear what do you actually collect, what is in there and why is it in there.  And these kind of conclusions we could only do by doing some user research on conferences, talking to art historians,  what their goals were, what their actions, what their means were to do their research.  And I have, can you read those papers?  Just the notes from my colleague.  And oops.  But times are changing and people are getting accustomed to more modern solutions to look things up on their phones  and to actually want to have the data in a pure format, which in the humanities is we are going there,  but in not every subdiscipline, we are there.  So we have talked to a lot of people, what they want from us, so we can take this into consideration.  But since we are only, well, we're not really software engineers per se, that's not our background.  I come from information science, my colleague actually from gender studies, so we're both just kind of whittled in there  and just learned, well, software engineering on the go.  We were kind of, well, now we have this information, what do we do with it?  And since our time is short, and well, resources are always kind of small, we also thought about, well,  if we don't have the expertise, maybe somebody else has.  And we did a rare thing to do for Humanities Project.  We actually got in contact with UX designers.  And now we're working with her to understand our users better, to observe them and to accompany us along the process of creating the kind of new prototypes, applications, user profiles, and so on,  so we get to the goal we want to go.  But unfortunately, I cannot summarize it as well as my colleague would have, so I skipped to the software evaluation part because, well, where did we come from and where do we go now, right?  As I said, the software, the database is based on a commercial product provided by a company in Cedars-Berlin called Programme Fabrik.  So basically, Programme Factory, if you want to translate it literally, and they offer a digital asset management solution called EasyDB, or EasyDB, however you want to pronounce it.  And particular for our case, this EasyDB instance has been modified to the max, so it's really hard to upgrade it to newer versions and to develop new things from there.  And on top of that, it's not even open source, so, well, I can understand why some reviewers of our grant application said, well, you should go open source, dude.  And so what we basically did is, well, what are other people doing, right?  This is the first thing you usually do when you're diving into a new subject.  We looked at our colleagues in the fields of digital humanities and art history, what kind of database solutions they were using, and they listed a few of them on the left side there.  And basically, we just started trying them out.  And I don't mean, well, I am now a user and I click here and I click there.  No, it means actually, well, how easy is it to install this into our local server infrastructure?  Is it easily deployable?  Is there well-documented code?  Is there long-term support? Who are the maintainers? Is there a big community? And so forth and so on.  The Software Sustainability Institute also provides a good guidebook and catalog of criteria on how to evaluate software for those kind of projects, which helped us a lot.  Other factors were like because a focus on a project also was maybe we should go into a graph database or linked open data to also look at the capabilities of that.  And well, there were some solutions like Research Space, which provided, well, very, very nice user interface and query ability, if that's the word, where you can query complex graph data in a very open format.  However, there were basically, there was one or two big walls in the way of actually testing it the right way.  And this was porting the data we have. Well, it is in a Postgres database.  But, well, if we want to just take our data, put it into a different system, we would have to do a lot of adoptions that it actually works there.  So this was also not a good idea to actually go in the long run.  Well, what could we do now? Well, just a few days ago, we had a meeting.  Well, we kind of have to scrap that kind of every relation approach there.  And we somehow have to do it differently because, well, the recommendations we say now have impact for the next 25 years.  And I will, how am I doing with time?  Okay. Okay. Like, if there's still time tomorrow, I will showcase some of the system, but I think that's not the main point here.  And, well, since who, maybe one or two of you have delved into like DevOps or something.  And if you do that, you come across the rugged manifesto.  And I'm usually not a big fan of reading quotations out loud in presentations.  But since this is being recorded, and so people can listen, I will do it anyway.  So the third point in the rugged manifesto means, as it says, I recognize that my code will be used in ways I cannot anticipate.  In ways it was not designed and for longer than it was ever intended.  And I think we've all been there, that we've kind of used some application, not as it was intended.  Totally different differently. And I have anecdotes from the humanities.  Maybe I just drift off here because I'm, yeah. Okay.  So where do I go?  Yes. For example, in another project, my two colleagues of mine are working very hard on.  They are creating a digital edition and geographical information system about historic data about the Prussian state,  or more like the royals in Prussia and what's called the important people.  And since people, they wanted to start entering data right away, they did not use some kind of database,  or even like XML or something like in a structure format, no.  Well, they say, okay, we want to create org-organigrams.  What do we do? We take Excel and create clip arts.  And now if you want to use clip arts for a web application, for example, well, at least it's XML-E,  so you can go from there and start migrating the data.  Another example is people creating transliterations of Quran codices in Word documents using, well, some kind of template,  but it's not always very pure. It's like, okay, it works, but it doesn't work really for if you want to have pure or data from the fair principles.  So, well, this is basically the problem. How do we actually go against this kind of misuse?  And how do we make sure that we have the data and the applications robust enough so they last at least 25 years?  Because, well, if you think back, who was computing 25 years ago?  One person, right? And it has changed a lot, right?  Well, and so I don't know what the future brings. I can't even tell what the new features of Android phones will be like in the next two years.  It is very hard to anticipate how technology changes and how this technology again changes user behavior.  So what are the recommendations we can actually provide? Everybody's very tense now, right?  And there are only a few.  Well, although we have this kind of runtime of 25 years, the grant will only contain a developer position for like, what's it called, a halftime or like maybe two-thirds position.  So while the actual art historians are collecting data, doing their research and so on, there's this one gal or guy who has to keep this service up and running.  And it is no option actually to just keep the old version of this database up and running. So what do we do?  Okay, we could of course upgrade it to the newer version, which means at first it costs a lot of money.  Well, it is a little more extensible, but we're still faced with a problem. Oops, still not open source.  So that's basically a no-go.  And so it has to be maintainable for basically research software engineers in the humanities who has to not only understand, has to also be in the mindset of an art historian and a proper research software engineer or a software engineer in general.  You kind of have to create a more modularized approach of your whole software. I don't think that still having a monolithic software architecture for web applications is still, is not proper anymore for these kind of kind of run times.  And I don't think that I'm speaking anything in you here for some of you people.  So basically if we started, for example, migrating, do we have a point as you just want to use it? No. Where's the...  So basically, by modularized approach, I mean just break it up into different components and then replace it when it needs to be replaced.  Right now, everything is one application like basically the database is connected to the CMS, which directly outputs the data. We have no API, no means of extensibility.  But if we would have to start redesigning the software tomorrow, an idea would be, well, we keep the current easy to pick up and running since it is configured to enter the data properly in the current way.  And it works. And then we start maybe to create a REST API or GraphQL API, talking directly to the database, providing APIs for the open source community and humanities community, and the better usable front end for, well, the art historians and interested people in the world.  And if we have done that after a few years, maybe we can then say goodbye because actually implementing the front end is actually not the hard part. But since this is so intricate data, redeveloping all the features to enter all the data we need in the proper way  for the researchers in the project would just take another two years. So it is not a sensible approach to start there, I think.  So, going from there, we always have to have in mind a kind of trade-off of sustainability and up to date-ness to always take the approach of the  minimal effort in the long run so it stays maintainable, but you always also want to have an up-to-date code base with the best principles and a testable suite and so on and such.  So it's very hard to find the up-to-date-ness, to really be up-to-date with their code then. And I'm really looking forward to how this will evolve in the next years, in the hopes that the grant will get accepted.  So where do we go from now? We're currently in the process of actually creating our own project website where we will share our findings.  We are hoping to get more insight about UI and UX in complicated research applications and we will start prototyping our new research approach,  or information retrieval approaches in a few weeks with our UX designer so we maybe might be able to produce the first prototype at the end of the year or maybe since we have to consider other projects as well, maybe start of next year.  And with that, I want to thank you for staying this late and I'm thankful for questions that you hopefully have. Thanks.  Thank you very much for the talk and we have two questions, I see.  So yeah, I'm working in mines in an archaeological research institute, so you're not the only humanities guy here, and I know all the problems you mentioned.  I just want to know one thing, you should be part of the Union of Academies in Germany, right? So did you get in touch with the Academy of Science and Literature in Mines with the Digital Academy inside?  Because there are a lot of people and they have a lot of ideas about all that things. Have you talked to them somehow?  We have been talking to them a lot because I'm also working with Torsten Schrade and Sarah Petrov at different projects and yeah, so we are in contact.  Thank you very much. One comment or question, I know also humanities is not like physics where you have a lot of money, but still if it's a 25 year project and just outlined how much work has to be done and you have a buzz factor of less than one, shouldn't you kind of say,  well, this is a large project, we want to have two people, or this thing is kind of impossible in the landscape of research funding, because it seems like so much work and also like a work for the actually 25 years.  Yes, we are still in the process on what to recommend and the current state is that they actually want to insert like a two third position, but we urge them to do actually more because the long tail will be that the architectures  and the whole application will get even more complicated in the future because I don't know what will be there like VR, AR, maybe this, that might be where people are in a few years.  And unfortunately, like just from experience within the humanities and digital humanities world in the, the Union of Academies, there are no projects that have been accepted for like with the full one full time position, but usually if you apply for more, they just say,  yeah, because the main focus there is in those projects is not on the digital side but still on the humanities side of identifying the the art historical data doing publications and complete a corpus of maybe  let me just make something up of all antiques situated in a specific part of Italy. So this, you have to find a trade off. And but, and another thing is that the this person employed then might not be there for the whole 25 years since the  contracts are not necessarily bound to the whole runtime of the whole project, but to phases of evaluations which take place every three or six years.  So, and so other people can also adapt you have to create a good kind of approach to your code to make it maintainable so other people in the future might as well take over. Does that answer a question.  Yeah. Okay. We have another question. Yeah, my daughter from Humboldt University, just wondered why you're talking just about application sustainability and giving a time frame of 25 years I would just talk about data sustainability because it's for sure that you will have to  change your applications every 10 years latest. I mean, no, if looking back 25 years that was one 1994. And if you try to use software from 1994 that won't be too successful today I suppose. So why not just talk about some data sustainability and then change your  software stack every 10 years as it's normal for many infrastructure organizations.  Well, data sustainability or in general research data management is also a thing we we have on our minds. And also the Academy we have now two people also focusing on that so we have this ball is rolling.  And yes, like changing your application every, every decade or so well this is kind of normal. But the problem that I personally experience within my my team of now still I think 15 people like 15 people like me in different kind of projects.  And is that as these as the funding of these projects run out there right right now. The we are still inclined to keep those services up and running so we have to keep kind of maintenance and we don't also want to  And we cannot change the basic the basic UI and you you you X because there's no time for that. So these are basically the challenges we face there. Of course if we have a proper day research data management plan and corresponding repositories and export the data in a human machine readable  format, we can go from there. But this will also be, I think a step that is that has to be taken within these 25 years to to make to part this data into that kind of format actually.  So please don't.
Pohl_Notroff_0_7667.png Pohl_Notroff_7668_7871.png Pohl_Notroff_7872_8435.png Pohl_Notroff_8436_10403.png Pohl_Notroff_10404_26291.png Pohl_Notroff_26292_28091.png Pohl_Notroff_28092_30947.png Pohl_Notroff_30948_31427.png Pohl_Notroff_31428_31475.png Pohl_Notroff_31476_31607.png Pohl_Notroff_31608_32195.png Pohl_Notroff_32196_32603.png Pohl_Notroff_32604_32867.png Pohl_Notroff_32868_34031.png Pohl_Notroff_34032_34523.png Pohl_Notroff_34524_34655.png Pohl_Notroff_34656_34751.png Pohl_Notroff_34752_35087.png Pohl_Notroff_35088_35267.png Pohl_Notroff_35268_35315.png Pohl_Notroff_35316_36227.png Pohl_Notroff_36228_36467.png Pohl_Notroff_36468_37115.png Pohl_Notroff_37116_39823.png