I’m an ‘enterprise’ developer, this means I work for a company which spends an obscene amount of money on its hardware and software. For people working outside the ‘enterprise’ world this may seem an interesting question, why exactly is so much money spent on development for these big companies?
Some may think it’s the ‘scale’ of the problem, but most of that is very well understood. Just add a little caching here, a few indexes there and you can meet your ‘non-functional’ requirements. Besides, it’s mostly an operational cost anyway, not really something which adds significant development overhead. Some vendors are one part of the problem, from their perspective, the more complex a solution, the better. Remember, IBM didn’t make $46,213,000,000.00 in consulting revenue by selling software that’s easy to install.
But besides the scale and the bad vendors, what is it that makes enterprise development so expensive?
I’ve come to the realisation that a major source of the pain is the crazy requirements, not only from ‘the business’ but also those IT imposes on itself. Take a nice, simple application like Tadalist. Simple, sharable todo lists. Even if you don’t like the application you can at least realise that it’s a simple but functional appliation. I present:
Tadalist Enterprise Edition
“We want an application to maintain and share todo lists amongst our users”
However, enterprise applications never stop there. You have to consult with every business unit in the company, gather their requirements and design a system which solves them all.
Visiting Finance.
“Financial lists need to be clicked twice in order to be marked ‘complete’, and one user can’t click more than 40 items per day”
Great, instead of a boolean checked attribute, we now have to store a collection of Approvals and the User who approved them. Also, when adding a todo list we need to ask if they’re creating a list about finance. Finance lists need some kind of special behaviour for completion.
Visiting Risk and Compliance
“After you complete a Compliance item it must automatically get copied to the Risk Review list. Only people from Risk & compliance can complete items on the Risk Review list.”
Ok, so instead of having an financeRelated attribute or using polymorphism, we’re now assigning some kind of ListType to our TodoLists and driving the custom behaviour off that. We’re also keeping track of the ‘type’ of user we’re dealing with, perhaps we could use roles or maybe a worksForRisk attribute… Just as we’re about to leave the room, the compliance manager says:
“Regular employees can only finish one compliance item each day.”
Roles it is.
Back to IT
Next we go and speak with the ‘Lead Enterprise Data Custodian’, this guy’s one of us. He’ll have a nice simple set of requirements
“We already have a table in DB2/390 (XY_CRAZYSHIT) for storing the values an ‘event’s ‘status’ can take. We use this table throughout the company, you must use it too. Your values are TODOLIST_NONCMPLET and TODOLIST_NTINCMPLETE.”
Ok, that sucks.
“We have another table on the oracle servers (KJ_USRSVCS) which stores the different roles a User can have, you’ll have to use that”
Ok, two different databases. That sucks even more. This is looking messy, perhaps there is some kind of simple service available to list these roles so we can just plug in to it. Off to see the ‘Principle Enterprise Technologist’
“We don’t have any shared services for accessing the user services”
Bummer, two database connections it is.
“However, applications aren’t allowed to connect to two databases, so you’ll need to build the shared service as part of your project. WS-I compliant SOAP services are our standard.”
OK, so our simple shared todo lists project now includes EAI development, installing and maintaining web services infrastructure.
Conclusion
Our simple, sharable todolists have grown into a hugely complicated system of rules, policies and IT ‘standards’. What was going to be a few months work is now a multi million dollar project, thanks to the business units and IT. That’s where the money goes.
All this leads me to the conclusion that “Enterprise Software” is a polite way of saying shitty legacy systems and overly complex requirements. The resulting systems are horrible to use cost too much to maintain.