Platforms, SRE and ITSM. Can we integrate them? Yes, we can! | SKILup Days 2024

Hi, I'm David Tomon. I need to my s as to. And today I wanted to talk about how we can brief the between those or engineer support platforms with the wider service management community.

We'll talk about how to find common cause around the holy ground of customer value, how to have productive conversations across the community, including how to make the case for continuous investments. Now, why can this be difficult? Because in today's fast paced digital landscape, the traditional paradigms of IT service management are being challenged by the rapid evolution of new approaches like platform engineering in our enthusiasm to disrupt and drive forwards.

We risk of leaving pockets of resistance in our wake, which we only have to mop up later. As I think Dhar sharp put it, cultural debt is like technical debt, but the interest rate is higher. So what's my perspective?

Well, I've been lucky enough to be around these and other related topics for a while now. In my work with organizations and clients, with people like qa, I've been able to take an holistic and integrated approach to this learning through discussions with my fellow DevOps institute and people, so ambassadors and surely some of the most experienced and knowledgeable people on the planet. I formed some ideas and guidance that I'd like to share and discuss.

Now we've all met people who sing the praise of their various methodologies, approaches, and frameworks. Often hard won and at great expense. Too often they're used to justify their investment in the status quo.

Much personal collateral is bound up in this can stymie grow adoption and progress? And here are a few of these excuses. Now you are probably familiar with some of them.

By the way, if you've used any of yourself, I know I have, then you'll hereby absolved and forgiven. While these new approaches have revolutionized how services of development supported, they're often perceived as conflicting with established ITSM principles. However, the key to unlocking their full potential lies in bridging this cultural, uh, gap and integrating them seamlessly.

This session delves into some of those challenges faced by those operate in these areas, and which explores how the evolving ITSM uh, approaches can bridge this using the principles of SRE, DevOps and of course, platform engineering as our guiding light. Can we therefore use platforms to help bridge the gap? Yes, we can, as you know, platform engineering focus on the design, development and maintenance of software platforms.

And these platforms are typically used to support the development and deployment of applications and services. They often provide common infrastructure APIs and tools that can be used by developers to build and deploy their applications, and in turn, reduce the toil on operations, uh, staff and maximize, for example, SRE effectiveness. Platform engineering is an important discipline because it helps organizations to build scalable, reliable, and flexible software platforms that can support the development and deployment of a wide range of applications and services.

By providing a common foundation to software development, platform engineering helps organizations to streamline their processes, reducing cost and complexity of managing that infrastructure and accelerate the delivery of new applications and services and other factors that drive value Through ITSM frameworks like it. O let's look at some key elements of how co-creative value works in IT service management. The first step towards bridging the gap between platform engineering and ITSM is understanding that shared goals, uh, delivering value to customers.

While traditional ITSM focuses on process efficiency and stability, DevOps and platform engineering emphasizes agility, automation, and continuous delivery. By aligning these goals, organizations can create a symbiotic relationship where the strengths of each approach complement each other. Co-created value emerges when teams collaborate, deliver innovative solutions.

Whilst maintaining operational excellence, ITIL defines co-created value with the mutual creation of value between service providers and service consumers through shared resources, capabilities and processes. This means the importance of understanding and meeting the needs and expectations of customers to deliver value to those services. To be effective value is not solely determined by the service provider.

Beauty is in the eye of the beholder, so it is rather a collaborative effort between the provider and the customer, the technology that customers play. An active role in the value creation process by providing feedback, insights, and requirements that influence the design, delivery, and improvement of services. Platforms, therefore have a key role to play in supporting the consistency and deliverable of valuable software.

So collaboration, uh, recognizes co-created value created through, uh, shared responsibility between service providers and customers. It emphasized the importance of building strong relationships and partnerships based on trust, transparency, and communication to drive mutual success. And the stability that can come from the user platforms provides the basis of that trust.

Collaboration at scale requires trust at scale, continuously improvement allows value to be co-created in an ongoing process that needs monitoring, uh, evaluation in order to suggest improvement. And ITIL promotes a culture of continuous improvement where organizations regularly assess customer feedback service levels, uh, performance metrics, market trends to identify opportunities to enhance the quality and deliver greater value from the software that it delivers. Platforms connect and information gather, providing data that brings insights to help illuminate some of these responsibilities.

We share resources and capabilities in creating value. We acknowledge that both service providers and customers contribute resources, capabilities, and expertise to the value curation process. It encourages organizations believers, their collective strength and assets to co-create innovative solutions and deliver superior outcomes that meet the evolving need of customers.

The platforms form part of these shared resources and by embracing the principles of co-created value, organizations can foster a stronger relationships through our customers to enhance service quality. This allows us to differentiate ourselves in a competitive marketplace. However, these relationships rely upon good communication and this is difficult if there is not a shared, um, common understanding of our platforms, they're merits and how they use therefore, mix and stereotypes around platform engineering can furiously hamper that understanding and therefore that effectiveness.

