DevOps - Development and Operations
By Robb Kimmer
Solution Development and Delivery
In earlier days, solutions were associated 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 mastered utilization by using virtualization.
We understand horizontal scaling is "better" than vertical scaling and that we can deliver
the PMNS more easily in converged and hyperconverged 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 delivered from a Service Catalog.
Although this can be 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
be stuck in the past and suffer unnecessary delays.
Even as Public Cloud services are taken 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 required to design and deliver a Public Cloud hosted environment is still steeped
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 be 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.
In both of the examples there are constants that can make for hard going. In the same
way that technical solutions are affected by people, process and politics, so application development
is affected by an isolationist practice. Why is this?
Why Is This?
Across all IT from datacenter infrastructure to applications to cloud there is one problem
that affects the smooth, joined-up running of a project and that is "silos of activity".
The silo has long been the black mark of IT. We became so used to operating in silos
that we didn't question whether such an arrangement was productive and cost effective. In fact,
even now, the majority of IT organizations operate using silos. Solutioning and development
in isolation.
Solution design and application development saw the arrival of Lean and Agile as a really
effective way to operate and yet, silos remained. Companies operated Agile but, kept the silo
way of doing things. Strange when you think about it. Agile means flexible and able to change
without trauma. Silo is a 'pit' with high sides that makes change very difficult. So, in essence,
Agile and silo worked together and made change difficult. Still does.
| 
About BTH
User Agreement
Privacy
Site Map
Contact
News Feeds
RSS Feed
Follow @Stephen Bucaro
Basics and Certification
