Developing WordPress for the Enterprise

23 Comments

worpress-for-the-enterpriseA note before you start reading this. First, I hope you watch this video first. Second, I hope you have some coffee, tea, or a soda with you, because this is going to take a bit to read. And if you give me a tl;dr reaction, it says more about you than about me, so feel free to move on.

I work in the Enterprise Software Space

I work in the enterprise space, when it comes to software. I have my entire professional career. While others were building cool online pet food stores, I was building online telecom billing platforms.

So my perspective on this year’s State of WordPress address comes because of the filter I have of hearing things in the context of the enterprise. And that’s why what I heard worried me a bit about the upcoming development strategy and WordPress’ move into the enterprise.

WordPress is becoming an Application Framework

See, the first part of Matt’s talk was about how WordPress had been in the process of becoming an application framework. I couldn’t agree with him more. After all, I’ve written about how I’ve used it that way several times.

I agree with him, not just because I’ve personally done it, but because I’ve watched others do it as well – more and more often. WordPress moved into the enterprise initially into Marketing Departments (with capitals “M” and “D” as Jason Cohen says). But it has also been adopted by IT (more capitals) as a way to build other solutions.

Many of us are aware of the large editorial solutions sitting on WordPress, created by companies like Ran.ge and 10up. But other companies are using WordPress for more than publishing. One example I use often is the use of WordPress for membership sites either for internal or external use.

An Inside Look at Enterprise Organizations

Now before I talk more about WordPress, let’s look for a second inside an enterprise organization. I work for a company that develops enterprise software (some of it desktop software, some of it hosted SaaS). In one of our vertical markets, we have over 50% market share – so we’re not playing at this game. We’re in it to win it.

I say that because I’m not talking about frustrations from a frustrating place. We’re in a good spot. But in that particular market, we sell our software to cities and counties – where they have hundreds, if not thousands of employees.

Rapid Development Iterations

When I joined the company just over seven years ago, I was shocked to hear we were delivering monthly releases. But it was a pendulum swing from when it had taken us too long to get releases out the door. There were a lot of reasons for what was going on, but let me highlight one particular aspect.

We had separated features from releases.

Now, I know, you’re wondering what that means. The idea of a release simply became a bundled set of software we delivered on a specific date. The best way to ensure that date was to only deliver whatever features were ready at that moment – at the time we’d release.

The net effect of this approach was that we’d be able to determine, right before the test or release build, if a feature was ready to be included in the build. Sounds great right? It’s like saying,

“We’ll release no wine until it’s time.”

The benefits go beyond releasing only software that’s really ready. It also allows you to set specific dates. Because you push out whatever is ready for that release. So the date is never missed. What changes is what’s in the release.

The Challenges of Fast Iterations in the Enterprise Sector

And this is where you start seeing the wheels fall off, on so many different levels.

First, it made it a lot easier to do releases. So we did them. First it was quarterly and then it became monthly. Because it was so easy – and because there was always someone who wanted something tucked in right at that moment. Perfect! Stick it in the monthly release.

Second, it made it feel (and this was even happening with quarterly releases) like certain releases weren’t applicable or required. See if you only end up releasing the stuff that’s ready, and the stuff that’s ready doesn’t relate to a customer, then they decide to skip it. In and of itself, that’s a bad consequence. But there are three ancillary problems that arise, which I’ll hit next.

Third, because some clients skipped releases (“oh, that’s an internal engine release, I don’t need that”), the spread of customers on product versions shot thru the roof.

When I joined, we had customers on a spread of releases that was 6 or 7 versions wide (1.x), with even greater variance across dot releases (1.x.y).

Fourth, supporting customers across such a spread was ridiculously difficult. This is software, after all, so there needs to be environments and people have to develop experience on whatever release they’re supporting. So you either specialize (creating spare cycles of bandwidth when no version-specific tickets are coming in for that person), or you have everyone support everything and things slow way down.