So let's have a look at some of these, uh, myths that service managers might hold about platform engineering and see if we can dispel a few along the way to embracing change. One common misconception is that DevOps and by extension platform engineering is synonymous with chaos and the lack of control. However, it is not about sacrificing stability for speed, but rather achieving a balance between innovation and the liability.

By implementing robust monitoring incident management, um, change control processes, organizations can mitigate these risks while embracing agility and innovation. Furthermore, these practices empower teams to take ownership of their service, fostering a sense of accountability, autonomy, and collaboration across the organization. Robust platforms have a key role to play in supporting this high velocity it, which is a crucial element in ITIL version four.

The myth that platform engineering is just for developers may still persist, but whilst platform engineering involves designing and maintaining those platforms, obviously that support software development, IT impact extends far beyond developers. Platform engineers who also focus on infrastructure automation, scalability, reliability, security benefit, not only developers but also operations teams, IT managers, and of course ultimately end users. And whilst we all love an elegant tool, it is a myth to think that platform engineering is only about technology.

Whilst technology is of course a crucial aspect of platform engineering, it's not the only focus. Platform engineers also deal with people, processes and organizational dynamic of producing platforms that allow collaboration, communication, and a need. Therefore, to understand the business are equally important to effectively design and manage platforms that meet those organizational goals.

Nor should we fall into the trap that platform engineering is a one time project. Of course, while some may view platform engineering, as you know, something, we do once to set up infrastructure and tools. However, platforms require ongoing maintenance, uh, updates and optimization to adapt to the evolving business needs.

And of course, as the technology advances, platform engineering is a continuous process rather than a one-off initiative. There is platform engineering just about building platforms. Okay, whilst platforms, you know, building them is part of our engineering work, it also involves managing and evolving them over time.

This includes monitoring performance so we can optimize resource usage, um, have better security, and of course, how do we incorporate that feedback to ensure platforms remain efficient, reliable and scalable. It is always about more than the platforms themselves. They are not merely self licking long bulbs.

Platform engineering is not an all or nothing endeavor. Some organization may the seed platform engineering, uh, all in or all out, but where they need to complete the overall business infrastructure. You know, we can forgive them for taking that initial response, but in reality, platform engineering can implement it incrementally, allowing organizations to gradually transition and modernize their system whilst minimizing disruption of risk.

This sort of strangle vine approach beats real dividends and enable quick wins to be taken and us to build confidence with our partners. But platform engineering, surely that eliminates the needs of the operations team. Do you want me to put myself out of a job?

Well, platforms engineering emphasizes yes, automation, self-service, but it doesn't necessarily mean eliminating operations teams altogether. And instead it allows operations teams to focus on higher value tasks and improvements such as strategic planning, optimizing workflows, and improving overall reliability and performance. In other words, releasing humans from judging, um, to those tasks that are not so error prone that require the skill, the judgment and empathy that only a human being can bring.

And finally, you know, platform engineering does it guarantee instant success? So what are you saying tommo? Well, yes.

Um, there is no guarantee that after all the platform engineering effort and costs might still be no further forward. We could even have made it worse. So yeah, pretty much implementing platform engineering practices doesn't guarantee it doesn't happen overnight.

It requires commitment, investment, and continuous improvement. Organizations may encounter challenges and setbacks along the way, but with dedication and perseverance they can realize significant benefits over time. It is that need to employ these approaches together, including our service management tools and practices.

And it also means that we cannot do it on our own. So we need to embrace our stakeholder to affect change. Now, developers of course, need to utilize these platforms.

They must be easy to use, fundamentally add value into the software development practice. Traditional operations staff will have insights into the task engineers and DevOps engineers and platform engineers, and of course they could be the same person, um, but where they are not, they all have a stack in the development, deployment or use of platforms. Service managers process and practice owner of another IT roles will be pivotal in adapting high velocity for which the platform is a key component.

Remember also that we have allies amongst the agile service managers, coaches and Scrum masters. And lastly, by no means we should look to inform and educate project managers on the potential use of the platforms, both on and as a result of their project. So having identified these stakeholders, what kind of conversation should we be having?

Productive conversations should focus on identifying common objectives, addressing concerns or finding synergies between those different methodologies. We should be highlighting the benefits such as of course, increased speed, um, to market, improve reliability, enhance customer satisfaction, and this can help overcome resistance to change. Emphasizing the importance of reliability, stability and the management of risk can help reassure IT.

Service management practitioners that platforms will enhance rather than compromise service quality. This reliability therefore has to become a first class customer, but to the platform engineer and engineering service management tools are interconnected components of our modern IT operations and service management environments. Cloud based service management platforms will provide a wide range of IT service management, IT operations management, and IT business management solutions.

