This is a guest post from Chris Lema, the VP of Software Engineering at Emphasys Software, where he manages high performers and oversees product development and innovation. He’s also ablogger, and an e-book author
WordPress is sneaking into the Enterprise
With WordPress powering over 17% of the Internet, it’s no surprise that it’s showing up inside corporations. And when WordPress does show up, is it any surprise that it can just as easily be proposed to management by business analysts as by software developers? If you’re a student of software development and IT, it shouldn’t be. Here’s why. seo hizmeti
WordPress is nothing new
Remember when developers were busy on corporate IT projects while business analysts were using Microsoft Access to solve day-to-day problems? Just a few years later, those same analysts were creating Excel spreadsheets and using VBA to build their solutions. And a few years later, the BA’s wouldn’t wait for IT to get around to their projects, so they started using other tools like IronSpeed. As technology has grown more and more accessible, it has simultaneously freed up the enterprise to operate more efficiently, and it was only a matter of time until your corporate IT team wasn’t quite as essential to get your website built.
Non-Programmers love “hacking” too
I’ve been managing software development in and for corporate enterprises for almost two decades. In that time, I’ve seen the same pattern over and over. The VP of Sales or the VP of Marketing has an idea, a new initiative. They take it to the IT department who has no bandwidth for these “little” projects. And then some young, enterprising employee who is a non-programmer pulls a MacGyver – the decide they are going to make the project happen, and find the tools they understand how to work with, figure out what they can’t, and develop a solution. Minoxil
There are constraints, but that’s part of the beauty
WordPress is amazing, but it has certain constraints that make it appropriate for marketing. It’s great strengths are also weaknesses in certain instances. WordPress isn’t typically hosted on official infrastructure, which limits what content you can publish on it. WordPress often hasn’t been vetted and approved by a committee and/or the chief software architect. Of course, this is part of the benefit. It means that you can implement the WordPress install without 8 months of approvals! It’s a solution that works, and works quickly. And because it works, it gets deployed, and your marketing department can manage the project, and control the message, soup to nuts.
WordPress isn’t only for blogs anymore
But isn’t WordPress only for blogs? Well, no. WordPress is a full-scale application framework. With thousands of themes, and 23 thousand plugins, you can expand WordPress to accomplish almost any goal for your enterprise – including an internal social network with BuddyPress.
So let’s say that VP of Marketing has an idea to build a new online community, but can’t get any traction with corporate IT. What do they do? Well today they can find someone with technical skills on their team, hand them a WordPress site (probably on a managed hosting platform) and then point them to any of the following three WordPress plugins that offer the ability to build an app without any programming.
1. Toolset – Build complete WordPress sites without coding
Initially they released Types & Views. Their Types module focuses on creating custom post types and meta boxes – expanding WordPress functionality without programming. Their Views module focused on displaying the data saved in those custom post types. But then they went further – creating a simple way for end users to add content via front-end forms. So CRED offers a database-like form interface that can collect any data at all. And Access determines who can access which screens.
In the paradigm of an architect, and construction crew, the team behind Toolset decided to eliminate the construction crew. Now even a marketing intern can step into the role of the architect and build an entire application without ever writing a line of code. All with one Toolset.
2. Pods Framework
Another option for that marketing intern is always the Pods Framework. It’s another way to build an application without coding. While Toolset delivers a lot of it’s power on the front end display, Pods spends equal time on the infrastructure. Think of Toolset as a product that really focuses on the facade of your construction while Pods spends more time on plumbing. You don’t need them both, but picking one is based on where you plan to do the most construction.
Last September or October, the same video was passed to me several times in a single day. It was the video of a demonstration of Piklist. And once you see it, you’ll realize why it was getting passed around. Again, this is another solution that lets everyday users create something more than a blog with WordPress. In our construction metaphor, our marketing intern still gets every right to choose their own tools, and Piklist provides them another option.
Should you use WordPress as an Application Framework?
I understand the debate that currently revolves around whether WordPress should be an application framework. Many “serious” engineers will highlight all the reasons why you should use something else than WordPress as your app engine. But while the engineers are debating the merits of WordPress for applications, savvy organizations skipped the debate and moved on to actually building applications on top of WordPress. Because it was easy. Because it was free. Because it was there and it was possible. Because they had too much to accomplish to wait around in committee.
The first time I used WordPress inside our corporation was a few years ago. Amusingly, at the time, I was both in charge of marketing and in charge of development. But like I’ve mentioned, my dev team was too busy to work on this internal initiative. Rather than abandon the project, I introduced WordPress to our organization.
The project was an innovation contest, which we were able to develop fully within the WordPress framework. The contest had three rounds, which became WordPress Categories. In each round contest entrants could submit a response with a WordPress Post to a prompt, which was part of the WordPress Category page template. Then, the Posts were voted on with the GD Star Rating plugin. Only the high scorers moved forward into the next round.
What could have been a .NET application that our dev team might have spent days on was instead a WordPress solution that was up in less than two hours.
Beyond having a great experience in our innovation contest, many users asked about WordPress and we ended up transitionung to our using WordPress for many things including our corporate extranets (4), knowledgebases (4), support solutions (1), and even a full-blown real estate product.
WordPress isn’t only for blogs anymore
As the Vice President of Emphasys Software, a 35-year old company that specializes in enterprise software products, and as an advisor of technology startups, I’ve seen and used WordPress as an application framework across dozens of projects for years. I choose to use WordPress for our enterprise projects for a variety of reasons. But I can distill it down to three. I use WordPress because it is easy. Because it is free. Because it is there and it makes amazing things possible.
Chris Lema is the VP of Software Engineering at Emphasys Software, where he manages high performers and oversees product development and innovation. He’s also a blogger (chrislema.com), ebook author (amazon.com/author/lema) and runs a WordPress meetup in North County San Diego (meetup.com/WordPress-San-Diego/).
A 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 Nacinassures 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.
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.