Appvia have had the opportunity to help transform IT in some difficult and challenging organisations (or institutions), where culture, capability and engineering vision have sometimes lacked the right approach.
A lot of project driven IT will be primarily focused on the delivery of the applications. Usually the vision is set for the service that they are intending to produce, discoveries will start, stories will start to enter the backlog and soon enough there is enough scope for an Alpha. Where the organisation is lacking an innovative engineering function, standard processes, architectural approaches and upfront heavy operational needs can start to arrive.
DevOps, a well known industry term may then arrive into the common language. “Well, you need some DevOps engineers”. A confusion around the Engineer and the principles tends to happen and tooling starts to arrive into the organisation in an adhoc fashion across projects. Before long, there is a diverse and wide range of tools and functions dispersed across the organisation, with very little DevOps princples being adapted. There is unlikely to be much reusability or organisational vision to the IT infrastructure and the quality will vary and be inconsistent.
Although this image sounds quite bleak and negative, this is a common pattern that we have witnessed in varying organisations, especially Governments and Banks, (though not just isolated to those). The nature of the organisational structure usually has a large impact on the delivery of the IT systems within it. However, despite what might seem like a difficult or impenetrable problem, does have a solution or set of solutions.
Identifying what is important to the organisation and the business is the main key. For some it is to stay competitive to the market, so speed of delivery and being able to pivot quickly is a core part of their business ideals. For others, it is the sheer cost of IT and being highly available and resilient as well as being able to deliver consistently and produce an aligned organisational capability to help maintain, evolve and support what is there.
One of the biggest costs in IT is the people and one of the biggest drivers of cost can also be people’s decisions. Where there is a lack of vision for the IT that is surrounding the delivery of the software, it leaves a gap that will need to be filled to deliver applications. Every time this occurs, the usual roles will repeat and hence the cost of delivery will rocket across all projects. This is where having some form of platform is one of the key advantages. Where legacy IT systems are intended to be transformed and aligned to cloud, to decouple traditional monolithic services; by not having something to align to, will result in a similar position, where technical debt is almost instantly obtained and divergences already occurred through lack of alignment across an approach in the organisation.
A platform we’ve provided gives Developers a self service framework, so that they can interface into a logical web GUI to facilitate their needs to be able to deliver quickly. This platform would make up all the standard components:
Internal and External Certificate Management
Code Coverage Systems
We focus the technical approach on containers as they create a lean, small and discrete application focused delivery mechanism. They are also a good technology choice to help promote decoupling and a “microservice” style architecture with the overall service.
We then leverage Kubernetes as a base to orchestrate the delivery of these applications across multiple clusters, abstracting away cloud vendor specifics from the application as much as possible, (where it’s sensible), to enable it to be hosted consistently anywhere with few changes. Where there are cloud needs i.e. object storage and databases; we took the decision to leverage those in cloud as opposed to providing them as Kubernetes services. This is purely to reduce the maintenance burden, (patching, upgrades etc.) on teams and make the development teams more focused on the business value.
Without getting too sidetracked with our love of Kubernetes; it really offers a fantastic base to build upon. It obviously isn’t the solution to all problems, but to be able to support 50+ independent projects, (which is where we have delivered platforms); it offers a great framework to extend and harness a central view and offer huge value in consistency. A support team being able to learn a framework to support so many projects, means they can keep lean and effective like the platform they are hosted within. This is where technology really can help shape the organisation inline with its benefits.
Although we try to make things as self-service as possible, there is still knowledge required in the development teams to be able to use the technology in the right way. This is when platform inductions come into play; running regular inductions to go over a hands-on process of taking application code, iterating it, testing it, deploying it and monitoring it, is key to allow people to be as effective and enabled as they can be. It is sometimes something that can get overlooked, with there being an expectation that delivery teams should just be able to just, well, deliver! However, enabling them in the technology is critical and hopefully, within 1 business day, the team is able to focus on the business logic but have a framework to work within that doesn’t consume too much of their time on the “string and glue” that can hold up a service or need Cloud / DevOps roles to help facilitate those tasks. The additional value of these inductions, is that it allows the platform and the platform teams to learn, improve and evolve with the users; to make sure that we always get that important feedback loop.
To make sure we don’t get carried away and send you all to sleep with our blog or cause you to need a stiff drink, we will end it here but we will continue to offer as much support and advise as we can in other blogs. Other topics we would like to cover are:
Teams and Team Makeup
Technology and how to decide what is right for your business
ITIL and how to cherry-pick the important bits but not allow it’s traditional approach to hamper agile, effective delivery
Integrating platforms into operational services i.e. allow teams to simply inform others of changes, incidents; without the need for heavy people process.
So stay tuned for some of these.
If you would like to speak to us about anything within this blog, feel free to reach out to us or contact us via email at email@example.com.