13 years I’ve been dealing with large platforms in multi-countries and territories. At the start of each project we say to ourselves how can we do it differently, how can we be more lean, more agile, more flexible, more fluid. I’m a coder at heart, I’ve recently fallen back in love with the open source world and love hacking away in whatever spare time I have, building apps in an agile free flow manner. It keeps me up to speed. I can still code an application (not in the most elegant way, mind) with the best of the geeks in some hackathon in soho or some more exotic climate if I’m lucky. This is my first instinct, just get shit done. Don’t faff over architecture, spend money. I hate layers of bureaucracy that develop in projects. Why can’t we just sit down and code out functionality in a permanent beta rollout. That’s surely the future? Its surely something we all aim to achieve? So yes I hate enterprise and everything that gets in the way to slow things down.
But and there is a massive but. I have learnt over the years that the odd software project can come off the rails. Why? Geeks maybe? Bad management maybe? The reality lies in the complexity of solutions as they gather momentum. Whether that’s momentum in terms of the reach of the application such as a global platform, increased functionality, increased numbers of developers churning out code, increased product stakeholders. Even the very nature of the application becoming business critical with many moving parts. All of which need to be tamed, this agile constant beta development approach is great in startup mode but like a new puppy they eventually need to be tamed otherwise developments have a tendency of becoming unplanned. Resulting in unmanageable code and an unsustainable solution. We need to organise the chaos into a controlled ecosystem and as the complexity increases, the modules and lines of code grow, all increasing the management burden which in turn, make the whole approach of getting releases out more rigid as we fight to tame the beast that we have created.
Getting the architecture right at the beginning helps with this process, but with everything, progress and ideas keep flowing all of which challenge this architecture immediately. We adapt to keep up, but with this adapting, changes the nature or our original intentions and starts to introduce the odd little bit of chaos into the solution. This chaos is a good thing, it challenges us, it helps progress our thinking, however it needs to be managed.
The real reason why enterprise ends up coming into play is because software development, which running into thousands of lines of code is by very nature complex. But this is a myth its actually quite simple. The thousands of lines of code have all been written to keep up with our new fast paced market and our insatiable demands for innovations, ideas and pace. It’s our market place that is creating the requirement for enterprise, the more ideas we have the more structure we need to keep in place to tame the beast that we could end up creating.
And at the top of the human food chain with the ever increasing ideas is our digital marketeers who want us always to stay ahead of the game. These beasts could reinvent our efforts every week. The problem is without enterprise thinking we have controls that naturally have to fall in place to protect the investment we have made so far. On smaller solutions that do not require such heavy lifting at the backend, we can simply throw away and start again if it gets complicated. This leads to consumable software solutions, which have their benefits and place. However these are strategic decisions and must be made at the beginning. Trying to change a large scale business critical solution with a strategic corporate investment into a consumable solution will lead to some very expensive software development cheques.
So what’s the answer. I think the problem is not about about whether enterprise is a bad or a good thing. Its about how we design the conveyor belt, how we ensure we can load the hopper of our product roadmap and ensure there is a common understanding of the order of releases. Sometimes this requires patience, sometimes things have to wait for those larger releases that will benefit someone in your organisation but not necessary our new sexy urgent idea we may be trying to push out. Remember we are trying to bring some order to something that could quickly get so complex and out of control that the only thing we can do is throw it away and start again. This is the real risk, every I.T. project is only a few scary ideas away from the scrap heap and this costs a lot more money in the long run.
The challenge for us how to we maintain our competitive advantage. A solution to this is a well thought out roadmap thinking ahead about the market, using real metrics about performance, your user base and how best to plan in functionality to keep them satisfied. Enterprise is a game of chess, its hard to master and takes time. Each move requires us to think well ahead and plan. Even if that means planning in your agility. Its not a gain for short term game and requires a lot of patience.
PHP, being a scripting language, is relatively slow when compared to code that runs natively on a server. 
matt clarke // just technology 