Are We Doing it Wrong?
Tim Bray has a very interesting post on enterprise development – check out the comments. I’ve said something like this there too, but like to elaborate a bit:
I strongly believe that building your own software is an essential ingredient for a successful, information-centric company such as a bank, an insurance company, or even a telco. I think it’s an excellent idea to use commodity services in all areas where you don’t have, nor want to have, any competitive advantages. But you should build something on your own if you want to innovate.
I also wrote that while it’s pretty fashionable to deride the claims that enterprise software is “inherently more complex” than much of the Web stuff, it is in fact true sometimes. One of the reasons is the absurd complexity of laws in some countries, and the rate in which more and more complexity is added to them. If you’re in a regulated business, this tends to create a huge amount of complexity you simply can’t escape from (unless you change the laws, or rather the whole legislative and political process, of course).
Another source of complexity is the business side, coming up with more and more complex product requirements. In many Web companies, there’s no difference between the business and technology decision makers – perfect “business/IT alignment”. This simply isn’t true in most large businesses. As a tech person, you have a choice of quitting or adapting to it …
I still agree that many of the practices, technologies and tools used on the Web can be put to excellent use within the enterprise. But even if you are given free choice of weapons in terms of tools and methodology, the typical constraints can ruin your day pretty soon.
Anyway, while I see some issues with Tim’s post, I still think there’s a lot of truth in it. Given that I spend most of my time in enterprise contexts, I strongly believe putting more of the Web into the enterprise is an excellent idea.
The key is defining a given company’s core competence.
For co’s in heavily regulated markets, part of their core competence should include operating efficiently within that complex environment - for such companies this will most likely exclude commodity SaaS, but not necessarily commodity platforms or infrastructure, or open standards, development frameworks, etc. where abouts in the ‘cloud stack’ or open technologies they can draw from should be evaluated in this full context.
The picture isn’t rosy in web/tech companies too. When there are business requirements, those sometimes tend to reflect the most vocal blogger of the day.
This discussion on Enterprise Software Complexity reminds me of this interesting paper from 2007:
http://sloanreview.mit.edu/the-magazine/articles/2007/fall/49101/the-trouble-with-enterprise-software/ http://www.communitech-solutions.com/Resources/The%20Problem%20with%20Enterprise%20Software.pdf
Interesting to read about what was the solution to simplify things back then :-)
Having recently worked with an insurance company to help them build their own software, I walked away with the opposite conclusion - only the largest players in each market should be building their own software. I don’t believe enterprise software is inherently orders of magnitude more difficult than web software, but I do believe that the vast majority of enterprises are ill equipped to build their own wares.
A small or medium sized insurance company is not going to hire the best software developers. They will hire reasonably skilled personnel, and oversee them with a large bureaucratic management body. The software they develop will be designed by committee and lacking in usability and polish.
I’ve seen then happen so frequently that I’m convinced it takes a near miracle to avoid.
My current thinking is that small and medium sized players are best served using a combination of off-the-shelf software and small to medium sized vendors who develop (and possibly even operate) software for them. It’s lower cost and faster to market, but also results in higher quality products.
With respect to heavily regulated industries, you’re right that regulations make straightforward development difficult, but that’s actually the intention of the largest regulated companies. I’ve worked in telecom, and I’ve seen the PUC meetings where this crap is cooked up. Once upon a time it was motivated by killing the CLECs and creating boondoggles like USF, but they’ve done it so long now they don’t know how to do it differently. That doesn’t make building or maintaining the systems very pleasant.
That said, it isn’t always the case that complicated rules dictate custom development. For example, if you sell taxable products or services in numerous USA jurisdictions, you really need to get Vertex, and forget about hiring a 20-head tax compliance department, plus five developers for them to harangue. Your server admin spends ten minutes a month installing the rate update, your shopping cart calls the Vertex library, and you concentrate on your business. Unless your core business is manipulating the regulatory apparatus (don’t laugh, this is certainly the case in telecom!), you might be very well served to let experts do your regulatory compliance for you.
With respect to committee design, Parand, I think it’s only certain well-run software-selling companies that avoid that pitfall. It seems universal in other industries.
@parand: In my experience, the alternative to building custom software is to use an off-the-shelf package requiring a customization effort that’s at least equal to, and sometimes exceeds the cost of building the custom solution.
I do agree regarding the problems with (some, not all) in-house staff – in fact, a company like mine makes money with large enterprise customers for precisely this reason.
Great discussion! Is this not where the whole concept and “spirit” of open source should come into play? Perhaps I am just naive and optimistic, but the sooner inudstry realises that open source (I do not mean products here, but the concept) is the way to go, the sooner we will move along faster.
I wasted weeks of time last year evaluating ECM systems for our customer needs and my final result is: It is similar everywhere. For getting real efficient and most benefit for business needs from the actual point of view, you must develop something new.
Even the bigger Open Source systems have been designed around 2004 and earlier. Other commercial systems have their roots even before 2000 and are grown huge and are inefficient. SAP is another good example. I don’t know any single user who likes it.