But this trust in them is built upon the transparency, um, for the end-to-end understanding that these platforms supply the service management automation is achieved through a suite of these IT TM tools, typically that streamlined service desk operations, incident management, change management, problem management, and other IT processes that you are probably familiar with. Platform engineers can leverage these tool suites automation capabilities to both automate routine tasks and integrate workflows and approvals, but also improve overall efficiency and reduce manual effort when we're tied into our existing software platforms. Platform engineering often involve integrating disparate systems, applications and services to create a cohesive IT ecosystem.

These ITSM tools provide integration capabilities, allow platform engineers to connect these tools with monitoring systems, configuration management databases, and ticketing systems. This integration allows seamless data interchange and workflow orchestration right across the IT landscape. Almost all IT tools have a configuration management database or system package.

hal, um, serving as a central repository to store information about our IT assets, configurations, and relationships our platform engineers can use in C MDBs to maintain a comprehensive inventory of infrastructure components, track configuration changes, and assess the impact of changes on service delivery. And this visibility enable better decision making and risk management within the platform engineering domain, the largest and most significant customer facing parts of an ITM tool is likely to be incident and problem resolution. These modules provide tools for identifying, prioritizing and resolving IT incidents and platform engineers can leverage these capabilities to quickly respond to incidents to help diagnose root causes and implement corrective actions to prevent recurring issues.

Uh, this ideal of that, this automation of what this platform provide by integrating incident problem management workflows with these platform engineering processes, uh, we can improve service reliability and minimize downtime. Now, as a bit of a byproduct, this produces performance analytics and reporting capabilities, providing insights into service performance, user satisfaction, and operational efficiency. Platform engineering can use these analytics to monitor key performance indicators or KPIs, identify trends, make decisions based on that data to optimize, uh, the performance and resource utilization of the platform.

Now, many already probably use AI to fit, but it can also be a source of data for further machine learning. This data can be combined in the service catalog. Um, service catalog and self uh, service is seen as one of the most obvious areas of platform integration.

Request fulfillment has been advocat in an area of automation for years. It's enables organizations to be fine and publish IT services, service offerings, uh, request platform engineers got to use this with the service catalog. Promote self service capabilities internally, allowing users and developers to request a provisional resources such as virtual machines, applications or access missions or, um, testing systems without manual intervention.

This of course reduces service delivery time, but also empowers users whilst maintaining control over governance and other IT resources. Who by leveraging these ITSM or ITOM and of course, um, IT business, uh, capabilities, platform engineers can automate those processes, um, for service delivery, um, ultimately enabling organization to achieve their business objectives more effectively. But none of this can be done without resources and perhaps ultimately money.

So how do we make the case for this continuous investment? Well, platform engineering is a journey, not a destination. Investing in the integration the platform we're doing with ITSM is essential for staying competitive in today's digital landscape.

But steady as she goes is effectively going backwards. Continuous investment and automation monitoring and infrastructure as code enables organizations to uh, achieve these things ahead of the game. Across the game line.

If you like, practices such as infrastructure, as code version control and automated testing allow teams to streamline operations, reduce manual errors and accelerate that time to market are boom and bust culture with sporadic but uncoordinated single project is unlikely to be effective and too often we will slip back to our old manual wanes of workaround or known error without eliminating them by the use of platforms. Moreover, fostering a culture of continuous learning and improvement ensures that teams remain adaptable and resilient in the face of involved and challenges. Only if we act swiftly and decisively.

The due date, of course, is always today. In conclusion then integrating platform engineering with ITSM is not about choosing one approach over the other, but rather embracing the strengths of both to drive innovation and value creation. By fostering open communication, embracing continuous investments in technology and culture, organizations can bridge the gap between those cultures and thrive in increasingly competitive landscape.

Have technology continues to evolve. Uh, the then the route to continued success lies in that adaptability, that collaboration, that relentless focus on delivering value the customer. Now we set out to examine some of these routes to value.

We've seen some of these conversations we might want to have, uh, with those key stakeholders and the way we want to have them with them. And finally, we have our hope made the case for continuous investment by service managers in that platform engineering. But those who are interested in the background of some of these service management associated issues here are few of my favorites, but feel free to share your own books or sources or any publicly available links in the chat and just to, um, uh, acknowledge our obligatory acknowledgements of course with you both ITIL and, and Calvin here.

Um, but thank you very much for your attention. I hope you enjoyed this brief foray and to what of course is a much bigger piece of work. If you would like to continue the conversation, please do so in the chat or contact me on any of the onscreen methods.

I'll be delighted to hear from you. So thank you so much, uh, for being with us, uh, for this session and I wish you the very, uh, best of luck in applying platforms and the very best of learnings with the rest of today. Goodbye.