What is Leverage and How Does it Fit Into the CMS Landscape?

Leverage is a content management system that we’ve continually developed at Brolik over the last seven or so years. We’ve built 99% of our clients’ websites, portals, web apps and even native apps on top of Leverage. It’s powerful. It’s versatile. It’s completely under our control.

In our sales process, we get questions about Leverage, its strengths and weaknesses, and how it compares to other content management systems. Questions are framed around Leverage specifically, but underneath, they’re usually about content management systems in general.

• Is it fully featured?
• Is it simple to use? Is there good documentation?
• Can it integrate third-party APIs?
• Do we own the code? Is it on our server?
• Are there granular user permissions?
• Is it open source?
• Does it include search engine optimization features?
• Is it responsive?

Often, the answer to those questions turns into an informative discussion about what a CMS really is and what it should do, the pros and cons of different CMS types, and whether a specific CMS is right for a business’s exact content needs.

While I can’t speak to everyone’s exact content needs in an article, I’d like to explain a little bit about content management systems in general and why we’ve built (and continue to build) Leverage the way we have been.

What is a CMS and what are the different types?

The content management landscape is currently undergoing some drastic evolution. Businesses are learning that their website isn’t the only place their content should go. There’s social media ads and cards, other companies’ blogs, microsites, reviews, intranets… you get the idea.

Credit: Brolik

This concept of reusable content has specifically brought decoupled or headless CMSes into the spotlight. Before we talk about what those are, let’s start with another trait that separates one content management system from another.

Database vs. Flat File

There are two main parts to a content management system and the way it’s built. The first part has to do with how the actual content, or data, is stored. For the purpose of this article, I’ll focus on database-driven CMSes, which just means that data is stored in a database, not in a file. For background, though, I’ll quickly touch on file-based CMSes.

Flat file, as you may have guessed, stores the content in files that are read to a website or application on the front end. (This is the “opposite” of storing content in a database.)

Flat file CMSes are typically for smaller organizations or organizations with a dedicated team that knows HTML or basic markdown. There are some advantages to a flat file CMS, but they center around the simplicity and reduced overhead of building out the system to read and write data to a database. With flat file CMSes, content managers edit and write content directly to a website file and upload it to their website via FTP.

Since most companies don’t have the luxury of a team of content developers that know code, database-driven CMSes are more or less the industry standard. I’d guess ninety percent or more of content management systems are database-driven.

There are different types of database-driven CMSes, but most of the time, the way content is physically stored in the database means very little to the end user or the content creators. Leverage uses MySQL databases, which are relational tables of information, but sometimes we need to store data as key/value pairs, graphs or other formats, which is called NoSQL and is non-relational.

One of the advantages of using Leverage is that we can switch between relational and non-relational databases to use whatever is most appropriate for the project.

For comparison, WordPress, Joomla and Drupal (the big three) are all MySQL, relational database tables.

Ultimately, if a CMS can be versatile in how it stores and outputs content, the way the content is stored is relatively unimportant. Some CMSes will use their database structure as a selling point, but as a buyer, you should be interested only in how well it does its main two jobs– storing and outputting content.

Coupled vs. Decoupled

The second main part of a CMS has less to do with the content itself and more to do with how closely that content is tied to a specific website or application.

Traditionally, content management systems have always coupled together a back end (the CMS) and a front end (the website). In fact, when people refer to popular coupled CMSes like WordPress or Drupal, they’re usually referring to the entire package– both the front end website and the content management on the back end. Even as you’re reading this, you may have just realized that the content management part can be completely separate from where the content ultimately ends up.

You’re not alone.

Leverage is and has always been a decoupled CMS (also known as a headless CMS). This means that the part of Leverage that allows our clients to sign in and edit their content is not tied to and does not rely upon our websites or applications in any way.

In fact, you can tack on a Leverage CMS to any existing site that runs off of a database.

We saw where content was headed years ago and knew we had to prepare, so we’ve always been decoupled, but up until recently, no one would even have known, because no one knew to ask. There was a time when our clients only had use for content on their website. We’d make the website and CMS together and explain it as one package called Leverage.

Today, however, we’re seeing a completely different story. Our clients (and the industry in general) are really focusing on content and the power it has in today’s marketing landscape. There’s a need for content to be standardized, optimized and distributed to more and more places at faster and faster speeds.

Decoupled CMSes like Leverage can be set up together with a website or application, but they can include a mechanism for any other website, application or service to read and use their data. (That’s called an API… more on that later.)

The advantages of a decoupled CMS go beyond versatility. When the focus of the CMS is on content first, it can do things like:

• Automatically save images at various sizes (thumbnail, banner, Facebook post, etc.)
• Store metadata with content (like canonical information or what image to use when sharing on social media)
• Create extended, excerpt, and “tweetable” versions of any content
• Track content ownership and the history of content changes (who made what changes when)

There are more examples of that concept, but you get the idea. A decoupled CMS can automatically prepare content for wherever it will need to go, and it stores it in a way that’s simple to retrieve in full or in parts.

