Welcome to Bucaro TecHelp!

Bucaro TecHelp
HTTPS Encryption not required because no account numbers or
personal information is ever requested or accepted by this site

About Bucaro TecHelp About BTH User Agreement User Agreement Privacy Policy Privacy Site Map Site Map Contact Bucaro TecHelp Contact RSS News Feeds News Feeds

DevOps - Development and Operations

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.

RSS Feed RSS Feed

Follow Stephen Bucaro Follow @Stephen Bucaro

Computer Networking Sections

Fire HD
[Site User Agreement] [Privacy Policy] [Site map] [Search This Site] [Contact Form]
Copyright©2001-2024 Bucaro TecHelp 13771 N Fountain Hills Blvd Suite 114-248 Fountain Hills, AZ 85268