The receptionist, security guard, decorator and delivery person — NCVO’s front controller
The last post in this series about NCVO’s technology strategy started to describe an emerging vision for a future technical architecture — a leaner system that allows us to scale our impact in a sustainable way.
In this post I want to dig deeper into the centrepiece of that vision — what we’re calling NCVO’s front controller.
What is the front controller?
First, a fairly technical description…
The front controller is an application which will marshal requests to appropriate underlying applications, providing a single place to control the delivery of user interface elements, handling caching, authentication and the restriction of membership content.
(I’m happy to say that I now completely understand the paragraph above. But I have no problem admitting that it took many conversations and to get me to that point.)
Or, here’s enough way to think of it, with full credit to my fantastic colleague Sophie Raeburn:
The front controller is like a receptionist, security guard, decorator and delivery person.
How will it work?
Let’s expand on Sophie’s description above:
The delivery person
When we order products online, we have no idea where (on what shelf, in which warehouse) this product is. But we know what we want and a delivery person will bring it to us. Similarly, when we want to read a piece of content or use a digital service, the front controller will know what we’re after because of the URL we request. It will then redirect us to that page or service wherever it is, whatever technology it is built on.
Switching my analogies, when we enter a building we may know what we’re after but not exactly where to go. A receptionist (hopefully along with some effective signage!) will tell us where to go. Similarly, the front controller will apply a common high-level navigation to different websites and services, whatever technology they’re built on, so that users can find their way around and get what they need.
The security guard
But maybe we don’t have a right to access part of a building, and a security guard will stop us. Similarly, we may not have the right to view some content or services unless we are connected to an organisation that is an NCVO member, or have purchased a product or a subscription. The front controller will ask our CRM, via the NCVO-API (see my last post for more on the API) whether we are allowed access. If we are, it will let us through. If we’re not, it will provide helpful next steps and options to get access.
The front controller also acts as a security guard for our user data. The front controller talks to the NCVO-API or our login system (OpenID) for user data, meaning that the underlying services do not need to*. This means a significantly more secure environment for sensitive user/customer data.
(* Caveat: this is a slight over-simplification…)
What does this building look like I wonder? Chances are, there’s some kind of visual identity that has informed how it has been decorated. Similarly, online things look nice (or not) because of decisions that are made about how to style different bits (or components). Rather than each site or service applying styling separately, the front controller will apply a consistent look and feel to everything that you view.
Or, here’s a more technical description
- User requests a page
- Front controller accepts request
- Front controller looks up resource/action related to request
- It looks up as to whether the user has a valid subscription for that resource
- If they have, it checks whether it has a cached version of that resource, if it is something that can be cached. If so it will return the cached item, reducing hits to the service
- If not it retrieves the resource from the underlying application sending user details if needed to customise/act upon the request
- It returns the resource, decorating it with the shared UI
Why build it?
I’ve talked throughout this series about our large and fragmented portfolio of digital products and services — one of the triggers for the entire strategy process. I’ve also shared how we learned about what this meant for users. In summary, this fragmentation has resulted in a disjointed user experience.
This is the first objective of the front controller — to provide a more unified user experience.
But our current set up is also complex and costly to maintain. Our second objective is to lower the cost of ownership and the cost of developing new services. We are hoping for:
- Improved scalability — the front controller contains a cache for regularly/recently requested items which should reduce our hosting costs
- Lower cost of ownership of digital services — they will no longer need to be updated if the branding or navigation changes as they deliver “nude” pages back to the front controller
- Lower cost of developing new services — they will no longer need to be able to integrate with OpenID or CRM (although of course they will need to integrate with the front controller — something we’re currently learning lots about).
Where are we with the project?
Over the last year we’ve come a long way.
The first step was to flesh out our high level vision. Chris Thorpe (introduced in my last post) produced a brief and an initial proof of concept/prototype.
We then needed to find a new technical partner that have the skills to develop the technology, and values and ways of working that fit with our own. We are delighted to have developed a strong partnership with Neon Tribe.
In the autumn we completed a discovery process to clarify goals and identify user needs (in this case, focusing on NCVO and our technical partners as the users of the front controller). We also confirmed the technology we are using (python), following a period of prototyping and experimentation.
What have we learned?
We are planning a meeting with all our partners to review how the project has gone so far and what we’ve learned. I’ll update this post with some of the key lessons.
(Huge thanks to Sophie Raeburn and Chris Thorpe, who are the people behind this ambitious project. This post would not exist if I couldn’t draw on their various articulate descriptions of the front controller! And any errors are completely mine)