Sometimes I like to write code, and I am a firm believer in the idea that, as well having a satisfactory and acceptable solution to the problem, production code is not completed until there is nothing further that can be taken away. While of course still having a code base that is tested in an automatic fashion, and agreed by it's stake holders to be highly maintainable. What's the simplest thing that could possibly work?
The story is different in an enterprise that buys in software solutions, from companies that I like to refer to sometimes as Big Iron Software Vendors.
Big Iron Software Vendors are sales and, sometimes, consultancy driven. They are often driven by repeat sales, and, perhaps, after sales support. It's easier to sell to an existing customer than a new one, especially where the CFO's play golf together.
In order to make a sale, these Big Iron Software Vendors provide solutions to problems. It is in their best interests to show their customers that the problems, while highly complex, can be fixed by buying their software. In order to make their software marketable to many different customers, each product that the vendor sells often solves far more problems than any individual customer has. Thus it requires consultancy and integration work to make it fit the customers unique problems, and unique existing infrastructure.
The end result is that often, even while the immediate problem is fixed, new, and #better# complexity is introduced.
This may fix an immediate problem for the customer, but creates a virtuous cycle for the vendor that is not in the purchasers best interests. Their customers’ problems will change, and thus, in the future, they will need further help from the vendor, to fix different complex problems - which of course, include the previous vendor-led solutions.
You know, I don't think I produce better looking documents in Word 2007 than I did 10 or 11 years ago. And I probably publish them as PDF anyway.
Big Iron Software Vendors are not motivated to help their customers simplify their problems, and introduce the smallest possible solution that solves only the problem at hand. For all their talk, they are motivated to make as many sales (of consultancy, support, and licensing) as possible. Within the open source world in which we now live, where many free-to-install, community supported, and mature products exist to solve well known problems, vendors are forced to find another tack, and this seems to be the world for Business Process Management and Service Oriented Architectures, and in the Telco world, IMS and SDP - whatever that means, and I have some thoughts on that for later.
While enterprises are starting to wake up to this issue, in startup-land (and yes, I include Google and Amazon) the use of Big Iron software products to build out solutions is small and decreasing. I've been learning from these guys, and want to ensure in future that the enterprise architectures I provide to my stake holders are as simple as possible, while providing the right features at the right time, and not reliant on complex vendor products, except where absolutely necessary.
There are always new products, and sometimes complex vendor led solutions provide a fit. But I'm sure, that within the long term, the successful businesses that rely on software for day to day operations and competitive excellence will be the ones who remove the cost and reliance on licensed software. Otherwise they'll just have to factor it in to the cost of their own products.
What software license costs would you like to refactor out of your architecture? Or am I wrong, and should we keep drinking the Kool-Aid? Or should we just start thinking of Big Iron Software Vendors in the same way we think of outsourced development shops, and tell them what to build instead?