Author: Tom Geraghty

Drawing on the lecture contents, share one example of a real-world disaster caused by people’s under- or unpreparedness. Consider both behavioural and systemic/structural causes for under or unpreparedness.

 

On april 26, 1986, the RBMK-1000 reactor at Chernobyl suffered a series of catastrophic failures that resulted in core meltdown. The RBMK type of reactor was inherently unsafe compared to most reactors used in Europe and the USA, partly because of a lack of concrete reactor shielding and partly due to the use of cheaper and more powerful graphite as a moderator instead of water (IAEA, 1992). The Soviet government at the time maintained that nuclear power was perfectly safe, despite multiple previous nuclear power incidents in the country, and that accidents were unlikely to the point of impossible (Plokhy, 2018). This stance led to a lack of safety protocols and a belief that spending extra money to build concrete shielding for the reactor in case of a meltdown was unnecessarily wasteful.

 

After the explosions at the plant, government officials, afraid of contradicting their superiors in the party, resisted calling for evacuation of local towns for many hours and days. In the nearby town of Kharkov, the International Workers’ Day parade took place on May 1, 1986 despite radiation levels many times the levels required to trigger evacuation (Ervasti, 1986).

 

Radiation is invisible, and that combined with government assurances that nuclear power was perfectly safe, meant that people in Chernobyl and surrounding towns did not prepare for such an eventuality. When the disaster occurred, some people were even found to be sunbathing, having discovered that they tanned quickly (not realising that the “tan” was in fact deadly radiation burns) (BBC, 2019).

 

Even emergency responders such as firefighters and the military, did not appreciate the seriousness of heavy doses of radiation, and were seen picking up bits of graphite from the reactor that had been thrown into the air by the explosion (Alexakhin, et al. 2006). For some people involved in the response, their belief that nuclear power was safe was so strong as to dismiss any safety concerns, due to the edicts issued by the Soviet government.

 

People are less likely to prepare for a disaster in high compliance cultures where authorities dismiss concerns and overstate safety, and radiation, being an invisible threat, compounds the issue.

 

Share one example of disaster risk reduction alternative that has either improved or has the potential to improve people’s preparedness. Consider both potential and limitations of such alternative.

 

In Bangladesh, an approach of community-based disaster risk management (CBDRM) has been implemented in response to the threat of floods and cyclones. (ADPC, 2008) This involves local communities in identifying and assessing their own disaster risks, developing preparedness and response plans, and implementing risk reduction measures. The program in Chittagong  involves training community members in disaster risk reduction techniques, including early warning, evacuation, and first aid. Community members are also involved in the planning and implementation of disaster risk reduction measures, such as building raised platforms for homes and livestock, constructing flood shelters, and planting trees to prevent erosion.

 

Through this program, communities have become more resilient to disasters, and have been able to reduce the impact of floods and cyclones on their homes, crops, and livelihoods. Additionally, the program has empowered local communities to take ownership of their own disaster risk reduction efforts and has improved communication and coordination between community members and local authorities (Shaw, 2006).

 

CBDRM programs may not always involve all members of the community equally however. Some groups, such as women, children, and people with disabilities, may be excluded from planning and implementation, which can lead to unequal distribution of resources and a lack of representation in decision-making. A lack of technical expertise can also hamper the effectiveness of CBDRM programs and may result in inadequate or ineffective disaster risk reduction measures (Nguyen et al, 2020).

 

Word count: 615

 

References

 

ADPC, 2008. “Community Empowerment and Disaster Risk Reduction in Chittagong City” Safer Cities 21. Available at: https://www.preventionweb.net/files/globalplatform/entry_bg_paper~SaferCities21.pdf (Accessed: 13 March 2023).

 

Shaw, R., 2006. Critical issues of community based flood mitigation: examples from Bangladesh and Vietnam. Science and Culture, 72(1/2), p.62.

 

“INSAG-7: The Chernobyl Accident: Updating of INSAG-1” (PDF). IAEA. 1992. Archived (PDF) from the original on 20 October 2018. Available at: https://www-pub.iaea.org/MTCD/publications/PDF/Pub913e_web.pdf (Accessed: 13 March 2023).

 

Plokhy, S. (2018). Chernobyl: the history of a nuclear catastrophe. First edition. New York, Basic Books.

 

