Adapt First! Expect the Unexpected?

Thilo Hermann
4 min readMay 6, 2021

--

https://pixabay.com/de/photos/bruce-lee-hong-kong-2164515/ from https://pixabay.com/de/users/tee2tee-386023 on https://pixabay.com/

Who would have anticipated in 2019 that, starting in spring 2020, we would have several lockdowns all over the world due to COVID-19? Most probably, no one. So, should we always “expect the unexpected” and prepare for all circumstances? Most probably, not. However, much like the Technovision theme “Be like water …” (see https://www.capgemini.com/technovision-2021-technology-trends-in-business/), we should be able to adapt and react quickly.

Whatever we do, change will come — some expected, and some unexpected.

Our architecture and design need to allow us to adapt and change it easily to address the change. In this context, the functional and the non-functional requirements, especially around adaptability, are key and every architect should appreciate the change and be open minded.

Architects tend to over-engineer; we need to respect the fine line between being adaptable and trying to foresee everything (which is, by definition, not possible). In the words of Bruce Lee, “a goal is not always meant to be reached, it often serves simply as something to aim at.”

What can be done to support an architect to define the right scope in the context of adaptability?

  • Risk-based: Analyze the imposed risks of an anticipated change and only address those with the highest score (probability, severity).
  • Projections: Analyze historical data of past changes (e.g., implemented change requests) and make a projection based on that.
  • Heatmaps: For existing applications, you can create a heatmap (e.g., out of your source control system) to identify the areas with a high change rate. For those, adaptability and flexibility in architecture are key.
  • Bet: Sometimes, it’s simply a bet based on your gut feelings and “silver neck” architects will call that “experience.”
  • Ecosystem: Investigate what your partners and competitors are doing. This can be used as input for the risk-based approach (see above).
  • Ask the Business: It’s always a best practice to talk to the business experts and get their view. As business is the main driver, you shouldn’t forget to talk to them.

What architectural patterns will help to achieve a flexible, adjustable system in which a change is not a thread?

  • Microservices: Divide and conquer! domain-driven design and bounded context are key to identify microservices. The independence and loose coupling give you the flexibility to adapt quickly and easily. Please be aware that this is not a silver bullet for all architectural challenges. Microservices as such also impose other “side-effects” (see https://bit.ly/3tydsgX).
  • Antifragile: Building applications that are on the next level, not only resilient and robust, but able to cope and even get better in a changed ecosystem (see https://en.wikipedia.org/wiki/Antifragility).
  • APIfication: APIs allow the streamlining of processes across the business and are key in a loosely coupled application landscape (see https://www.capgemini.com/2018/11/api-fication-a-3-step-process-to-joining-the-api-economy/). It is not about building another application, it’s about “getting all the applications to talk to each other. This help to do an impact analysis and allows us to react flexible on changes.
  • Configuration: Building configurable applications or microservices with, for example, plugins, adapters, dependency injection. The good old “Gang of Four” design patterns are still relevant and valuable (see https://en.wikipedia.org/wiki/Design_Patterns).

What kind of processes, operating models, governance will support the adapt-first approach?

  • Product centricity: Move from projects to product-centric services. This implies long-term responsibilities for the defined product and therefore the right mindset to embrace the change and invest in flexibility.
  • BizDevOps: Installing one team that is responsible to cover all dimensions E2E of an application helps to have clear responsibilities. Together with automation it speeds up changes and enables responsiveness.
  • Top management: Bottom-up approaches are nice, but to change the way of working, the internal processes, the operating models it’s essential to have the support from the top management, i.e., from the CxO level.

What people and teams will you need to make it happen?

  • A-Team: The people who are working in such an environment should have a lot of different skills (cover the whole SDLC, several technology stacks, automation tools, operational tasks, etc.). It looks like a “Swiss Army Knife” — software engineer. The problem with this is that only few of us are capable of fulfilling these demands. The team, as such, must be able to fulfill all of this and not one single team member (see https://bit.ly/3dYSgvI).

On top of this, you sometimes just need some luck. At #Capgemini, we started distributed agile delivery years ago and, unsurprising, this operational model fits very well into the expected post-pandemic new normal.

To close with another Bruce Lee quote: “Take things as they are. Punch when you have to punch. Kick when you have to kick.”

For further information download the latest #TechnoVision 2021 https://www.capgemini.com/technovision-2021-technology-trends-in-business/

--

--

Thilo Hermann

Thilo has more than 25 years of experience in IT Architecture and worked for several clients in Germany. He’s located in Stuttgart and works at Capgemini.