This document describes a proposed software product called “Sovereign.” Our actual plans for Sovereign are up in the air at the moment, but this document is an attempt to describe the product, its role, and how it might be marketed.
But First, Have You Met Trevor?
You have a friend named Trevor.
Trevor is the smartest guy you know. He has an answer for everything, and he can get anything done.
You want to know the capital of Sierra Leone? Trevor can instantly tell you that it’s Freetown. You don’t know how Trevor knows this, he just does.
You want reservations to the best restaurant in town? Trevor must know a guy that he can get him on the phone and relay your party size and desired table. You don’t know if this is how Trevor works, but you know that you ask Trevor for a reservation, and he gets it for you.
There’s nothing Trevor doesn’t know, or can’t get done.
Every once in a while, you begin to suspect that Trevor is pulling the wool over your eyes. You think that maybe he just Googles for stuff when you’re not looking. But, you can never catch him. If he does it, he’s too fast to notice.
Besides, Trevor doesn’t just give you raw information, like he’s reading from Wikipedia. He always says it in his awesome British accent, and he usually mixes it in with some witty anecdote about something in his past.
“What’s the temperature in Moscow? Why it’s 22 Celsius mate, which reminds me of a time I was in Vladivostok in October 1987. Coldest bloody day I’ll ever remember. I was waiting for a freighter to come in from Tokyo, full of stolen VCRs…”
I mean, there’s just no way Trevor can fake that, right? He must just know everything all the time. That’s the only answer.
[record scratch sound effect]
Narrator: Actually, Trevor didn’t know a damn thing about anything…
Some Background
A content management system (CMS) is a server-based software package that manages the content of a website. This is the system you log into to change something on your website.
A common CMS is WordPress. Another one is Drupal. Those two are open-source (free). There are commercial CMSs too – systems like Sitecore and Adobe Experience Manager. These systems can cost anywhere from $50,000 to millions of dollars per year.
A CMS tends to be monolithic and jealous. Meaning, you can only use one CMS to manage a single website. You can’t mix and match, and you can’t run more than one at a time – you usually need to pick one and hope it works out, because it will “own” your website, from top to bottom. Any other software will have a hard time getting a word in edgewise. Generally speaking, enterprise software doesn’t like to co-exist with other software.
In addition to the cost of the software, you have to pay someone to install and configure it for your website. This is called an implementation. Much like the lumber yard just delivers a bunch of wood to an empty lot, someone has to come along and nail that wood together to make a house.
The company that does this is generally called a systems integrator (SI). They become experts with a certain CMS, then charge organizations five- and six-figure fees to implement it to support their requests (meaning, to produce and run their website).
One of the problems with implementing CMS is that, often, some information for a website has to come from other places than the CMS. If you have a CMS that stores articles for your news website, these articles can be stored in the CMS, which is relatively simple.
However, sometimes, information has to come from outside the CMS, by connecting to another system. This is often called an integration because you’re integrating one software package with another. This is usually always complicated and fraught with issues, because getting two different software packages to talk to each other is usually difficult.
For example:
Organizations often want to “integrate” a separate software package, so that it looks like it’s built into their website.
Organizations often can’t move out of an old CMS completely. Moving a long-standing website is like moving out of a house you’ve lived in for 50 years. Organizations sometimes want to do a staged migration to a new CMS.
Organizations often find that different CMSs work better at different things. For example, WordPress is great at publishing news articles, but not great at composing landing pages.
What would be handy is if there was a system to make it easier to integrate external data sources into an existing website. Ideally, we’d like to “glue” disparate systems together, so that one part of a website can be be serviced by one piece of software, and another part of a website can be serviced by another part.
For example:
http://mywebsite.com/news could be powered by WordPress, which is really good at managing news.
http://mywebsite.com/support could be powered by Redmine, which is a ticket management system.
http://mywebsite.com/services might still be powered by our old CMS, because we haven’t had time to move all that content over.
http://mywebsite.com/help is generated by our help authoring system, and that’s fine, but users need to authenticate to the CMS first, and the static generated website doesn’t support that.
Everything not listed above could be powered by Episerver, which is a really competent, mainstream CMS. So, Episerver would be the default option if the request wasn’t for something in the above list.
The problem is, of course, that all these software packages can’t coexist on the same website. They’d “fight” with each other. Each one would want to “own” the website.
Additionally, even if we could get them all running together peacefully, they’d all look different. It would be really obvious when you moved from one to another, to the point where you might get confused or nervous that you were on a different website. There would be no brand continuity between the sites, and the navigation would change from site to site.
What we need is a way to “glue” these different systems together, so they all run under the same website, and they look visually cohesive. What we want is for our customers to interact with all these different systems without knowing that they’re different systems.
Meanwhile, Back to Trevor
Wouldn’t it be great if we had a Trevor for our website? I mean, Trevor knew everything, and could do everything.
We could ask Trevor for the latest news from the website, and he’d tell us, in that glorious British accent, peppered with some great anecdotes about his time at Eton and Sandhurst.
We could ask Trevor to file a trouble ticket for us. He’d ask us a few questions, and – boom! – it would be done. We’d have no idea how he did it, but if we ever needed an update, Trevor would get us one.
We could ask Trevor to remember something we did together six years ago. Trevor would know instantly, as if it was yesterday, and he’d talk about it like he was providing live commentary on something going on right now. If something we did more recently is more relevant, Trevor might tell us that instead.
Yeah, that’s what we need. We need Trevor in website form. Trevor effectively “glued” together everything we needed to know or do. All we had to do was talk to him, and he became a universal interface to all sorts of people and information.
We loved Trevor.
URLs Matter
A URL is the address you type in a web browser, or that is typed for you when you click on a link. The acronym is for uniform resource locator, which is exactly how it’s described: it’s a uniform method by which to locate a resource.
An organization’s “URL space” is the collection of URLs it exposes to the public. This roughly coincides with the number of web pages (it can get a little muddled, but it most cases this is true). A small organization might expose a couple of dozen URLs, while Microsoft might expose 100,000 or more.
Philosophically, a URL is an amazing thing. It’s a token you can exchange for information. You might click a link, or type in a URL you copied down on a cocktail napkin, but in all cases, you have something of value – you can exchange this thing for information. A URL is a ticket.
URLs matter. Organizations tend to be flippant about them; they matter. They remove the contact that was at a URL, resulting in the dread 404 link. Sometimes, when they move to a new CMS, that system manages URLs an entirely different way, and an organization might unknowingly abandon thousands of URLs.
At some point, it became okay to simply delegate URL management to whatever piece of software is managing your website. New software? Okay, we’ll just rearrange our entire URL space and adapt.
Your URL space is the digital history of your organization. From the standpoint of the web, your collection of URLs is what you expose to the world. It’s the collection of tokens people can use to exchange for information from your organization.
URLs have value. They matter.
An Introduction to Proxies
When you type a URL into a browser, it makes a request to a server for some information. That information is returned to you in a response.
Sometimes, you make a request directly to a server, and it responds directly to you. But not always.
Sometimes, you make a request to Server A that doesn’t have what you’re looking for. So Server A duplicates your request, and passes it on to Server B. Maybe that Server B has what you want, so it sends it back to Server A who sends it back to you.
All of this happens so fast, you don’t even notice it.
Server A, in this scenario, is acting as a proxy. It is simply passing a request through to Server B, then passing the response back to you.
Occasionally, Server A recognizes an old URL and knows that it should be changed to a new URL. It can do one of two things here:
It can rewrite the old URL to a new one, then send the request to Server B. In this case, Server B would have no idea that the original request was different.
It can respond with a redirect, which tells the requesting browser, “You had Make your request again, to this new URL.”
Proxies are quite common for a lot of different reasons:
Organizations like to have proxy servers at the edges of their network so they can monitor the traffic that goes through them. They can block certain sites at the proxy by refusing to relay a particular request.
Networks like to use proxy servers to cache data. Let’s say what URL you want is really popular. Server A might save the response, and then just hand it back without asking for it from Server B, just to make things faster. Server B has usually told Server A, in the process of sending back a prior response, “You can just hang on to this for X hours. If someone asks for it again, don’t bother me – just use what I’m giving you now. After X hours, come back to me for new information.”
Some proxy servers route traffic to different places based on criteria. They might send the request to Server B, but they might send it to Server C under certain conditions. Or Server D, E, or F.
Various handling systems (Server B systems, from our example) will provide redirection, thought it’s rarely handled by a frontline (Server A) system. Usually, a request will proxy backwards, and the response will be a redirect, which will then have to go backwards through Server A, just to start the process over again with a new URL.
Proxy servers are basic web infrastructure. They’ve been around as long as the web, and they serve a very boring function that’s completely transparent to most people.
What Does This Have To Do With Trevor?
Trevor is a proxy server.
As it turns out, Trevor doesn’t know a damn thing. Trevor is just really good at finding the answers he needs in a hurry, and translating those answers into his trademark British accent and wit.
All those times you asked Trevor for something? He was just Googling on-the-fly. He was so fast that you didn’t know, and since all the answers seemed so deeply infused with his personality, you never thought to ask where he got the answer.
You just thought he knew everything.
But, in reality, Trevor just had the uncanny ability to “glue” sources of information together to appear to be a cohesive whole. Trevor got his information from all over the place, and talked to all sorts of people to get your requests fulfilled, he was just seamless about it, so everything he did appeared to be glued together into a single source of information.
Just…Trevor.
Introducing Sovereign
We are proposing the creation and sale of a software product we call Sovereign. (We’ll explain the name later.)
Sovereign is a proxy server, built on the .NET software stack. Sovereign is designed to allow organizations to present a single, cohesive website which is, in reality, glued together from multiple backend systems.
Sovereign becomes a “traffic cop” of sorts, performing two major functions:
It handles inbound request from users, evaluates them, and sends them to different backend systems for fulfillment based on criteria, or redirects them immediately.
When the responses come back through Sovereign, it can modify them to make them appear to be visually cohesive. It can, for example, modify navigation, or add a logo, or change the font. Sovereign “smooths over” the differences between systems, making your a website appear as a unitary whole, when it’s really pieced together from multiple systems under the covers.
We envision it as something like this:
A request for
/news/our-new-product? Well, news is managed by WordPress, so I’ll send the request there. When it comes back, I need to fix all the links so they point to the correct website, and the global navigation needs to be added.A request for
/support/ticket/1234? We get that from Redmine, our ticket management system. When the response comes back, we’re just going to lift out the entire body of the HTML page and drop it into our core template.A request for
/services/consulting? That’s still on the old website, so I’ll get it from there, and then we’ll just add the global navigation bar to the top.A request for
/help/getting-started? Okay, that’s fine, but are you authenticated? No? Okay, here’s the URL for the login page on the CMS site. Log in to that, then try again and I’ll let you through.A request for
/products/whizbag-5000? Holy cow, we renamed that product two years ago. Make your request again, except for/products/whizbang-6000this time.
In each case, Sovereign is managing the request. It’s either routing it to the correct place, or replacing the request. Sovereign is the traffic cop making sure that everything gets where it can be optimally served, then managing the response so it makes the most sense to the requestor.
Sovereign could operate in two modes: standalone or failover.
In standalone mode, Sovereign handles every request and dispatches all to one backend or another.
In failover mode, another system initially handles the request and fulfills it if it can. However, if it cannot, it then sends it to Sovereign for handling.
Failover mode would be appropriate when we have a CMS that will handle 95% of our requests. We don’t want to “invoke” Sovereign until we know that this request is one of the 5% that our core CMS doesn’t handle, since it will handle the vast majority. In this case, Sovereign handles the exception requests that can’t be handled by our core CMS, and need to be handled somewhere else.
Competition
Proxies are not new. As we said above, they’ve been part of the web since it was born.
However, most proxies are used for infrastructural reasons, much like the examples I provided above. Very rarely are proxies used for intentional servicing of content requests.
The most common proxy server for the last decade is called Varnish. It is commonly used to speed up websites – requests are handled by Varnish, which responds to them from memory, returning the last known response and not forwarding the request at all.
The drawbacks of Varnish (or other proxies) for our stated requirements are:
It’s based on the Linux technology stack. Enterprise organizations in the US are more likely using the .NET stack
It’s quirky and difficult to configure. It has its own proprietary configuration language.
There is no user interface. Customers don’t really want to buy software, so much as they want to buy visual interfaces. Customers want a dashboard, and visual control mechanism to their software.
It only runs in standalone mode. Varnish cannot run alongside a CMS and be invoked in standalone mode. In fact, Varnish is designed to run on its own server, and effectively “shield” the main web server from traffic.
It’s not design to be configured on-the-fly. Reconfiguring Varnish involves redeploying configuration files, and invoking your IT staff. There is no way for a site manager to reconfigure the software from an interface.
Sovereign would be designed to run on a more common technology stack, with a friendlier experience, and play nice with other software.
The Larger Technology Trend
The larger trend Sovereign addresses is one of distribution.
We believe that the days of monolithic CMSs may be coming to an end. For a large organization, with a large web presences, it is becoming more and more unrealistic for one system to provide every need.
Different systems provide for different interaction and usage platforms. The reluctance in using them is due to difficulties making them appear as part of a seamless experience.
We think the future is distributed. Organizations want to pick and choose from multiple systems and glue them together through a gateway framework which routes requests and homogenizes the responses.
The Business Model
Sovereign would run as both installed and service-based software. Both would incur an annual fee.
The installed version would be appropriate when Sovereign was expected to run in failover mode. It would be installed alongside the customer’s CMS, and be invoked when the CMS could not fulfill a request.
The service-based version would be appropriate when Sovereign was running in standalone mode, fielding every single inbound request. In this case, it could run on an entirely separate server architecture.
We think $500/month is a reasonable cost for the software. It could slide based on consumption or features, but that’s a price point we think is tolerable considering the value it provides and compared to the CMS software it is designed to compliment.
Marketing
Initially marketing would be to CMS integrators, like Blend. We know the challenges these companies face, with customers demanding for “this other system” to work seamlessly alongside their current website.
Another very common scenario is a customer with a large aging website who cannot move to a new website all at once. This customer needs to service what requests they can from the new website, but then have the request “failover” to the old website.
In both these cases, the challenge is providing some way for the external resources to appear to be part of the core or new website. As Sovereign allows for the manipulation of the response, the proxied systems can be made to appear as part of the original website. This isn’t true, of course, but Sovereign allows for an effective facade to be applied.
We have faced and solved these problems before, with varying degrees of success. Sovereign is a packaged solution to these problems.
Sovereign is the system that Blend wishes it had for the last 13 years.
Our other initial target would be CMS vendors themselves. A major obstacle to the sale of new CMS software is the old website, and the abject fear the organization experiences when it contemplates migrating it.
These migration projects can be disastrous, and there’s no good solution other than a “big bang migration.” The fallacy is that only one system can service a website, so organizations are faced with an all or nothing option – completely rebuild the old website, or do nothing at all.
Often, inertia causes them to do nothing, and the CMS vendor loses a sale.
Sovereign makes these situations easier. By allowing a small, new website to service what requests it is able to, then failing over the requests to the legacy site, it gives organizations a solution to slowly build out their new website and “cover up” the old one. As the new website gets bigger, it will handle more and more requests, and failover less and less often. Eventually – perhaps years down the road – no traffic will be routed to the legacy site, and it can finally be shut off.
CMS vendors would scramble for any solution they can present to customers to overcome this objection. Sovereign is that solution.
Finally, the Name
At the end of the day, all an organization “owns” on the web is their URL space.
Over time, an organization creates web pages which occupy URLs. These URLs can be serviced by multiple systems over time, as an organization implements one CMS, then takes it down and implements another. Oftentimes, previous URLs break, or get redirected to other content.
Oftentimes, organizations get perversely beholden to software vendors for how their digital real estate gets managed. One vendor does it one way, another vendor does it another way, and as an organization moves from one vendor to another, their URL space get polluted and managed erratically.
We want to declare sovereignty from external forces operating on our URL space.
Sovereign gives us that power. Sovereign is the front line that decides how a URL is going to be handled, what backend will service it, and how it will be presented back to the user.
When run in standalone mode, Sovereign “rides above” all the other software which provides responses from a website. It manages the gateway to these backend services, granting or denying access, and deciding how responses will be formatted.
We will no longer surrender our URL space – the single most important, forward-facing thing we own – to a motley collection of vendors.
We declare Sovereignty.