Citizen Developers in UPenn's Nanofab Lab

Noah Clay is director of the Quattrone Nanofabrication Facility, University of Pennsylvania.

In 2014, my team at the University of Pennsylvania's Quattrone Nanofabrication Facility [http://www.nano.upenn.edu/core-facilities/nanofabrication/] created a custom lab management application to improve our suboptimal processes for registration, scheduling, billing, and analytics. Given our requirements — which included complex business rules, mobile access, cloud deployment, and single sign-on — we expected the project to take months or even years to complete, even with a large team of skilled developers. In fact, three lab engineers with no programming experience built the app (see figure 1) in three weeks using a cloud-based rapid app platform as a service (aPaaS).

Like everyone else involved in custom application development projects, we had grown resigned to long development cycles, high costs, and considerable complexity. So, when I first came across the idea that nontechnical "developers" in our lab could build apps and modify functionality quickly, it didn't seem plausible. Nonetheless, recent major advances in application development platforms and methodologies let us build our own lab management application using the Mendix App Platform running in the cloud. Rather than spending months setting up the development environment, we were able to create an application tailored to our specific requirements in a matter of days using the platform's visual modeling tools. The results worked so well for us that we now want to create an application development community of fellow labs and universities to share applications and components and benefit from each other's best practices.

Initial Challenges

Part of the new Krishna P. Singh Center for Nanotechnology, the Quattrone Nanofabrication Facility is a 10,800 square-foot cleanroom facility for micro- and nanofabrication. The state-of-the-art lab includes a suite of equipment that ranges in cost from tens of thousands to tens of millions of dollars. Both facilities serve UPenn's research and educational programs, as well as partner institutions and businesses in the greater Philadelphia area.

Managing access to highly sensitive, multimillion-dollar equipment is challenging. For starters, our six staff members support hundreds of researchers each year. To do this, we relied on several old systems and manual processes, including a calendaring application for scheduling, Microsoft Excel for billing, and even paper logs for some records. As you might guess, this posed multiple challenges to lab staff. If a research institution requested a progress report on charges its researchers incurred during the first part of the month, it took us three days to tabulate. If we needed to decertify a user's privileges, we had to do it one machine at a time. Finally, if we wanted analytics on which of our groups were undertaking various kinds of projects, we simply couldn't produce them.

With that context in mind, we set out to upgrade our systems. The choice was whether to buy a packaged application or build one ourselves.

To Build or to Buy?

Many large nanofab labs rely on off-the-shelf software. However, we knew firsthand that these implementations are neither fast nor flexible. For example, I was involved with a project at another university that used commercial software and took a year to roll out. Five years later, we still couldn't get the app to interact with the university's financial systems to generate invoices.

Packaged applications also force you to change the way you operate to match how the software is written. At the Singh Center for Nanotechnology, we have more than 100 unique pieces of equipment that we use in different ways. Attempting to customize off-the-shelf software to fit each piece of equipment's unique attributes would have been a major undertaking requiring significant time and money, as well as the expertise of professional developers.

As a research lab, we don't have the resources or expertise to manage infrastructure. We wanted an application that could be hosted in the cloud and fully managed by the vendor. In addition, we had to ensure that the application was always accessible via mobile devices, which are our researchers' preferred method of interacting. Most packaged applications simply couldn't deliver these capabilities without lots of additional programming.

Finally, most packaged applications have fairly complex license-management fees. Unless your organization can afford an enterprise-wide license, the cost of using a packaged application can rise substantially over time, particularly when you factor in ongoing customizations as your needs change.

Enabling Citizen Developers

Before deciding to build our own application, we consulted with UPenn's internal IT department, whose staff said they could build a system using the open-source CMS Drupal. But here's the kicker: the project's estimated timeline was two to three years, and we would be billed hourly for each ongoing change. We simply didn't have that kind of time or money; we needed a faster, more flexible option.

After considering all the factors, it became clear that a cloud application built using visual, rapid application development (RAD) tools from Mendix would best suit our needs. The fact that industry analysts such as Gartner and Forrester Research had already vetted the cloud platform made our internal IT organization much more comfortable approving our choice.

We built the application's core functionality in just over a week in February 2014, ran tests in March, and had it deployed by early April. We allocated three people to develop the application: two mechanical engineers and a materials scientist. Although the platform was generally easy to learn and use, each of our developers had different strengths and interests, so we divided the development tasks accordingly. This team created the business rules for accessing our equipment, and they now trade off in managing the application.

Our basic goals for the scheduling application were that it be:

• simple enough for anyone to use;
• accessible via smartphones and tablets;
• scalable enough to meet any future requirements;
• flexible enough to let us respond to changing business conditions; and
• deployable in a way that met our internal IT organization's security requirements.

The cloud-based app platform lets users design and build their own applications within an architectural framework that provides the structural integrity needed to maintain and govern an app portfolio. This approach let our "citizen developers" build their own application without compromising the IT environment's integrity, especially when it came to governance and security. Because the platform abstracts how applications are built using visual modeling tools that our developers mastered easily, we were able to deploy our new app quickly.

The Precise Application Needed

The real challenge we faced when building our app is that all the equipment in our lab has multiple levels of interlocking dependencies; these dependencies make scheduling access complex because we must factor many business rules into the application. From a researcher's perspective, a piece of equipment might appear available at a given time, but a process underway elsewhere in the lab might require the same equipment at a conflicting time.

Also, demand for lab equipment is heavier on weekdays from nine to five than on weekends. As a result, we must limit weekday access to any piece of equipment to a few hours. The challenge is that students and researchers have become adept at gaming the scheduling system, so we must be able to continually create and modify business rules to identify and modify such behaviors (figure 2).

Previously, we had to decertify user privileges one machine at a time. And, if we wanted to run a report to determine which groups were doing which projects, we couldn't. That is, we didn't have much visibility into how people were actually using the equipment.

In building our new scheduling application, our goal was not only to reduce development time and cost, but also to improve the whole change-management process. As a research facility, we don't generate profits that can be reinvested; the university not only pays for the lab equipment itself, it also spends millions of dollars on buildings to house that equipment.

The lab management application helps us better predict our costs using a billing system that lets us see how much revenue we are generating in a given month. Our previous billing system — based on Microsoft Excel spreadsheets combined with paper records — required manual entry. Figuring out how much revenue we were generating in any given month was not only painfully slow, it was clearly error prone. In fact, from a compliance perspective, the lab is much better off with the new application. We not only know who is scheduled to use a particular piece of equipment, we can easily determine who used that equipment at any given time.

The aPaaS gave us a mechanism to visually model all of those scenarios and contingencies in a scheduling application that we could deploy in the cloud with a single click. And, changes to the application can be made in a matter of minutes, at no additional cost to the lab (or the university) beyond our engineers' time. Moreover, the platform made acquiring, installing, and managing the IT infrastructure to run the application a non-issue; the vendor automatically manages all tactical IT security and data protection issues, including backup and recovery.

Demo of UPenn's Lab Management App (2:38 minutes)

The Mendix application platform (3:13 minutes)

Building a Network of Like-Minded Universities

By definition, the university research community is collaborative. One of the platform's capabilities is the ability to publish and share applications and reusable components through a public app store (see figure 3 for a possible entry). As we continue to hone our processes, we expect to share our scheduling application with other universities, along with any future applications we build.

We hope that as other research organizations discover the platform's capabilities for "self-serve" app creation, they, too, will publish applications and components that benefit us all. After all, university researchers face a major challenge: the quality of their research experience directly affects their ability to qualify for additional grants and invitations to join collaborative research projects — and information spreads quickly across nanofabrication communities. At UPenn, we not only want to service more researchers, we want the brightest minds in our field to prefer using the Singh Center for Nanotechnology equipment rather than contracting with research facilities provided by other universities.

Conclusion

Many research organizations and other institutions want access to highly sensitive, multimillion dollar lab equipment, but it doesn't necessarily follow that an IT department must build, support, and customize its applications to manage who can access those resources on any given day. Instead of burdening internal IT organizations with their app needs, a university's individual colleges and departments can build their own applications using cloud platforms with integrated visual modeling and deployment capabilities.

For the IT organization, this new application development approach might eliminate the project backlog once and for all. Rather than having to constantly prioritize (and deny) numerous requests, IT can give departments like ours a framework to service their own development needs, with the knowledge that they can apply governance and security policies to the application portfolio. IT can then concentrate its efforts on its core strategic initiatives.

aPaaS products in the cloud can give organizations like UPenn greater freedom in how we build applications, but, more importantly, they also give us speed and flexibility in how we respond to our constituencies' needs. These tools represent an opportunity to involve users — citizen developers — in application development at a time when centralized IT already faces multiple department requests on top of the major strategic projects that constitute their main responsibility. When you consider that the people who will directly benefit from an application have the greatest interest in seeing it built, empowering them to do it themselves makes everyone concerned happier.