Fifth, when clients are skipping releases, their requests for custom software get more complicated because they’re asking for things on various versions of the software – including older versions that don’t have what you need it to (infrastructure).

The Consequences for Add-ons/Plugins

You can imagine, from the experience I’m describing above, and with the final issue articulated above, that custom development (where we create an add-on for a customer, and then release it to other customers) was a serious burden.

This had nothing to do with the fact that we’d unhinged features from release dates. This had to do with the consequence of that fact.

Because the consequence was a greater spread of versions we had to support – as clients opted to not stay on the very latest release. And that wasn’t just because of the unlinking of features to releases, but also the rapid release cycle.

Even when we moved to quarterly releases, corporate change every three months was seen as “too fast” for many of our clients.

So the results were the same – greater client/version spread.

And with that came our largest development challenge. Because when you have clients spread across so many versions, creating add-ons (which in the WordPress world would be plugins) can be prohibitively expensive.

  • Do you only build features for the latest version?
  • Do you build it for whatever version the client is on, because they’re going to pay?
  • Do you build the mother of all add-ons that can work on a 12-version spread?
  • Or do you look for ways to get everyone back on the same release version?

It’s not that tough, look at Chrome & Firefox

By this point, you’re likely thinking that it was just our organization that was hosed. After all, other companies have figured out how to roll out small patches without us even knowing it, right?

You might be thinking I’m talking about Microsoft and their auto-updates, but you’d be wrong, because years of working in the Microsoft server world has taught me better.

Microsoft updates have single-handedly taken servers down and created uptime issues for hosting servers. So clearly I can’t use them as seamless examples of updates that don’t impact users except for positively.

No, the example that we’ve heard talked about is actually Chrome and/or Firefox – web browsers. The idea is that you can keep people updated without them having to stress about it at all.

So let me ask you a simple question – particularly if you have enterprise experience.

When was the last time that happened to a piece of business software (not a browser)?

When was the last time someone updated their company’s accounting software, Microsoft Office, or operating system without any stress?

And this is why the idea that auto-updates will protect the user and keep them updated, like an experience with Chrome is false. Employees that use browsers typically do one thing with them – visit a site. The experience is simple and straightforward: type in a URL (or search term) and hit enter.

Now watch people use Office. They do different things with it. The software isn’t simple. And changing it, in any way at all, worries IT departments.

So guess what? They create implementation projects. They sometimes hire staff to manage what can easily become a multi-year project. All just to upgrade mission-critical software.

We can say they should get used to it. But they’ll look at us and smile. They’re the multi-million dollar companies that don’t play lightly with risk. A single question will stop us from making our argument.

Can you assure me that this next auto-update won’t impact a single plugin’s functionality?

And with that, we get stopped and assigned to the multi-year project plan to upgrade software.

Wait – there’s more: Retraining!

Before you presume I’ve made the case for why I’m worried about how enterprises will react to the most recent WordPress development strategies, let me hit on one I already did this morning on the WPwatercooler show – the cost of retraining.

Let’s first assume the best-case scenario:

  • You’re able to fully articulate exactly what’s going into each release
  • You’re able to assure customers that every release is important
  • You’re then able to get them to agree to update
  • You’ve eliminated spread and everyone is on the latest
  • You’re able to provide excellent support because of it

Ok? You’ve read all of the above and figured out how to move past it. Perfect.

So now you move into the argument I was putting forth this morning, which my friend Jason responded to today in a post.

To fully appreciate it, and to lean on experiences you’ve already had, let’s look again at how people use Microsoft Office.

They create eBooks in PowerPoint. They create tables in Excel. They create agendas, books, research, and letters in Word. And every one of those interactions causes them to touch a different part of the system.

So what happens when you change a part of the system (especially via an auto-update)? Ask around about Microsoft’s “new” ribbon interface. People are still using a version from 2007 in order to get away from change. Or check out how many people are rocking Windows 8? You know the one with the brand new interface.

The problem is one of change – but not just because of all the issues we already looked at. It’s not about fear of change. It’s not about IT planning.