What should I look for in a CMS?

Beyond the data storage and coupled/decoupled distinction, there are a few popular topics that you’ll come across if you read articles about what to look for in a CMS. As I’ve stated, this varies business to business, so instead of telling you exactly what to look for, I’ll just tell you what’s out there, and you can make the connections to your own needs.

Modular content

This is more or less what we were just discussing with decoupled CMSes, but the idea is not just that content should be stored separately of a website. Content also needs to be stored in correctly-sized “chunks” so it can be easily distributed in full or in part to wherever it needs to go.

WordPress and Drupal, the current industry giants, use a hybrid of modular content and large blocks of text containing layout information, formatting information, and different types of content or code.

WordPress pages are single blocks of content that include text, styles and formatting information

For example, a “page” entry in WordPress contains a mixture of text, styling and formatting. To create a click-to-tweet link based on a callout or to move that callout to the sidebar, we’d have to pull the whole page’s content and parse out the specific text we need. Or, we’d need to edit the content itself as opposed to front end website code.

Leverage stores content as meaningful chunks that can be used anywhere

Leverage, on the other hand, stores every piece of content separately and reassembles that content on the front end. Storing each piece of content as its own entity in the database means we can create all kinds of different experiences on the front end– including customized or personal experiences.

Content API

The next topic you’ll increasingly come across is a content API. The idea behind a content API is that we need a standardized and simple way to pull content out of the CMS from anywhere. By definition, a decoupled CMS has no built-in place to “output” the content it holds. To display content, we build a website or an app and pull content out of the CMS using a content API.

APIs are not limited to just content from a content management system. An API, or Application Programming Interface, is a way for separate codebases to communicate in a standardized format.

Other commonly used APIs include pulling weather data into a weather app, stocks into a financial app or signing someone up to your Mailchimp email list through your website. Individual apps don’t check the weather in every location for every day, and they certainly don’t store and update stock prices in real time, so developers pull in this data (content) from an API. In Mailchimp’s case, the (awesome) email service wants to allow outside developers to manipulate Mailchimp data without giving them direct access Mailchimp’s code.

While APIs are old news, building an exposed content API off of a content management system is a fairly new trend. As I stated earlier, there previously wasn’t a huge need for this, but increasingly, there is.

Right now, none of the major open source CMS systems offer a content API, but I’ve heard rumors of content APIs coming for at least two of the big three. Keep your eye on this topic.

Support community

Another aspect of a strong CMS is a solid support community. In fact, this is typically the number one reason clients are scared to make a jump to a custom CMS.

It makes some sense. If CMS code is open sourced, anyone online can contribute to it, improve it, fix bugs, and more. With a large community, if a developer runs into trouble, a quick Google search will return a flood of helpful information. If that developer still needs help, a post on Stack Overflow is sure to get a quick answer.

This is especially useful for companies who have tighter budgets or a small development staff. Taking advantage of the community can be a huge asset. For companies that can either afford the development work or can’t afford the lack of privacy, however, open source may not be the answer.

Leverage is not open source. The only developers that have ever worked on Leverage’s core have been Brolik employees. We take great care to make sure our code is standard, well-written, and well-commented for when non-Brolik developers work on projects built on Leverage, but we don’t believe that our code or our clients’ code should be exposed to the public.

While you can easily see the benefits of a community (and why CMS articles place importance on it), the dark side of an open community is its vulnerability to hacks and attacks.

WordPress, for instance, is constantly fighting to stay ahead of attackers by issuing updates and patches. A large amount of these updates just close holes after a hacker has found them.

With open source code, it’s not possible to implement simple security measures, because every developer in the world can see all of the code. Hackers can just comb through every line until they find a vulnerability, and when they do, they know that a large number of websites on the internet are built with that exact code and can be hacked in the exact same way.

We prefer instead to keep our code close and to hire and train Leverage specialists– people who get paid to be Leverage experts and who not only use it daily but also build on the core and improve it for future sites. What’s even better is they build Leverage alongside marketers who use it internally and for clients, account managers who hear every idea for improvement, and the sales team that fields all of these CMS questions originally.

What’s next?

The CMS topics I covered here are what I consider to be the most common or most pressing issues for business owners looking to switch to a new CMS. There are plenty more considerations around choosing a CMS, ranging from what types of content an organization uses to how many employees they have to how many content touchpoints there are.

For information on those considerations and more, here is a hand-selected list of useful and current (at least at the time of this writing) articles.

• http://alistapart.com/article/choosing-a-cms-your-organization-will-love
• http://blog.invisionapp.com/the-future-of-the-cms/
• http://alistapart.com/column/nearly-headless-cms
• http://alistapart.com/event/content-management

If you’d like to talk with us about whether Leverage can work for your particular needs, email us directly, head over to our contact page, or call us at 267 297 8421.

If you’d like to learn more on your own first, there’s some information on Brolik’s site and on Leverage’s website.