So.. After reading this, I began wondering if the company I work for does or doesn't fit under the umbrella in the article.
I work for a company that creates online digital "newsrooms". Basically, CMS on steroids. We handle everything for a company that needs to publish their PR content in a way that doesn't make journalists cringe and run screaming. I'm talking about Press Kits, Releases, Photos, Videos, "Baskets" or "bundles" of the above, being able to e-mail the bundles out to other press people, very complex embargoes on content (so releases expire or do not even show up before a certain time), very complex permissions and very complex subscription management systems, etc...
All of the above is... well... complex. The company found they were re-writing the system over and over with each new client, or worse, copying code from the old client.
So they created a system of plug-in-able modules of sorts. When a new newsroom wanted video stuff, we plugin VideoManagement, and all the requisite features get shoved into the new client's app. When a client application that uses video management finds a bug, it is fixed, and pushed out to every other client site that is actively maintained, and they get the fix too.
On top of this, though, the client applications are able to be customized with new layouts and such. Always a bit of a pain, but it's still capable of being customized fairly easily.
So is the company I work for wrong for doing that? We don't have any real clients other than these types. We've found a niche, and have found plenty of business within that niche. Does it not make sense in this case?
I ask here because I'm unsure of whether or not I feel like the company I work for is the exception simply because I work for it.
I think that's real application evolution at work: You have new projects and new requirements all the time, but they're _similar_ projects. It is natural to gradually build out a framework of reuse. That's different from the "the entire business should have uniform software" misconception described in the article. There, the owners are grabbing for an efficiency that simply isn't present in that situation.
"we often forget that the consequence of unnecessary duplication is far less than the consequence of unnecessary consolidation."
I don't know that I agree with this. Unnecessary consolidation is bad, but I find that it's more of an effect of that consolidation being poorly thought out.
Then maybe just a set of common libraries is a better way out... There's just a problem of a difference between a common "authentication library", "unified storage library", "messaging library", ... and a global clusterfuck with more inter-dependencies than your brain neurons have.
If you can keep them separate, they don't become a required framework for everything - but changing anything in one of them still requires retesting a lot of applications that could've been affected. Keeping the libraries as simple as possible (maybe even as separate language-independent rpc services if it's only for internal usage) could be a solution.
As someone who currently works for Corporate IT, I totally share that pain, especially about the inner-platform.
Our current UberMegaProgram is very customizable. When you want to add a new product, you add the fields the product will have (so far so good), and then, there is something called "operations"... which is basically Assembler re-invented. You move data to some registers, do some basic operations... and you're expected to do all the math and validation in that (which is, of course, un-debug-able). I HATE it but since we paid 800000 dollars for it, it's not going away soon.
I am not entirely sure. Is the difference between: (1) a number of reusable modules/components (I am thinking of, say, maven artifacts in a private repository, something along a private CPAN) and (2) the evil Uber-Application that:
in (1) you take several modules out of the sea of modules you have and integrate them into the software you create for the customers needs (potentially adapting or refining the modules)
while in (2) you rather try to bend a single application and the customers will in a way such that they eventually meet somewhere, forming some sort of application which sort of meets the customers requirements?
As well as making the developer's life a misery, the ÜberApplication can mean a slow death for your company as you can't sell components separately - it's all or nothing.
I work for a company that creates online digital "newsrooms". Basically, CMS on steroids. We handle everything for a company that needs to publish their PR content in a way that doesn't make journalists cringe and run screaming. I'm talking about Press Kits, Releases, Photos, Videos, "Baskets" or "bundles" of the above, being able to e-mail the bundles out to other press people, very complex embargoes on content (so releases expire or do not even show up before a certain time), very complex permissions and very complex subscription management systems, etc...
All of the above is... well... complex. The company found they were re-writing the system over and over with each new client, or worse, copying code from the old client.
So they created a system of plug-in-able modules of sorts. When a new newsroom wanted video stuff, we plugin VideoManagement, and all the requisite features get shoved into the new client's app. When a client application that uses video management finds a bug, it is fixed, and pushed out to every other client site that is actively maintained, and they get the fix too.
On top of this, though, the client applications are able to be customized with new layouts and such. Always a bit of a pain, but it's still capable of being customized fairly easily.
So is the company I work for wrong for doing that? We don't have any real clients other than these types. We've found a niche, and have found plenty of business within that niche. Does it not make sense in this case?
I ask here because I'm unsure of whether or not I feel like the company I work for is the exception simply because I work for it.
Thoughts?