Changing Your Culture to Ensure Cloud Native Transformation Success
(full disclosure:James Mottram, withContainer Solutions - on behalf of the authors, very graciously provided me with a review copy to read).
Today I completed my read of Cloud Native Transformation: Practical Patterns for Innovation.
While this is not intended as a technical book on how to do a cloud native transformation - and may in fact - be of the most use when read by executive leadership, business stakeholders, IT managers - yet it may still be of immense benefit to help orient non-technical and technical members of an organization - and align the thinking and planning of the organization - and in aiding to set and manage expectations.
This is a book that can be primarily of use to two categories of companies:
Those who have not yet started their cloud native transformation journey; and
Those who have stumbled in their cloud native transformation journey - and don't yet know how to recover (or, who do not yet truly understand what went wrong).
I particularly enjoyed the pattern discussions in each chapter - but found the case studies in chapters 14 ("Building a bank in a Year: Starling Bank Case Study"), and 15 ("Welcome to the Jungle: Adidas Cloud Native Transformation Case Study") - to be particularly interesting.
Chapters in the book include:
What is Cloud Native?
The Human Challenge of Cloud Native
What's the Pattern? Architecture, Pattern Languages, and Design
Beyond Patterns: Behavior, Biases, and Managing Evolution
Knowing Thyself: The Cloud Matrix Maturity Tool
Tools for Understanding and Using Cloud Native Patterns
Patterns for Strategy and Risk Reduction
Patterns for Organization and Culture
Patterns for Development and Process
Patterns for Infrastructure and Cloud
Applying the Patterns: A Transformation Design Story, Part 1
Applying the Patterns: A Cloud Native Transformation Design, Part 2
Common Transformation Challenges
Building a bank in a Year: Starling Bank Case Study
Welcome to the Jungle: Adidas Cloud Native Transformation Case Study
(There's also an Epilogue, and an appendix: A. Library of Patterns)
One of the hardest parts of implementing change is changing culture - this is the book you need to help you with that critical part of the cloud native transformation journey.
A quick visual guide to setup Kotlin 1.3 in Eclipse 4.14 (2020-12)
This posting was motivated by the elegant Kotlin implementation that Christian Hujer posted to Github today (for Conway's Game of Life) - which led me to spend a little time today revisiting Kotlin.
The conciseness of the Kotlin language is notable when comparing Christian's two implementations: Kotlin vs. Java.
Some years ago, while researching the actual language in the RFCs related to the use of POST and PUT - I happened across some articles that suggest POST could/should be used for update actions.
This blog posting is a placeholder as I try to find those postings that I vaguely recall...
Some personal observations and reflections on the relationship between energy levels - and the corresponding cognitive capacity to perform different levels of mental work - and some of the significant factors that affect those.
Meeks Cognition-Energy Capability Scale
10 - "Zone Thinking" - intensively creative mode - when I am "in the zone" - able to think, work, and see deeply nested relationships between highly abstract concepts. Deep insights occur often, and seem to come more easily - often coupled with leaps of intuition. A very rare level - often degraded by stress, worry, noise, and any negative emotions. On a monthly basis - this mode of working may only be experienced for a combined total of 8-12 hours during a month - often due to the significant degrade caused by open office plans, stress introduced by a heavy traffic commute, or poor office accommodations. Successfully sustaining this level of cognitive capability for mental work requires isolation. Copious amounts of great coffee also required.
9 - "Deep Thinking" - not "in the zone" - but able to perform intense, deeply focused, mental work - at a highly creative level. Deep insights occur - with sustained effort. This level is typically most useful for highly analytical work - or work that requires a high degree of attention-to-detail. Typically sustainable for 4-6 hours on a given day - but any sustained period of working more than 8 hours per day will quickly deplete the ability to achieve/sustain this cognitive/energy level for a period of time - fatigue will quickly cause a degrade to level 8.
8 - "Efficient/Fast Thinking" - a sustainable level for high quality mental work. My normal day-to-day zone for most mental work - mental clarity is high, able to focus and execute consistently - even with the typical distractions of stress, heavy workload, worry, negative emotions, office accommodations, or a heavy traffic commute. This is the minimal level for pattern recognition faculties to be operating optimally.
7 - "Average Thinking" - the minimum level to adequately juggle two or more projects - requires sufficient food, relaxation, recreation, sleep - and a reasonable workload. This energy/cognitive level has significantly limited capacity for original/creative mental work. Tasks which can be performed on auto-pilot are best tackled when energy/cognitive levels have been degraded to this level. Detailed work can still be adequately performed. The possible introduction of errors in mental work is usually not a concern at this energy level.
6 - "Degraded Thinking" - mental acuity is slightly impaired. The probability of the introduction of errors in mental work is a strong possibility. Abstract thinking capabilities are beginning to be impaired. Connections between concepts are not immediately obvious - and require greater sustained effort to see. Normal tasks begin to take longer to complete. A feeling of low energy is perceptible.
5 - "Impaired Thinking" - this energy/cognitive level is typically reached during periods of high stress, significant fatigue, cold, flu, etc. Efforts to sustain intense mental work for 50+ hours per week - for periods longer than 2-3 weeks will result in a degrade to this level. Mental acuity is definitely impaired. The introduction of errors during intense mental work is no longer a possibility - it is a certainty. Only repetitious type tasks should be performed at this energy level.
4 - "Zombie Thinking" - at this energy/cognitive level, or below - mental acuity is significantly impaired. Mission-critical, high-value, detail-intensive mental work should be halted - rest and recuperation are required. Recommended treatment: 1-3 weeks at Hotel Playa Mazatlan.
"Our brains have an upper limit on how much they can process at once
due to a constant but limited energy supply, according to a new UCL
study using a brain imaging method that measures cellular metabolism."
"The study, published in the Journal of Neuroscience,
found that paying attention can change how the brain allocates its
limited energy; as the brain uses more energy in processing what we
attend to, less energy is supplied to processing outside our attention
focus."
"If there's a hard limit on energy supply to the brain, we suspected
that the brain may handle challenging tasks by diverting energy away
from other functions, and prioritising the focus of our attention."
"Our findings suggest that the brain does indeed allocate less
energy to the neurons that respond to information outside the focus of
our attention when our task becomes harder. This explains why we
experience inattentional blindness and deafness even to critical
information that we really want to be aware of."
"Agile EA? Give me a break! Please stop dreaming up buzzwords. If your EA is not agile, then your EA is not an EA, it is just another slow, stubborn, organic mess of an enterprise!"
"Agile means quickly adaptable. The purpose of using the practice of EA is to design, develop, build and change your enterprise in a logical, systematic, and integrated way, which is quickly adaptable to any changes needed, for any reasons given."
"If the architecture of your enterprise is not logical, systematic, and integrated, then it is not agile, no matter what buzzwords are used to describe it."
One could make the same argument for maligning the use of the phrase agile software development - when software development itself intrinsically should mean quickly adaptable. But that would be refusing to acknowledge that there are indeed "agile" - and "not-agile" - ways of doing things.
But, of course, not all software development organizations and processes are organized and implemented in a way that is quickly adaptable. The same is true of the many varied implementations of enterprise architecture in organizations - and their processes.
If the preponderance of evidence shows that there is more rot and waste in what most folks have chosen to call enterprise architecture - then I have no problem with some folks prepending Agile to EA - in their attempt to introduce more agile ways for an EA to operate - and to call out that the Emperor has no clothes.
2023-03-01 Postscript
A friend recently shared with me this link to an article by Sam Holcman
"We do not believe that 'agile' Enterprise Architecture can even be a real thing!"
"It does seem that adding the adjective 'agile' to Enterprise Architecture makes it now different than previous methods, teachings, courses, or 'certifications.'"
"This would imply, using the antonym of 'agile' that, what they were doing before was dull and slow, and what they are doing now, 'agile' Enterprise Architecture, is quick and nimble."
I don't think Sam gets the picture ("We do not believe that "agile" Enterprise Architecture can even be a
real thing! It is the output of TRUE Enterprise Architecture that would enable enterprise 'agility'"). He has a vested interest in the methodology that he promotes (Enterprise Architecture Center of Excellence (EACOE)) - and so could naturally be expected to be resistant to change.
If you apply his same arguments against agile Enterprise Architecture - to the revolutionary/evolutionary changes in SDLC practices - of agile and DevOps. He would likely argue that those are not real terms either.
His argument (and the About page for the EACOE) appear to be reminiscent of the heavyweight implementation of Enterprise Architecture - which is the antithesis of agility: Ivory Tower and Heavy-Handed Centralized Governance. And that is very different from what the term Agile Enterprise Architecture really encompasses.
Apache Camel 3.1.0 release
https://camel.apache.org/blog/release-3-1-0.html
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12346526&projectId=12311211
Of particular interest, I noted the following:
Additional suggested reading:
- https://camel.apache.org/
- https://github.com/apache/camel
- https://camel.apache.org/manual/latest/
- https://camel.apache.org/components/latest/index.html
- https://github.com/apache/camel/tree/master/components
Claus Ibsen will host a webinar (Tuesday, March 3rd, 6am PST, 9am EST) to review "What's new?"