2020-02-28 Friday - Book Review - Cloud Native Transformation: Practical Patterns for Innovation

You can find the book on Amazon here: Cloud Native Transformation: Practical Patterns for Innovation 

(1st edition, by Pini Reznik,  Jamie Dobson, Michelle Gienow)

Below is a copy of the review I've also posted to Amazon.

Changing Your Culture to Ensure Cloud Native Transformation Success

(full disclosure: James Mottram, with Container 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:

1. What is Cloud Native?
2. The Human Challenge of Cloud Native
3. What's the Pattern? Architecture, Pattern Languages, and Design
4. Beyond Patterns: Behavior, Biases, and Managing Evolution
5. Knowing Thyself: The Cloud Matrix Maturity Tool
6. Tools for Understanding and Using Cloud Native Patterns
7. Patterns for Strategy and Risk Reduction
8. Patterns for Organization and Culture
9. Patterns for Development and Process
10. Patterns for Infrastructure and Cloud
11. Applying the Patterns: A Transformation Design Story, Part 1
12. Applying the Patterns: A Cloud Native Transformation Design, Part 2
13. Common Transformation Challenges
14. Building a bank in a Year: Starling Bank Case Study
15. 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.

Also see my post on LinkedIn

2020-02-27 Thursday - Apache Camel 3.1.0 Release

A tip of the hat today to Gregor Zurowski, for his LinkedIn post mentioning this news:

Apache Camel 3.1.0 release
https://camel.apache.org/blog/release-3-1-0.html

"All users of Camel 3.0 are encouraged to upgrade to Camel 3.1 soon because there are some major memory usage optimizations in this release."

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12346526&projectId=12311211


Of particular interest, I noted the following:

• [CAMEL-12619] - camel-swagger-java - Add support for 3.0 spec 
• [CAMEL-14227] - camel-rest-swagger - Add support for OpenApi 3.0 spec 
• [CAMEL-14315] - add openapi-rest-dsl-generator

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?"

2020-02-24 Monday - Quick Visual Guide to Setup Kotlin for Eclipse 4.14 (2019-12)

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.

References:

• https://kotlinlang.org/
• https://github.com/JetBrains/kotlin
• Download:
• https://github.com/JetBrains/kotlin/releases/tag/v1.3.61
• Kotlin Language Reference (v1.3)
• https://kotlinlang.org/docs/kotlin-docs.pdf

• https://www.eclipse.org/eclipse/news/4.14/

 

 Setup Steps:

 

0.0 Precondition:

• JDK 1.8 installed   
• Eclipse 4.14 (2019-12) installed

1.0 Install the Kotlin Eclipse Plugin

• http://marketplace.eclipse.org/content/kotlin-plugin-eclipse
  • https://dl.bintray.com/jetbrains/kotlin/eclipse-plugin/last/

2.0 Kotlin Preferences: Building

• Check box to enable incremental compiler usage.

  

3.0 Kotlin Preferences: Code style 

• Accept default Code style 

 

4.0 Kotlin Preferences: Compiler

• Configure JVM target version: 1.8
• Configure JDK Home: <your path to JDK 1.8> 

 

  5.0 Create a new Kotlin Project (e.g. "HelloWorld")

 

6.0 Verify that your Project's Properties "Java Build Path > Libraries" has Java JRE 8 configured

 7.0 Create a Kotlin File

  8.0 Name the file (e.g. "HelloWorld")

 

 9.0 Create the "main" function

10. Remember to "Run-As" a Kotlin Application

Additional Reading:

Building RESTful APIs with Kotlin

• https://kotlinlang.org/docs/tutorials/spring-boot-restful.html
• https://medium.com/hacktive-devs/build-restful-web-services-with-spring-boot-and-kotlin-8190bd156722
• https://dzone.com/articles/kotlin-spring-bootspring-data-h2-db-rest-api
• https://auth0.com/blog/developing-restful-apis-with-kotlin/ 

 More Kotlin Tutorials & Exercises

• https://play.kotlinlang.org/byExample/overview
• https://play.kotlinlang.org/koans/overview
• https://kotlinlang.org/docs/reference/coding-conventions.html

2020-02-13 Thursday - Researching POST for Update

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...


REST API Design - Resource Modeling (2014)

• https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling
• Using POST instead of PUT to record updates...???

Radar: REST without PUT (2015)

• https://www.thoughtworks.com/radar/techniques/rest-without-put

2020-02-08 Saturday - Energy Levels and Cognitive Capability Bands

Photo by Terry Tan De Hao on Unsplash 

https://unsplash.com/photos/MTUQ2jobhYM

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.

Source: NASA
https://www.nasa.gov/mission_pages/planck/multimedia/pia16875.html

• https://en.wikipedia.org/wiki/Flow_%28psychology%29
• https://en.wikipedia.org/wiki/Hyperfocus 
• https://en.wikipedia.org/wiki/Mindfulness
  

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. 

Photo by Jakob Boman on Unsplash

Source:https://unsplash.com/photos/Td9FnTMHu0A

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.

Source: https://media0.giphy.com/media/WxwC4ivuBMElb3oZIo/giphy.gif

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. 

Photo by Annie Spratt on Unsplash

Source: https://unsplash.com/photos/7CME6Wlgrdk

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. 

Photo by Iwona Castiello d'Antonio on Unsplash

Source: https://unsplash.com/photos/oWU2w0JuHnE

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. 

Photo by NeONBRAND on Unsplash
Source: https://unsplash.com/photos/RzgPzI8GRck

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. 

Photo by Demi-Felicia Vares on Unsplash
https://unsplash.com/photos/CMqw9hQ-cw8

Supporting Citations:

2020-04-18 Saturday

• Medium Article: Effective Work: Secrets To Working Effectively in the Age of Information Overload - by  Dotan Nahum, (Amazon Book, Kindle)

2020-10-10 Saturday

• Energy demands limit our brains' information processing capacity, University College London  
• "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."

2021-06-03 Thursday

• https://ideas.ted.com/the-7-types-of-rest-that-every-person-needs/

 

2021-09-26 Sunday 

• This guest post by Susan Shu Chang, on Eugene Yan's blog - led me to a post by Susan ("Why my top productivity multiplier is sleep") - which resonates strongly with what I have written above. Also see this post by Susan: ("How I optimize my day with routines and tools: Lessons from balancing multiple projects") - in which this quote caught my attention: "my productivity and mental sharpness nosedive if I am in focus mode for too long"

2020-02-02 Sunday - Agile Enterprise Architecture, a rebutal to a criticism

Marc Gewertz made the following post on LinkedIn recently:
 

"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."

 My reply posted on Linked:

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 a article by Sam Holcman

What does “agile” Enterprise Architecture mean?
https://www.architecturescoe.org/resourcesall/agile-enterprise-architecture

"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. 

His arguments have the smell of No True Scotsman.

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. 

 2023-03-06 Postscript

Gerben Wierda's latest article:
Beyond Chess and the Art of Enterprise Architecture (Part Two)
https://www.architectureandgovernance.com/applications-technology/beyond-chess-and-the-art-of-enterprise-architecture-part-two/
 
I noted he includes this...
 

An Agile EA Manifesto
 
If there was to be an ‘agile EA’ manifesto — it could be summed up as:
 

• Strategic agility and uncertainty analysis over fore- and backcasting
• Requirements over principles
• Collaboration over division of labour
• Design skills over design principles
• Create your abstractions ‘risk based’
• Govern your architecture through ‘checks & balances’
• And last but not least:
• IT skills over powerpoint skills