No, in this case, it’s about the cost of retraining.

When you change one thing – one little thing – in an organization of hundreds or thousands, plan on seeing the ripple of that change taking place over years, not weeks or months.

I know this personally.

We wanted to introduce a new navigation bar. That’s it, just a new shortcut menu, at the top of their screen. We left the old menu in place (just called it “classic” and hid it by default).

But before we did it, we did months of demonstrations. When I write months, don’t think 1 or 2 or 3. Think 12 or 14 or 16. And then we made the change. And guess what?

Some customers freaked. Because we made the mistake of training IT departments and did demos for decision-makers. Not end users.

And it was end users that freaked.

Any change at all, and I mean any, can cost an enterprise organization months or years of time in training/retraining. To roll out that little menu took us almost three years (no exaggeration).

Developing WordPress for the Enterprise

If you watch the State of WordPress, the entire logic of the argument sounds wonderful. I know because I’ve seen, heard, and lived it. I thought it was driven by a natural consequence of a release (like 3.6) taking so long, but Nacin assures me it’s not. It’s just that the current approach is too long, according to him.

Additionally, the folks behind the strategy aren’t dumb. They’re looking for ways to accelerate development while mitigating risks – in this case the risks they’re familiar with.

In fact, the driver isn’t separating features from releases, but rather feature development from release schedules – which is a nuance that I hadn’t caught. Will the result be a better approach to the enterprise sector, or will we see the same consequences I’ve seen in the past? I don’t know.

My only assertion is that the approach and message, if not managed, will not work well in an organization that has revenues in the billions instead of millions. In fact, I’ve seen these challenges in companies with only 100 million in revenue but tons of content-producing/application-using staff.

But does it mean that WordPress won’t be able to go into the enterprise space? I don’t think it means that. Does it mean we need to fork the product to do that? I don’t think that either.

Instead, I would make three suggestions to the approach.

Shift from 3 to 4-month cycles

I ‘m making this statement based on the expressed articulation of an October and December upcoming set of releases. That suggests quarterly. And moving to less than quarterly is a good thing. This doesn’t completely reduce the stress to IT organizations, but it drops one of the releases. And that helps.

If you have 3 releases a year, make them focused on Performance, Programming (API) and Presentation respectively.

It’s easy to share with an enterprise client the predictable nature of yearly cycles on all three of these fronts. Additionally, these are well-understood development themes. And themes are organizing containers that companies can easily embrace and share with one another (on a business level). Lastly, if they decide to skip one, it shouldn’t have impact on the others.

Limit how plugins impact the admin GUI

There’s already a trend for themes to push their GUI for theme options into a single place. That brings pure joy to my heart – even if some vendors have yet to support the movement. But we need more of that. I’m not talking about limiting a plugin’s ability to change/skin the Admin GUI itself. We need to keep up what we’ve started there.

My suggestion is to do the same for plugin options. Why have them all over the place? Initially I thought that’s what “settings” was for. But even if we need something else, let’s create a single, unified approach and have plugin developers directed to place options there – because it will seriously limit the amount of re-taining that goes on as everyone does more plugin-based development.

Wrapping Up

I told you it would be a long post, didn’t I?

So how did our story end? After seven years we’re in a radically different place. We no longer have support techs that focus on a particular version. But that’s because we no longer have such a wide spread – we’re down to a 2 version spread. And we’re down to two releases a year – themed, of course.

This helps us in communicating with customers. It also helps us when it comes to product planning. And ultimately, we’ve married features back to releases. Maybe it’s a pendulum swing, but it’s more profitable.

We won’t see WordPress’s development schedule move to two a year. I know that. But what I understand is that the next two releases (the platform stuff) will set things up so that we can take WordPress into the enterprise sector better than ever before. That’s the hope and expressed intention.

