Thoughts on proof of concept and rapid deployment

I was having a debate with a programme manager colleague who is a massive fan of end user empowerment, of rapid provisioning and self service portals, he and I are often at odd’s, he likes to remind me of my olden days nature, that I need to join the cloud and self service revolution. After our conversation on the train home, I thought I’d put together a post to put the issue to bed and explain where I’m coming from.

Before we continue let us establish something, I’m a huge fan of self service, of user empowerment, the more I can enable our customers, ‘the business’ to do what they want to do in order to meet their business goals, the better. My job should be the facilitator to make sure whatever you request from an infrastructure standpoint (and if I can help with the application load/config/support work I will), gets done.

So what are my reservations about self service solutions. Let us operate on the basis that my programme manager friend was trying to sell to me as a ‘unique value proposition’ which would ‘transform opportunity’.

• What is it that the user can request – can I request a stack, a web server, application server and database server then just load my application, or are we talking about blank box provisioning. Why? It’s often not the box provisioning that’s the problem, I can build a server in hours even seconds, it’s the nonsense that sits after that – middleware, what version, what upstream/downstream feeds and settings – what security baselines, for what application and therefore configuration. The database configuration and build out, again I can give you a white box with Windows or Linux on it, getting the database, the database stack set up is not necessarily as quick.
• If it’s not the stack – who is co-ordinating the middleware load, the stack configuration so that the end user gets their finished end to end product and what are the lead times. If I can build a virtual machine or as one colleague said to me a physical server in 35 minutes, what’s the lead time for my MQ build out, then how long to get the queues setup and permissioned, what about any firewall rules or configurations to bring online with our related systems.
• Who owns it? Production Support – has it passed through the production grade checks if not then they might not accept it as a ‘completed’ system, therefore does it get supported by the end user, the projects resource and who then provides the ongoing maintenance?
• Process alignment – so I press deploy front office risk app and it builds me my web server, my app server and database instance, how do I get access to it? Do I need to log a call which might take days to implement and is that deployed alongside our normal production and uat environments.
• Template management – who owns and develops these stacks on a application basis, if it’s the end user how do we align that with the operating system, the middleware and other layered components that need to be upgraded.
• Service level agreements – it’s proof of concept/rapid provisioning with me deploying systems in minutes, how does it work from support, regardless of who supports it, my web server seizes half way through a critical test plan with the vendor sat next to me billing $1500 a day, what level of support do I get. I know it says proof of concept, but in reality we might actually be wanting production grade support in terms of response if we have sensitive timescales and requirements.
• Go live – so I get my application code validated and fully working on my proof of concept templated stack using the pre-provision tools, are they deployable in production? Is it the same OS revision, layered components and middleware – do I have to re-test, if it’s not re-deployable using the same stack then is this rapid provisioning or proof of concept a benefit or hinderance?

We need to be innovating and delivering in house solutions covering the entire application and infrastructure stack of an equal or better quality to that which we might buy in as a service.

We need to understand the rules of engagement and consider the end user expectations, so often we start off with a proof of concept solution one which is and I quote ‘of no consequence’ only to end up in endless meetings discussing ways around accepting a non standard solution into production support on a ‘best endeavours’ basis.

This site uses Akismet to reduce spam. Learn how your comment data is processed.