The Hub: Digital Transformation for Museum of Science, Boston

  • Built 56 custom apps, REST API with workflow engine, and React frontend, integrated with other enterprise systems.
  • Key tech: AWS Lambda, Node.js, React, MongoDB Atlas, Active Directory, Microsoft Graph, SharePoint Online, Exchange, OneDrive.
  • Served as one-person project / product management and development team with 80+ direct stakeholders.
  • My simultaneous roles: product owner / program manager, business analyst, software developer, database developer, information and process architect, copywriter, UX / UI designer, brand designer, and system administrator.
Published
November 18, 2018
Length
~2289 words
Time
~11 minutes
Published November 18, 2018
~2289 words // ~11 minutes
Share on Twitter
Image by CHUTTERSNAP.
I identified all of the business processes to be facilitated and talked with stakeholders to define each one.
The result was The Hub: 56 custom apps comprising a smaller footprint with increased security and ease of maintenance.
From there, I built software that implemented the business processes we'd defined.
The organization relied on apps to help our people serve a million visitors per year as well as the local community and larger scientific fields.
These apps no longer matched our needs and the cost of updating them was very high.

The Museum had an extensive but problematic group of web-based enterprise software applications and contents.

  • These were built in the late 90s / early 2000s, mostly in ColdFusion, a language now used by relatively few people and no one on staff.
  • They stopped evolving over a decade earlier and no longer matched the organization's business processes.
  • A partial reboot effort several years prior left staff navigating between two systems.
  • On the older server's web root were over 400k files, ranging from logs to image uploads to a prolific level of patched and repatched spaghetti code. No human could make sense of all of this.
  • A staff member needing to update her own published document had to submit a work order.
  • Staff members were clamoring for apps that worked the way they worked, wherever they worked, and more apps to solve more problems.
  • The on-premise server running the old apps violated PCI standards and the organization was faced with the prospect of investing in costly upgrades or losing its ability to accept credit card payments.

For all their deficiencies, these apps were indispensable. Hundreds of staff and board members used them daily, not only to accomplish discrete, structured tasks and familiarize themselves with policies, but to service more organic needs like collaborating on grant proposals, finding language translators for onsite visitors, identifying subject matter experts for media requests, and recruiting ad hoc help for private events, marketing campaigns, product testing, fundraisers, and cleaning up the Charles River.

In short, these were apps that helped our people serve a million visitors per year as well as the local community and larger scientific fields, but they weren't doing their job.

Since the old system was messy and no longer matched users' needs, I rarely even looked at it. Instead, I identified all of the systems' functions, reviewed requests for new functions, and talked to people who were still using paper forms. After establishing the stakeholders for each function, I collaborated with each one — over 80 stakeholders in all — to discover and define their business needs.

Stepping back from the software itself, we first identified what information they needed to receive from whom, when, who needed to be notified, and what steps needed to be taken in response. From there, we collaborated on how software could facilitate those processes, and I built the software to address their needs.

The result we called The Hub:

  • 56 custom workflow apps, plus an Intranet that serves as a gateway to these apps in addition to providing staff contact information, important policies, document libraries, and a messaging system.
  • A responsive and fully accessible UX, receiving near-universal praise.
  • One server shut down in 2016, and the other in 2019. No PCI-related risks were realized.
  • Most processes and data are now in the cloud, with improved security and redundancy. (A REST API server was built onsite, but its functions will join others in AWS Lambda.)
  • 100k centralized lines of code, down from from 400k+ files.
  • Simple, point-and-click access control.
  • Distributed content management — with my oversight and support, staff members manage their own documents and web content.
An iMac, in an office, displays the Person Lookup function of The Hub.
A smart phone, held by a person at a desk, displays the Person Lookup function of The Hub.

I was fortunate to work directly with over 80 stakeholders, from security staff to scientists to accountants to VPs to event planners to the COO and the Board Chair. Each person brought a unique perspective on the organization, a distinct set of challenges they faced in their work, and fresh thinking about how software can solve problems.

Consistent with much of my career, I wore a number of hats while building The Hub. I have been the product owner / program manager, but I've also been the business analyst, software developer, database developer, information and process architect, copywriter, UX / UI designer, brand designer, and system administrator.

Working with one group of stakeholders at a time made their lives easier and reduced scheduling overhead.
Balanced old with new, reducing the learning curve.
Agile process sped up support, which fostered good will.
Hosted drop-in help sessions.
Started with a single app good for both R&D and publicity.

Rather than tackling the entire platform at once, my first step was to identify one best app for initial R&D, and then to use that app for public testing and for a moderate level of organic publicity. I chose an app "owned" by my IT colleagues so that my first stakeholders would be among the most patient and understanding with my R&D. It turned out that my IT colleagues also had some of the highest expectations and most trenchant criticism, but that was good because it forced me to iterate to an elevated standard that likely saved me trouble and time in the long run. As this app was used by managers across the organization, a number of people quickly became aware of what I was doing and how the new software could make improve their working lives.

I continued the theme of leveraging relationships throughout this process. There was internal pressure to shut down one of the two old servers, and I did so but blended that approach with working with one group of stakeholders at a time, regardless of the server on which their apps were located. Of course, this was easier and more sensible for the stakeholders, who don't think in terms of servers. However, the biggest bottleneck I faced was stakeholders' busy schedules. Thus, when I got a group starting to think through their needs, I made sure to get everything I needed from them then, reducing scheduling overhead and forging the quickest route to the finish line.

