Posted by Marbenz Antonio on August 4, 2022
The first step in preparing for uncertainty as an enterprise architect is to consider your standard operating procedures. And technology isn’t the only topic under discussion.
We usually hear statements like “change is a constant” and “the rate of change and the threat of disruption creates a huge opportunity,” Steve Case said. Although we are aware that this is the case, many professionals still appear to design and construct business applications and systems based on a specific set of point-in-time needs.
The necessity for ongoing business application rebuilding to take advantage of new opportunities develops from software development. However, an unfortunate result of continuous integration/continuous delivery (CI/CD) is that it may allow developers to produce subpar solutions and keep fixing them as a standard best practice. However, there are more options besides the ones that agile software development teams and squads commonly choose. Better consideration of how we design for change is something architects can and should do.
Recently, we instructed a session on using architectural thinking for uncertainty at The Open Group’s Enterprise Architecture Practitioners Summit. We believe that reconsidering standard approaches for creating code and databases is the first step in preparing for uncertainty. Problems need to be solved in other areas outside technology sometimes. Thinking through problems, or architectural thinking in our situation as architects challenges us to reconsider the discipline of developing business applications.
We encourage architects to resist the temptation to adopt best practices that won’t benefit the organization or IT professional in the long run. There are so many excellent practices that only exist in name.
We think that architects already possess the qualifications and skills necessary to assist enterprises in addressing this challenge, and architectural thinking is a method for them to prove their worth and value to the company. However, architects must be careful not to unnecessarily restrict themselves by depending too much on some of their existing coping methods, such as:
However, each of these is incredibly successful as a coping technique since it enables architects like us to effectively think about and work on solutions. But the issue here is that if we acquire them through “muscle memory” without consciously evaluating the consequences, they are also self-imposed and can limit both the way we work and the outcomes.
To see clearly, you’ll need to open up more than just your eyes. Here are a few important ideas that help in changing architecture:
For instance, version 1.0 of your preferred software project, solution, or app is likely no longer available. That suggests that all business applications have undergone revisions. A revision shouldn’t necessitate a code modification. A code update leads to a new version or dot-release. Other methods can be applied to cut down on code modifications. Some of these methods start to come to the fore when dealing with uncertainty.