As you know, I love WordPress. I love that hosting companies, development shops, and Automattic are all looking at how to take WordPress into the enterprise space. I’m sure it will all work itself out – so this isn’t a doom and gloom post. It’s just one guy’s opinion with three (I hope) reasonable suggestions to help us move forward as we think about a certain set of customers.

About This Site

This site is hosted by Pagely - running on Amazon's hardware, making it lightning fast. They're a managed WordPress host which means they take care of my site so I don't have to. Starting at $24/month, this may be the perfect solution for you too.

23 comments

  1. Mario Peshev says:

    Monthly releases are really frightening. I just had a very similar post published earlier today and I have been concerned about applications and enterprise solutions in particular.

    I have contributed to several large platforms/applications based on WordPress over the past 3 years – multisites with tens of thousands of websites, large traffic, server clustering and extra effort in performance/fine tuning. None of the websites is running the latest major WordPress version even with the existing release schedule. To be able to properly test every combination of a theme and plugins for tens of thousands of websites, to replicate it locally and migrate without causing downtime and regressions takes incredible amount of time.

    I would be surprised if the minds behind WordPress (Matt, lead developers etc.) are advocating against using WordPress for applications. It’s not the right tool for every job (or the Swiss Army Knife) but it’s mature enough to handle and scale for large projects and is a good investment in the future. Given the “release schedule” statement I practically see only 2 possible solutions:
    1) Releases are so short that nothing could actually happen, new features can’t be completed, they are delayed over various versions and it’s just the same as it is now, or 2) the WordPress Core is getting planned for decoupling and decomposition of the modules, so that a separate Enterprise version could exist similarly to the Red Hat stack or the way Drupal operated many years ago.

    • Ross McKay says:

      +1 for the Red Hat / Fedora approach, if trying to address the Enterprise market and maintain a fast release schedule. Enterprise wants stability first, functionality second — it can work around functionality gaps but it can’t work around instability. Knowing that new stuff is coming and letting them play with it in rollout projects is good, forcing them to choose between a June or a July release is bad because Enterprises just don’t move that quickly.

  2. Dave Bell says:

    Very well spoken. Being in Windows training for 20 years, I know plenty who are using XP. And none who want to move to Win 8.The Metro thing scares me. And I have been using Windows since 2.x. I use it because I have Start8. And if not for that, I wold be using Win 7.

    The whole upgrade cycle thing is very tricky and you have eloquently spoken of some of the more subtle issues.

    I love WordPress and I am probably at the polar opposite of your experience, knowledge and skill. But I love the heck out of it. And I think they will figure a way. As a user, I have only one wish. Do as many updates as you like, but do NOT let them break my sites when I upgrade. Simple. One unbreakable rule. If they get that right, I am very happy. And so are my clients.

  3. Similar to Dave Bell’s comment, I think people who don’t experience how difficult it is to change people’s behavior for new releases don’t realize how difficult it actually is. Any UI change, and probably most process changes (where things work differently, though you may have the same UI) requires a lot of background work in the enterprise that’s hard (not complicated, just hard).

    For example, anything that references the old way – manuals, video training, operations manuals… all needs to be (found and) updated.

    There’s also the whole “is this change OK to move to production?” process.

    I wish there were a better way.

    David

    • Yeah, definitely. I worked at Accenture out of college and my first task there was to update the header in about 200 Word and Excel documents because the project had updated its logo.

      I was able to write a script to do it for me (go me!), but other changes aren’t so easy.

  4. Thanks for posting your full argument here and including actionable suggestions.

    Enterprise is different, and I don’t think the core team has as much experience there as others in the community, like yourself. So as WP progresses as a platform, voices like yours need to be heard.

    One thing we haven’t really addressed yet is that the WP drivers need to be more specific about who their target “customer” really is and if WP as a platform means WP as a platform for enterprise or WP as a platform for someone else.

    Your suggestion to “Limit how plugins impact the admin GUI” could be done in a plugin I think. (Us problem solvers can’t see a problem without trying to solve it.) WP saves the dashboard menu in a global $submenu. We could loop through this and place all non standard menus into another menu or space in the dashboard. There might a plugin that does this already.

    • RE that admin menu plugin thingy: it would be fun but not really address the issue. I think if you are installing WP in an enterprise situation, you need to take some time to customize the admin menu and experience for them and should be hiding/moving/showing things exactly how you want them.

      • chrislema says:

        I agree 100%, but that won’t protect you from a plugin doing things later, post an auto-update. Sorry I wasn’t more clear about the specific challenge.

  5. Kristin says:

    Chris, thank you for this. I hope everyone reads it.

    “So my perspective on this year’s State of WordPress address comes because of the filter I have of hearing things in the context of the enterprise.”

    Your statement that your experiences color your perspective might just be the most important concept for everyone in WordPress to understand right now. Everyone’s background provides a filter and WordPress’s future is going to depend on input being accepted from all those perspectives.

    My filter is small businesses. While we can’t quote the big numbers you can, I too fear the idea of faster update cycles. I’d been hoping for a longer cycle than we have now. The negative impact on my business and my clients is very real to us. Time spent updating, troubleshooting, retraining and just stressing out is seen as time wasted by my clients which means it doesn’t provide what they see as value. We all know what that means.

    I hope this is the start of a conversation that continues and results in more real involvement in decision making by people from the business sector.

  6. Patrick Daly says:

    Well said. I’m also in an enterprise environment — a financial institution at that. We’re seriously considering using WordPress as our primary CMS which is no small feat for a company willing to pay millions of dollars for a CMS.

    For us, the re-trainability would be a small issue, if any. We don’t have clients or that many content creators.

    Instead, our issue would a rapid WordPress release cycle would be in testing and compliance. We’re held to strict standards which would have to be re-evaluated with each release (forget about automatic updates).

    I’m torn though, because I want WordPress to work in the enterprise so badly. At the same time, it’s massively popular because it’s consumers are individuals and small businesses. Maybe both/all audiences can be served at the same time … particularly if WordPress is simply the platform and plugins are the features as development may seem to move toward.

  7. We are contemplating the impact of moving our application from Flash over to WordPress and were intrigued to hear that 7% of the WP installed base is using it to build applications. I have been hunting to find people to talk to (in the 7%) – would love to find a list somewhere or a Forum where migration TO the WP platform is being discussed. Ideally, it would included business people and technologists. Thanks

  8. Matt says:

    I strongly disagree with one of your premises, that it’s easy to update web browsers because they’re “just used for visiting web pages” where something like Office is used for “real stuff” that’s hard.

    BS. A browser is more akin to an operating system: it has to parse and run applications every bit as complex as Office on the fly, from Google Docs to Zoho to Outlook.com/Gmail/Yahoo Mail. What’s more they have to work even when the code is broken, as you can see by the hundreds of thousands of edge cases they correctly display when a quote, closing tag, or other aspect of the page is missing. Log in and visit the homepage of Facebook, WordPress.com, or any other major web property and you’re getting anywhere from 2-10mb (uncompressed) of code that has to be executed.

    And to top it all off, this random code you’re running from around the internet is sometimes hostile. It’s actually inspiring from an engineering perspective to see Chrome sandbox exploits because they’re often a chain of 13 different small bugs that have to be combined to break out.

    And if they can do it we can do it — it’s just code. :)

    • chrislema says:

      Thanks for stopping by and commenting.

      My point wasn’t about the complexity of the code, though I disagree with the idea that a browser is like an OS.

      My point was about the complexity of the use cases. The behavior ‘spread’ in a browser is limited (regardless of what the code may or may not be doing). In Office the same isn’t true.

      This results in wildly different consequences when changes are made that impact the user interface. And when the cost of those consequences is high, corporations don’t want auto-anything.

      • Matt says:

        An OS is a browser with drivers.

        I would argue the spread of what people do with and use browsers for is much higher if for no other reason than the user numbers (billions) times possible targets (web sites and applications).

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>