What If Enterprise Software Were Produced?

By Jake • August 30th, 2011 • 8 Comments

I don’t know very much about game development. Very little. I know a lot about enterprise software development. A metric ton.

I wonder what would happen if enterprise software development took more cues from game development.

The two aren’t really that different. You have users/players. Ostensibly, you want them to use the software/play the game. Your users/players have categories of things to accomplish, e.g. they want to process transactions, play a first-person shooter. You have developers writing code. You have QA, release, documentation, marketing, all of that.

I guess the biggest differences are the economics involved with the sale and the purchasers, but even so, the development process is really quite similar.

One thing I first noticed at SXSW in 2010 and subsequently in game development posts I’ve read since then is that game development is referred to as production. I assume this is a reference to the development of entertainment, e.g. a TV show or a movie. In enterprise software, we don’t call it that.

I further assume that this subtle word choice underlines the fact that work and play have always been separated. So, enterprise software is developed, not produced, because it is not entertainment. This post isn’t about making work fun, but yeah, I think that idea has legs too.

One thing about producing a game is that the gamer/player is the focus and is studied in minute detail, since this target customer is the intended buyer. Not so much in enterprise software, where IT departments make purchases on behalf of their users, and differences in business practices, legal and statutory requirements and other factors create complications around seemingly simple use cases like processing invoices.

Is it possible to build software for the masses of enterprise users when they themselves have little say-so in the purchase?

I’ve no idea, but I wonder if there aren’t some important cues enterprise software could take from game development.

Plus, it would be cool to have a producer title.

Find the comments.


Possibly Related Posts

  • http://empoprise-bi.blogspot.com/ John E. Bredehoft (Empoprises)

    There are apples, and there are oranges. My company produces enterprise software, but our target market consists of a few hundred government agencies with perhaps a few thousand users (many of whom do not influence the purchase decision for the reasons you cited above). 

    Correct me if I’m wrong, but the AppsLab creates software that can potentially be employed by thousands of users, and these users all have some kind of say in what the software does (although some users have more say than others). Because your enterprise software is produced for a private company, you don’t have to pay as much attention to the regulatory environment as we do (every once in a while I’m forced to draft an explanation of why we should not be forced to allow blind people to use our software to compare fingerprint images).

    And that’s just two examples. There are enough differences in enterprise software that I suspect that it’s hard to generalize. I consider Microsoft Office to be enterprise software, and I can see how Microsoft may be inclined to “produce” this software package. In our case, we’re more likely to “develop” it.

  • http://blogs.oracle.com/userassistance/ uvox

    Increasingly though, enterprise app purchasers do focus on the user aspect, some companies even running their own usability tests. As for games in enterprise apps, for sure, game dynamics and mechanics have a key role to play in solving user problems in the workplace: http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/24663

    Successful software development must involve the users. The concept of “user” though, to an IT department, varies (i.e., it’s them – wrong).

    There are legal and regulatory aspects to game development too – for example, what you cannot show in wargaming in Germany and the use of virtual currency (which can be exchanged for the real thing) makes the US Treasury very nervous.

    Still, interesting area. We (Apps-UX) are active in the gamification space too. 

  • http://theappslab.com Jake

    I’m not really talking about gamification, although we (Paul initially) have been pushing the importance of adding fun to work. I think Paul’s thoughts predate the term “gamification”, and I have initial designs and spec for an engine we nearly built back in early 2009.

    I’m talking about the production, which I think is the key difference to building software people want to use. It’s about writing scripts, not specs. Yes, we have moved in that direction, but I think it’s too slow. Just changing the title from product manager to producer would initiate a mindset change.

  • http://theappslab.com Jake

    Agreed, the more people you build for, the more the process is complicated. Many more people use Word than play Warcraft. Another value to game production is independence from other productions, which is one that enterprise software cannot follow, i.e. you don’t upgrade games.

    Despite the differences, following a production model would help a lot of traditional waterfall projects. Agile is great, but it’s very tough to turn a waterfall team into an agile one. Production is more of a pivot, fewer major role changes.

  • http://empoprise-bi.blogspot.com/ John E. Bredehoft (Empoprises)

    “Independence from other productions” may change. Zynga already has a property called “Rewardville” which allows you to earn rewards for other Zynga games. And imagine the cross-game power that would occur if items from one game could be carried over into another – for example, if raw materials from Farmville could be carried over to make dishes in Cafe World. This offers the potential for some very compelling gameplay (and some revenue opportunities for Zynga) – but at the same time, it would require some very complex coding, interface, and compatibility solutions.

  • http://theappslab.com Jake

    I wasn’t clear enough. I meant backward compatibility. Players play the newest version online, and in shrink-wrap games, they start over w each new version. So, each production starts relatively fresh.

  • http://www.garry.to joel garry

    This morning I heard an interview on the radio with the ceo of whatever big game is being introduced today.  He said they actually have two teams.  They release a new game every year, and then that team takes two years to build the next version +1.

    They also talked about the big release, where they built a meatworld replica of the game in the building where the Spruce Goose was built, and were going to have a big paintball game there.  They were also to have a Jeep sponsored ride-along, with things blowing up while a soldier drives you through.  The elementary school I went to looked down on those buildings, and we kids used to play army in the canyons there. http://www.seattlepi.com/news/article/Call-of-Duty-convention-kicks-off-in-Los-Angeles-2152595.php

    Kind of like a small-scale Oracle OpenWorld.

  • http://theappslab.com Jake

    Wow, that sounds fun. I get the general impression that the intended consumers play a larger role, as with other entertainment productions. This could be due to heavier competition in the space. It’s also easier to create incentives to get people to give feedback, e.g. see a free screening, play a new game, etc.