Ervasti, R, (1986) Soviets Celebrate May Day, No Mention of Nuclear Accident With AM-May Day. AP News. Available at: https://apnews.com/article/595cefb4d64896ee1a422caa6c1b88d2 (Accessed: 13 March 2023).

 

The Aftermath of the 1986 Chernobyl Disaster: An Eyewitness Account | BBC HistoryExtra (2019). Available at: https://www.historyextra.com/period/20th-century/chernobyl-disaster-ukraine-when-what-first-responders-diary-eyewitness-nuclear-exclusion-zone/ (Accessed: 13 March 2023).

 

Alexakhin, R.M. et al. (2006). Environmental consequences of the Chernobyl accident and their remediation: Twenty years of experience. Report of the Chernobyl Forum Expert group “Environment”.

 

Nguyen, H., Pross, C., Han, J Y-C. (2020). (Ed) Perkins, M. Review of gender-responsiveness and disability-inclusion in disaster risk reduction in Asia and the Pacific. UN Women-Asia and the Pacific. https://asiapacific.unwomen.org/en/digital-library/publications/2020/10/ap-review-of-gender-responsiveness-and-disability-inclusion-in-drr

1. Alexander (2013, p.2714) argues “resilience has a bright future ahead of it as an explanatory concept in various allied fields that deal with environmental extremes. However, its success in this respect will depend on not overworking it or expecting that it can provide more insight and greater modeling capacity than it is capable of furnishing.” In the context of DRR, do you agree with this statement? Provide reasons for why/why not.

 

Resilience is not a panacea for all the challenges facing DRR. Resilience may be misinterpreted to mean robustness: simply sustaining functions despite challenges, whilst true resilience is “The intrinsic ability of a system to adjust its functioning prior to, during, or following changes and disturbances, so that it can sustain required operations under both expected and unexpected conditions.” (Hollnagel et al, 2006) Rather than treat resilience as a model, we must treat resilience as an activity, and make clear the distinction between active resilience and passive robustness. 

 

The scholar Nassim Taleb, in his book “Antifragile” notoriously misinterpreted resilience: “Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better.” (Taleb, 2013) It is clearly an easily misinterpreted and misunderstood concept.

 

Additionally, as Cretney (2014) argues, there is a danger that resilience can become a tool for the perpetuation of inequalities and injustices. We must question for whom resilience is being built and who benefits from it most.

 

2. Given the range of vulnerabilities associated with New Orleans and Hurricane Katrina (2005), as outlined by Laska and Morrow (2006), suggest THREE disaster preparedness measures or initiatives that could serve to reduce some of these vulnerabilities.

 

Applying the concept of multi-layer safety (MLS) by Esteban et al, we can highlight three disaster preparedness elements that may have served to reduce some of the vulnerabilities highlighted by Laska and Morrow (2006) are:

 

1. Primary layer: Hurricane Katrina highlighted the importance of adequate infrastructure in reducing both the likelihood and the severity of flooding. This includes improved infrastructure, such as stronger levees and better drainage systems, to reduce the likelihood of future floods.
2. Secondary layer: During Hurricane Katrina, communication between emergency responders, local officials, and the public was limited, leading to confusion and delays in response. These gaps in emergency response planning demonstrated the need for effective early warning systems. The appropriate measures include developing a comprehensive early warning system and up to date evacuation plans.
3. The Tertiary layer regards recovery and restoration after a disaster. In the case of Hurricane Katrina, better involvement of the local community in planning for a disaster, and responding to it afterwards would improve the effectiveness of recovery programmes. 

 

3. Given the many and varied critiques and limitations of the resilience concept (e.g. as presented in Cretney 2014), why do you think resilience persists as a central element and goal of DRR strategies?

 

Resilience is about what a system can do — including its capacity: 

 

• to anticipate — seeing developing signs of trouble ahead to begin to adapt early and reduce the risk of decompensation 
• to synchronize —  adjusting how different roles at different levels coordinate their activities to keep pace with tempo of events and reduce the risk of working at cross purposes 
• to be ready to respond — developing deployable and mobilizable response capabilities in advance of surprises and reduce the risk of brittleness 
• for proactive learning — learning about brittleness and sources of resilient performance before major collapses or accidents occur by studying how surprises are caught and resolved 

 