Using an agile process, I released one new app every few weeks. Because of this, my support requirement was spread across a large time horizon and I never had a large number of support requests at once. In turn, I was able to respond to support requests quickly, often releasing iterations on several apps per day. This speedy support fostered good will across the organization. If I'd taken a waterfall approach and released all 56 apps simultaneously, I suspect some stakeholders may have been waiting months before I could address their concerns.

Over time, as apps were replaced and contents were migrated to their new homes, the gateway to the old system was maintained with messaging and continually updated links to the new items, allowing me to guide people to new items through their familiar pathways. In the same vein, the first iteration of the new gateway to the new items reuses elements of the old gateway, striking a balance between, on one hand, presenting familiar concepts and, on the other hand, making a strong impression of innovation that communicates high ROI.

As part of the final transition from the old to this first iteration of the new, I hosted multiple drop-in help sessions. Many questions were answered, and change-resistant hands were held. During these sessions, some people expressed a desire for additional guidance for future changes. To that end, as we begin to morph this first iteration into its long term form, I've planned that significant future changes will be accompanied by screens explaining usage in text, for those who prefer reading, and demonstrating usage in video (and audio), for those who prefer viewing or listening.

REST API — 72 microservices provided with Node.js, MongoDB, Express, ImageMagick, Windows Server.
Intranet Frontend — React, Sass, Webpack, Gulp.
Client-side workflow engine — JavaScript, jQuery, Sass, Gulp.
Access control, hosting, file management, email — Microsoft's Graph, SharePoint, Active Directory, OneDrive, Exchange.
Helpers — Figma, Adobe Creative Cloud, Inkscape.

I'm a fan of Linux and other open source / libre technologies, but the Museum loves Microsoft, which had been a generous donor in the past. Prior to my tenure, which began in 2013, it was determined that this product would be built on Microsoft SharePoint Online with Microsoft InfoPath, which is billed as an out-of-the-box, point-and-click solution for building workflow apps.

After some time, I convinced the Associate VP that InfoPath could not meet our needs. Suited for some power users but not developers, it simply couldn't accommodate the Museum's more complex business processes, even when supplemented with C#. SharePoint Online is a cloud service with no access to run backend code. Moreover, my knowledge of JavaScript was scant, frontend frameworks like React were not yet common, and SharePoint Framework (SPFx) did not yet exist.

Thus, I had to blend discovery and invention to develop a novel solution that could meet our needs. I learned enough JavaScript to repurpose the base concept of Forms7 (storing data as JSON in a SharePoint list), added in a number of libraries, and built a client-side workflow engine that manages screens, permissions, moderation, data validation, data storage and retrieval, and email notifications.

SharePoint's email API was problematic for us because it wouldn't allow an app to send email to someone who'd never used the app before. (Microsoft calls this a security feature.) So, spinning up a server was the only option. A sys admin gave me a Windows box connected to the network, and I installed Node.js, Express, and MongoDB and built from scratch a REST API that handles the apps' email notifications and now also affords 71 other services.

These days, a simple, custom, multi-stage workflow app with email notifications can be built and deployed in about an hour.

By 2018, it was time to replace the old navigational gateway and bring together these disparate apps, plus lots of content, into a new, cohesive platform. For this, I opted to use React, again teaching myself the needed skills.

This is brief statement 2. This is brief statement 2.
This is brief statement 3. This is another. This is brief statement 3. This is another.
This is brief statement 1.

In addition to the typical branding concerns, I was especially interested in communicating that this important part of the organization, which had been neglected for so long, was now in professional hands. A great brand can inspire confidence, and a brand only has to be lackluster to make people feel like they're dealing with an amateur they can't trust.

Human beings are especially attracted to faces — most especially their own. Thus, another part of my plan for making The Hub feel more human and more engaging is to use staff members' self-supplied face pics. (Admittedly, this concept is baked into parts of Microsoft Office, and it's also now common in other apps.) A few photos are being pilot tested as policies are being negotiated with HR, but, for most staff members, initials now hold the place where their photos will appear.

In a select few other places where photos are used, they comply with the Museum's main brand guidelines.

As mentioned in Change Management, some staff members feel they would benefit from additional assistance in learning and understanding usage, and demo videos are part of my intended solution. I'm also working with our Help Desk to create a library of self-help materials and documentation. All videos pertaining to The Hub begin with the adjacent, 4-second bumper with the animated identity.

The bulk of The Hub is enterprise apps. How does one attract people to something that is impersonal by nature? Obviously, gratuitous photo, video, and audio would get in the way of people's work, so color was used as the primary attractor. Thus, I've thrown in color just about everywhere it won't be an inhibitor or distraction.

Maximizing color usage meant putting colored type on a colored background — while, of course, adhering to accessibility standards for foreground-background contrast. Therefore, I created a light-to-dark scale for each brand color, and then create Sass variables and transparency mixins for each one.

The Hub is an endorsed sub-brand of the Museum's parent brand. The Hub's logo uses samples from the organization's parent brand color pallet in a shape that evokes the concept of a hub (elements around a central fixture). The logo doesn't include direct references to the parent brand, but typically appears in proximity to the parent brand.

While the creative work is my own, it was reviewed by the Museum's Brand Design Manager.

The logo can be used on dark and light colored backgrounds, and can be reproduced in greyscale. The file itself is a hand-edited SVG that can be targeted with CSS.

Typography has been an odd duck. The parent brand's typeface is Akzidenz Grotesque, the forerunner to Helvetica. However, some parts of The Hub, such as document library interfaces, are generated by Microsoft, which gives us almost no styling options. In these spaces, people will be met with Microsoft's font, Segoe. Until we can transition all of The Hub to the organization's parent brand typeface, all parts of The Hub use the Segoe typeface in order to create a cohesive and consistent experience across the platform.