Enterprise Software and clean API’s

I find myself often hitting the “indignant” stage when dealing with enterprise software. Typically, this is dealing with software that titles itself “Enterprise” software. To me, that usually means one of three things:

1) it’s software that might have once had a nice core and has been overloaded with features to the point that it’s now a bloated piece of shit that barely does what is really needed and is nearly impossible to use.

2) it’s software that was some architecture astronaut’s piece of work that was never really implemented in any real world scenario. It likely never will hit a core real-world scenario because it provides a sound foundation for charging exorbitant fees for “consulting work” to make the product fit for your environment.

3) it’s software that’s sole purpose is to appease the regulatory and/or control issues, or even just various C-level executive fears. This kind is often associated with our arcane legal and/or accounting systems that corporations have to use.

When I hear enterprise software I also think of year (or more) long sales cycles, design by committee, undocumented API’s, and software that’s so devilishly complex to install, run, and maintain that most system administrators fear interacting with the systems they’re supposed to be supporting.

There is a lot out there that could be so much better…

Of course my first thought as an engineer at heart is something along the lines of “That stuff is complete crap – I could build that so much better…”. I don’t even, for a second, doubt it. My realism/”I have limited time” hat comes into play pretty fast and I realize that while I could, I’d never be able to get other things done if I was doing that. There’s only so much time in the day after all.

I’m looking at future purchases of exactly enterprise software. As I’m looking, I’ve got my core needs and goals, a pile of nice to haves, and a view towards processes that we’ll either need to modify or switch the software to match in some fashion. What I’m also starting to look for are touch points and API’s. My team are the ones with the knowledge of the environment – not some contractor-ware shop. What we need are the touch points to integrate with a bunch of heterogeneous systems.

We, as customers of enterprise software, need to make sure we’re getting clean, well-defined, and supported API’s with these products. Go ahead and beat the enterprise sales executives with the “SOA” ugly stick – demand API’s, demand ways to get data in and out of their product. Wether it’s java, a SOAP web service, REST, or a something else – we’ve got to have a handle to work the system, report data out of it, coordinate with other systems.

Being able to integrate, or even whole encapsulate, an enterprise product into your environment is critical. It is the only way we’ll be able to continue the track of automated systems. It’s also the path to avoid getting locked in to someone’s proprietary enterprise system.