(From Woods, 2018.) As Woods states, resilience is a verb. There are many aspects of resilience, but the key point of adapting and improving is vital. DRR is an active process, it is a verb, just like resilience. DRR exists to serve people, and the adaptable element of resilience is people: it is only people who can adapt, learn, and improve (Geraghty, 2020), which is why resilience persists as a central tenet of DRR.

 

References:

 

Cretney, R. 2014. Resilience for whom? Emerging critical geographies of socio-ecological resilience. Geography Compass, 8 (9): 627–40.

 

Esteban, M. et al (2013). Recent tsunamis events and preparedness: Development of Tsunami Awareness in Indonesia, Chile and Japan, International Journal of Disaster Risk Reduction. Elsevier. Available at: https://www.sciencedirect.com/science/article/pii/S221242091300037X (Accessed: February 16, 2023).

 

Resilience Engineering and DevOps – A Deeper Dive | Tom Geraghty (2020). Available at: https://tomgeraghty.co.uk/index.php/resilience-engineering-and-devops/ (Accessed: 16 February 2023).

 

Hollnagel, E., Woods, D. D. & Leveson, N. C. (Eds.) (2006). Resilience engineering: Concepts and precepts. Aldershot, UK: Ashgate.

 

Laska, S., and Morrow, B. H. (2006). Social vulnerabilities and Hurricane Katrina: an unnatural disaster in New Orleans. Marine technology society journal, 40(4), 16-26.

 

Taleb, Nassim Nicholas. 2013. Antifragile. Harlow, England: Penguin Books.

 

Woods, D.D., 2018. Resilience is a verb. Domains of resilience for complex interconnected systems., p.167.

 

In December 2022 I requested a copy of the NUH Trust’s risk assessment and associated decision making evidence showing how the restriction to women’s individual rights and the benefits to home birth, in terms of clinical outcomes, was weighed up against other safety concerns to come to a decision not to provide a full time home birth team.

In April 2023 they responded with the attached NUH maternity home birth risk assessment document.

 

TL;DR: What is platform engineering? Isn’t that just old Dev vs Ops thinking? What is the Platform Operating Model?

A platform operating model is:

 “a business model that creates value by facilitating exchanges between two or more interdependent groups, usually consumers and producers.”

Applying DevOps thinking, we can adopt that model internally to organisations, by considering a platform team as the producers of the platform service to a range of consumers – the value-stream oriented product teams.

Value stream-aligned teams focus on a single value (or revenue) stream, because that singular laser focus on the success of their product maximises the return on investment. However, it’s not efficient or effective for each stream-aligned team to use and maintain all the underlying technology beneath it.

In the old days, we might have addressed this with a separate Ops team who provided the infrastructure, but that (as we know) caused inefficiencies, bottlenecks, and created “walls of confusion” when applications were thrown over from Dev to Ops in order to run in production. Instead, modern platforms allow stream-aligned teams to consume platform services in order to run their own workloads. The stream-aligned team “pull” services from the platform team, instead of “pushing” the application over to an operations team.

An effective platform engineering capability achieves an economy of scale by allowing multiple stream aligned teams to consume the same platform, but primarily aims to improve *flow*, and reduce the cognitive load of developers using the platform.

So, what is a platform?

“A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced co-ordination.”

From Evan Bottcher, 2018

https://martinfowler.com/articles/talk-about-platforms.html

 

And what is a product?

A product simplifies something for the consumer, solves a market problem and/or addresses a customer’s need or desire. In the case of an internal platform, the market is an internal market, and the customer is the stream aligned team(s). This is also why an organisation may create multiple platforms and platform engineering teams: different stream aligned teams have different needs, and to meet all those needs, a platform would end up being too large, cumbersome and bulky, like a huge swiss army knife with a hundred features when you only need a knife. 

Amazon’s founder, Jeff Bezos, once said, “Your goal should be to create value for everyone you interact with.”

 

A product is: 

• Coherent
• Evolving
• Long lived
• Supported
• Owned
• Designed with the user (customer) in mind
• And it’s worth noting that all products also have *names*

 

