Join the Largest Global Community in Computing

An interview with Ewa Deelman, recipient of the 2025 Sidney Fernbach Memorial Award.Dr. Ewa Deelman is the Research Director at USC’s Information Sciences Institute and Research Professor in the USC Computer Science Department, whose pioneering work in workflow automation has transformed how large-scale scientific research is conducted.Pegasus has become a cornerstone for reproducible science across disciplines. What were some of the early challenges you faced in designing a workflow system that could scale across such diverse scientific domains, and how did those challenges shape Pegasus’s evolution?We faced a number of challenges, both technical and social. Since we have written many papers on the technical challenges of Pegasus ([1] gives a good overview of the system) here I can focus on the socio-technical aspects.In the beginning, we needed to understand the requirements of the domain scientists. In 2000, we started working with gravitational physicists from LIGO, high-energy physicists from CMS (Compact Muon Solenoid) and Atlas, as well as astronomers. I was just starting a position at USC/ISI after my Postdoc at UCLA.  These were new collaborations for me, new problems to tackle. My background was in high-performance computing and parallel discrete event simulation. In this NSF-funded GriPhyN project, we needed to address issues related to distributed systems (the data and computational resources were distributed geographically), and we were exploring the concept of virtual data in that context. The idea was that the scientist could ask for data, like a mosaic of an area of the sky, and the system would determine if this image was already available or whether it needed to be materialized.  To support this idea, we were developing new computer science concepts, abstractions, and systems while aiming to understand the scientists' needs to ensure we provided them with the right tools. It also took some time to understand…

IntroductionLearning Metadata Terms (LMT) is a standard that connects metadata terms in practice with the purpose of solving many use cases common to e-learning. While there are other metadata standards, they have been inadequate for keeping up with machine-readable data requirements, which modern AI needs to achieve significance. While data models attempt to be free of technical bindings, there are fundamental design decisions that relate to whether data is intended to be stored in a graph database or as a record.Overview of the StandardThe purpose of the standard is to allow both human and machine traceability across properties of any type of learning resource. Because “learning” is so broad, it really can apply to any described learning “object”. Unlike previous metadata standards, LMT differentiates the purpose of the learning object by describing it as either a learning resource or a learning event. A learning resource is anything that is used for learning, that is intended to be a shared resource that is almost always digital. The point being that copies of it can be made, and with the right permission, it can be redeployed or first repurposed and then deployed. Learning events, categorized separately, are either instances of learning resources or are resourced opportunities for learning. A common way to put it within the working group was “if you can be late for it, it’s a learning event”.The standard is extremely relevant for all of the reasons metadata is relevant. By allowing learning resources and learning events to be described, explained, and located, it enables end users of those objects to be more easily connected to them, allows their proper usage, and enables management of learning resources and events. Because learning happens everywhere and encompasses not just knowledge, but skills, abilities, and attitudes, the standard has broad use. In addition,…

What is Platform EngineeringBefore we understand platform engineering (PE), let’s quickly run through a scenario of typical software teams. Here, we have multiple teams working on different projects. Each team has their own way to set up servers, set up CI/CD pipelines, set up monitoring tools, and deployment scripts, etc. The problem is that, when we have a completely new team for a new project, the company has to spend time and resources to set them up with the same set of tools. In some cases, the setup is included in the project scope. The tools can be different based on the technology stack, but the motive would be the same. This can be time-consuming and costly.Enter platform engineering - The idea behind platform engineering is to give developers ready-to-use, standardized tools and environments so they don’t reinvent the wheel every time. It is also referred to as “Internal Developer Platform”—IDP. Basically, with IDP, the team doesn’t have to spend time setting up infrastructure. They can just focus on the development of real products.Is it the same as DevOps? No. This is a common misconception about platform engineering. DevOps is more like a set of principles/guidelines (culture + practices) for achieving faster, automated, and more reliable software delivery. Platform engineering takes those principles and builds reusable systems (platforms) so that all teams can apply DevOps without reinventing automation from scratch.Importance of Platform EngineeringDuring the early adoption of DevOps (around the year 2000), it was expected that developers should implement necessary infrastructures beyond the actual product. While it improved ownership, it also created an unintended consequence: developer cognitive overload. [1]Research shows that developers spend over 10x more time reading and understanding code than writing it. Add to this the operational burden of managing complex deployment pipelines, monitoring systems, and infrastructure configurations,…