DevOps Consultancy solutions were associate with getting the technology right. The key was technology, the solution was technology and the business expected and paid for technology. Times have changed. Well, at least for those of us taking notice. Today technology is hardly ever a significant problem. Technically, we have a less complicated world. Over the years we have come to understand that technology is basically an arrangement of Processing, Memory, Networking and Storage. We have master utilization by using virtualization. We understand horizontal scaling is ‘better’ than vertical scaling. And that we can deliver the PMNS more easily in converge and hyperconverge products that also contain the software solution. We have automated many of the key activities to enable reduction in time and costs.

The Cloud paradigm came along and made life easier by helping us to become Service Brokers rather than server admins or network engineers. To the customer we are now Service Brokers; well, we should be. We should be experiencing shorter procurement cycles given that applications and services (the solutions) are deliver from a Service Catalog. Although this can true in the Public Cloud deployment model and the Software as a Service (SaaS) delivery model, when it comes to Private Cloud procurement we still seem to stuck in the past and suffer unnecessary delays. Even as Public Cloud services are take up by more and more businesses the activity of getting the servers. Applications and services ‘up there’ still makes for hard going. All the work that is require to design and deliver a Public Cloud host environment is still steep in old-fashioned working practices.

Despite all this change and learning, solution design and implementation is still a thorny job. And produces mountains of documentation (some needed, some pointless). Endless Gant charts and interminable meetings trying to get the solution in place and delivered. Why is this?

Application Development and Delivery

Application developers use to live in a world of their own. To some extent that is still true. Application development companies don’t usually have network engineers, technical architects and storage SMEs sitting in on the early morning scrums. Applications are developed in isolation and separate from the technical solutions. That will need to created to host, resource and support the application.

In most cases an application is developed for one of two reasons. To provide a solution for an external customer or to provide an application for the business with which it can make money. For instance, a company needs to pay salaries. To do that it needs an application that can pay the salaries, calculate tax and pension information. And enter data into a database and then print a payslip all in accordance with the legal framework set out in the Revenue Services ‘rules of engagement’.

An application development company will take on that challenge and through a series of iterations. It will deliver an application that meets all of the customer and legislative requirements. For a business that wants to make money from an application the scenario is very similar to that for an external customer. The difference is financial in that the business has to justify the cost of having developers on staff creating the application. That cost is set against a forecast of income from the eventual deployment of the application as a service for the business.