Into the Beyond

In this book so far, you have learned about the fundamentals of an operating model, been given a technology landscape overview, and read about previous industry attempts to bring structure to operating models. We then leaned into why the future is distributed and the different classifications of edge computing environments, before we presented a step-by-step guide on how to purpose-build your own operating model. To solidify what we have learned, we provided an implementation example based on an anonymized case study to help you apply the learnings in your organization.

In this chapter, we will cover the following additional topics:

• Operating models for multiple independent operating units across the globe
• Antifragility
• Gap analysis
• Technical debt
• Undifferentiated heavy lifting
• How to measure progress
• Challenges associated with creating and applying your operating model
• Managing a multitude of options

By the end of this...

Operating model challenges

In this section, we will cover a few gotchas or things to be aware of when developing your operating model. If you’ve been in your organization for a while, then you probably are already aware of some and perhaps – even better – know how to address your challenges. If you are new or don’t know how to tackle some of the challenges in your organization, then this section is for you.

We have already mentioned some of the challenges along the way and hence won’t dive deep into them again. However, this section provides a brief recap.

There is no ready-made operating model that is fit for purpose, hence we wrote this book to help organizations and leaders to get the most value out of their distributed technology, skills, and process investment by creating their fit-for-purpose operating model.

The challenges of having knowledge gaps and undocumented vital information can have many root causes, such as organizational...

Becoming antifragile

The author Nassim Nicholas Taleb describes antifragile in his book with the same name as “things that gain from disorder.” While we all understand what fragile means, we don’t really have a word that describes the opposite, so the author claims. The word robust might come to mind, but robust better describes things that don’t change when exposed to disorder, such as uncertainty, variability, imperfect/incomplete knowledge, and error. Antifragility does take a different approach instead of just going further. Antifragile describes things that thrive, evolve, or get better when exposed to stressors or change, and open source software does exactly that.

We need to be more explicit, though, with what we mean when we say open source software. We are not talking about a public GitHub repo that is maintained by a handful of people. While impactful software might start that way, we really refer to enterprise-grade or enterprise-ready software...

Understanding how open source connects antifragile, undifferentiated heavy lifting, and tech debt

It is important to recognize that undifferentiated heavy lifting and technical debt are different from antifragility but related.

Undifferentiated heavy lifting is an effort that the customer doesn’t notice or care about. For example, whether your favorite bank builds its own server operating system or uses an established vendor’s operating system makes little difference to the online banking user experience, if things go well. However, it exposes the organization and its customer to more cost and risk because the bank’s core business isn’t building operating systems but providing banking and financial services industry-related products and services. While I don’t know any bank that builds its own operating systems, there are banks that are cobbling together fundamental services such as IAM, storage, logging, and monitoring with either their DIY or...

Measuring organizational progress

We believe the best way to measure progress in a distributed technology operating model is via flow metrics. If you baseline your percentage of complete and accurate lead, wait, and process times, you will not only be able to optimize individual processes but also see whether completely revamped processes would actually help improve the overall outcome. For example, if your compliance process still imposes a wait time of 4 to 6 weeks to get your compute instance provisioned, does it matter that the actual provisioning of an EC2 instance only takes 5 minutes versus the previous 1 hour on your local virtual machine farm?

A word of caution: do not use metrics to compare teams. Problem spaces and technology stacks impose various degrees of complexity, hence comparing the flow between the mainframe team and the digital-natives team is unlikely to provide any insights. And don’t forget to consider building slack into your flow as Martin Fowler...

Summarizing our journey thus far

We have covered quite a bit of ground in this book.

Our path started off with looking at the challenges that the journey to the cloud has thrown at organizations and why – with edge making its way in every industry – we can’t continue the same way we started off our journey to the cloud. We urged leadership to stay away from confusing marketing slogans such as cloud-first strategy and explained why we have this stance.

We demystified terms such as strategy, tactics, mission, vision, goals, capability, and objectives and explained how they relate to each other.

We then revisited research on organizational cultures completed by Dr. Ron Westrum and how to create performance-oriented cultures. We did this because it is the reason why we chose the workshop practices we outline in this book. And to be precise, this in turn is to help create a culture with a high level of collaboration, information sharing, and open communication...

What’s next?

Firstly, you need to decide whether you need help or are confident to start this journey for your organization by yourself.

If you are ready to start on your own, then start socializing your idea with your colleagues, get executive sponsorship, and follow what’s laid out in Chapters 5, 6, and 7. Kickstart your initiative with the assets made available in our GitHub repository (https://github.com/PacktPublishing/Technology-Operating-Models-for-Cloud-and-Edge).

If you need help for the short or medium term, then you can get help from consultants or your partners or contact the authors to help you find a suitable way to get started. Long-term ownership needs to sit within your organization, hence there’s no need to seek long-term support from external entities. Note, if you get consultants and partners, make sure that those individuals have actually built and owned what they built beyond day 2 operations before. There is no point in getting help...

Summary

And with that, we thank you for reading this far and wish you good luck on your path to defining and building your distributed future according to your needs! If you love the acceleration of new concepts and technologies, the increasing global connectedness, and the resulting shared learning as we do, then the conclusion can only be that it’s an exciting time to be alive! Enjoy the enormous growth and learning potential, building high-performing teams, and leading with the culture aspects by example, and don’t forget to share what you have learned by raising issues or pull requests on our GitHub repo.

Further reading

Refer to the following for more information about the topics covered in this chapter:

• Enterprise Architecture as Strategy: https://hbsp.harvard.edu/product/8398-PDF-ENG
• The Open Organization: https://www.redhat.com/en/explore/the-open-organization-book
• Martin Fowler on Slack: https://martinfowler.com/bliki/Slack.html
• The climate impact of ICT, Lancaster University: https://arxiv.org/pdf/2102.02622.pdf
• Microsoft: A new approach for Scope 3 emissions transparency: https://download.microsoft.com/download/7/2/8/72830831-5d64-4f5c-9f51-e6e38ab1dd55/Microsoft_Scope_3_Emissions.pdf
• Sustainability: https://eprints.lancs.ac.uk/id/eprint/150985/1/TheClimateImpactOfICT_2020Report.pdf

Acknowledgments

This book wouldn’t have been possible without the help of others. Our employers were the very first to give us work, which helped us gain insights to write this book. We would also like to thank our families for giving us space and time to go through this long 6+ months journey.

But most importantly, our reviewers. We carefully selected our reviewers because of their expertise but also because of their personalities and the fact that our reviewers will all call out things that “don’t seem right.” All this is important to create a book of value for our readers, our industry, and the economy that thrives on business value creation. For that, we’d like to particularly thank the following:

• Katherine Squire, Senior Vice President, Engineering, Culture Amp
• Thenna Raj, Head of IT, Woolworths
• Guillaume Poulet-Mathis, Director of Product Engineering, Optus
• John Heaton, Chief Technology Officer, Alex Bank
• Niraj Naidu...