In most organisations, a product also requires a Product Owner, who is responsible for translating business strategy, product vision, customer needs and preferences, and balancing these priorities against non-functional requirements, proactive preventative maintenance etc. A platform should be no different in this respect: without a product owner, the platform may drift away from what is most valuable for the business and the users of the platform, costs of running it may increase beyond the ROI of its utility, and it may suffer from feature sprawl, technical debt, poor reliability and unplanned work.

Let’s draw out some of those words from Evan’s definition.

APIs, tools and services:

This means that it’s not just “one” technology. A single platform may possess multiple options for use, multiple optional features and functions. One user may use a completely different suite of features than another, but they’re both consuming the same product.

Knowledge and support:

A product doesn’t just get given to the consumer without any support or guidance about how to use it. Of course, it should be as usable and fit for purpose as possible without extra instructions or guidance, but just as you should be able to get into a modern car and drive it without referring to a manual, it still comes with a manual to help you realise the maximum benefit of the product. And more than that, a product come with a support team – who you can reach out to for help when you need it. A support team isn’t just there to process support tickets – they work with users of the product to help them make the most of it *and* gain essential and valuable feedback to drive the evolution of the product.

A “compelling internal product”

A platform is “A curated experience for engineers.”

Thanks to Matthew Skelton and Manuel Pais for this term.

There are two key points to make here – one is that the product consists, as we described above, of tools, APIs, documentation, services, alongside support and advice on how to use it. It consists, essentially, of everything required to make that experience as positive as possible for engineers to get their job done. 

One of the primary goals of platform engineering is to reduce the cognitive load of the engineers and developers using it. Users of the platform are solving complex problems, and the more that any of their attention is taken in working out how to access something, how a feature works, what the API specification shows, or anything else, the less of that cognitive capacity is spent on addressing the business problems that they’re tasked to solve. The more that the platform can allow people to maximise their *germane* cognition, reducing extraneous cognitive load, the better the end result. The safest cars are also those that are easiest to drive, because we can spend more of our attention on the actual task of driving safely.

The best platform therefore, provides just what the stream aligned team needs, nothing more, and reduces the cognitive load of the people using it. It evolves according to feedback from the users of the platform, “competes” with other platforms in the organisation to be the best one to use (the compelling internal product), is owned by the platform team, and has a cool name. 

Funding Models:

Funding for platform engineering typically falls into two categories: operational funding and project funding. Operational funding is used to maintain the existing platform and deliver continuous service to users. This includes the costs of hosting, licensing, monitoring, and supporting the platform. Project funding, on the other hand, is used for new developments and expansions of the platform. This could include the development of new features, integrations, or scaling efforts.

In many organizations, funding is often allocated based on the value a platform brings to the business. This means that a platform that supports high-value or high-revenue generating teams might receive a larger slice of the budget. However, it’s crucial to ensure that funding decisions consider the long-term sustainability and evolution of the platform, rather than just immediate revenue potential.

Organisation Structure:

In terms of organisation structure, platform engineering usually sits at the intersection of technology and business, providing a bridge between technical and non-technical teams. The platform team is often composed of cross-functional roles such as product owners, engineers, architects, and designers, each with their own specialities but sharing a common goal – to build and maintain a robust, efficient, and user-friendly platform.

This team often works closely with other teams in the organization, known as the stream-aligned teams, to understand their needs, deliver the necessary platform services, and gather feedback for future improvements.

Overall, the organization structure, governance, management, and funding models for platform engineering all aim to foster a collaborative, customer-centric environment. The goal is to provide an effective platform that reduces the cognitive load on its users, allowing them to focus on delivering value to the business, and evolves in response to feedback and changes in the business environment. It’s a dynamic, ever-evolving process that requires a commitment to continuous improvement and customer satisfaction.

Summary

Platform engineering, under the guidance of a strategic leadership team, functions as a bridge between technology and business in an organisation, aiming to provide robust, efficient, and user-friendly platforms. This is achieved by a cross-functional team, including a product owner, who is responsible for the platform’s evolution, balancing operational maintenance, and prioritising feature development. Funding is typically bifurcated into operational and project-based categories, with allocation decisions influenced by the value a platform brings to the business and its long-term sustainability. The organizational structure promotes a collaborative environment, with platform teams working closely with stream-aligned teams to understand their needs and provide necessary platform services. The ultimate goal is to reduce cognitive load on users and allow them to focus on delivering value to the business while ensuring the platform evolves responsively to feedback and business environment changes.