Technology platforms are the critical middle layer of the traditional technology stack. They rely on the infrastructure which supports them and, in turn, power the varied and growing number of applications that sit on top. It is clear that all three layers are inter-reliant, yet it is often the platform layer that doesn’t get the focus it needs.
For the increasingly digital enterprise, any system downtime is extremely costly. So how can enterprise IT leaders avoid a situation where their cloud platforms are the weakest link?
Building a strong foundation starts in the planning
In recent a recent article we covered the steps IT leaders should take after enterprise platform downtime , where a key component was the review of the original planning documentation. But this essential planning process is a step that is often short-circuited or completely forgotten, especially in today’s DevOps world.
DevOps way of working has introduced great efficiencies and there are many good reasons why everyone is getting on board. The main challenge, however, is that it is easy to lose sight of the big picture and forget about some of the fundamentals from the (dare we say it!) ITIL days – which, while they may sound antiquated, are still very relevant today.
We’ve had extensive (and robust!) internal discussions over the years on how to integrate the best of both worlds in your platform planning process. Here is a summary of what we think is important.
Platform planning principles in the DevOps world
The way that we used to approach platform or application delivery is very different to what we do now. We used to have separate people or teams responsible for distinct elements of the development process – one responsible for functionality, one for non-functional requirements (availability, monitoring, performance, etc) one for security etc. Now all of these elements are delivered by the one, common DevOps team.
But are they really?
Developers will tell you that they are thinking about the bigger picture, coding the functionality while thinking about the broader enterprise context, but – all too often – their focus is on getting the solutions ‘out there’. When the primary objective is the rapid deployment of new platforms or applications, you can be assured that critical elements such as monitoring, security, compliance and reliability are not getting the attention they deserve.
That’s not to say that the DevOps model is flawed. It’s a sound foundation that enables streamlining and fast-tracking of the inevitable wave of digital transformation. But there are several elements from the ‘traditional’ development world that the DevOps team can’t afford to forget – in fact, they should be included in a check-list of responsibilities of each and every developer on the team.
Three elements to retain from the traditional development world
The old ITIL list of considerations is quite lengthy. We challenge even those who have lived and breathed it way-back-then to remember it now. It’s OK, you don’t need to remember it all, as long as you focus on the following:
• Monitoring Think about the last major downtime event – how did you become aware of it? If it was your internal or external clients that told you about it, you probably have a monitoring problem.
Proactive monitoring needs to be a key consideration for every new technology piece – whether at the infrastructure, platform or application layer. And it needs to be embedded as a key part of the development process. Any monitoring program that you try to implement after a new platform or feature is launched will not be as effective as it could be.
A few platform-specific examples to consider: How is your database functioning? For integrated platforms, is the schedule of events occurring as needed and expected, including arrival rates, load rate and other cyclical activities? How will you know? The monitoring requirements, tools and processes need to defined as part of the functionality build.
• Security / Compliance Every organisation has a set of business rules that guide its operations. In the enterprise space there are many – and there is a particular focus on security and compliance.
When project delivery times were much longer, it used to be that security and compliance requirements were managed at the operations handover point. Once a platform or application was released, the security team would wrap a layer of security and compliance around it – often, the developer wouldn’t know much about it.
In a world when new iterations are released on a monthly basis, you can’t afford to think about security and compliance at the end. It has to be done in a more real-time manner. It’s very much a mindset thing – every time a developer builds a new piece of functionality, its security requirements and implications have to be front of mind and factored in.
• Reliability, Availability and Maintainability (RAM) Even in an enterprise setting, where the stakes are high, not every platform or feature is mission critical. In fact, treating your whole technology environment as such places unnecessary pressure on already limited resources – and potentially means that the truly essential elements are not getting the attention they need. This elevates risk needlessly.
High-end subject matter expertise is absolutely critical in creating a consistent framework for Reliability, Availability and Maintainability – RAM – that is held in mind throughout the development lifecycle. An expert will set up creative, data-rich reliability testing and clearly define SLAs for each key functionality upfront.
Putting all this together helps manage stakeholder expectations and assists in allocating the right resources to where they are needed most.
Key message – think ‘big picture’
In the DevOps model the focus is about speed and agility in implementing the functional parts of a platform or application. And rightly so, the world is moving too fast for us to work in any other way.
But this doesn’t mean that developers can forget about the broader enterprise context they operate in or to ignore the non-functional requirements that define it. Sure, it is often much easier to make a feature work in a specific way if you approach it in isolation. But in doing so, developers are effectively undermining the integrity of the entire, complex and interrelated technology stack. A situation no-one wants.
Each and every member of the DevOps team needs to think big picture and, in developing new platform solutions, they need to consciously think about, define and weave-in some fundamental elements from the ITIL world – particularly monitoring, security/compliance and Reliability, Availability and Maintainability (RAM). These are the foundations of the new platform planning check-list.
If you believe some of these concepts are new or hazy to your DevOps team it may be time to review some of your processes. Fusion Professionals can help you to integrate the still-relevant components of traditional development within the modern and fast-moving DevOps environment.
