What does "Design for Uncertainty" really mean?

Design for Uncertainty" is one of the key IT architecture principles for utilities and most other organizations undergoing digital transformation. Enterprise architecture and system integration provide an important cornerstone to enable you to manage uncertainty, react quickly and smoothly to changing requirements and easily adapt to new market opportunities. Some of the key elements for a modern integration approach include loosely coupling, API first / API driven integration, dynamic or elastic scalability, support for both synchronous and asynchronous message exchange patterns and use of open standards. Luckily, many modern and future-oriented utilities understand why they should avoid point-to-point integration and leverage therefore an Enterprise iPaaS (Integration Platform as a Service) such as Utilihive or an ESB (Enterprise Service Bus).

But still, the question is how to design an IT architecture for uncertainty. How to design an IT architecture that can handle a sudden rise or dip in the data volumes to be processed. How to design an IT architecture that supports digitized processes and new data-driven services in shaky market conditions including changing regulations and unstable circumstances.

"Design for Uncertainty" means:

• Modular architecture: You should design your application landscape with modularity in mind to ensure flexibility and adaptability to changing requirements or opportunities. The time for the dinosaur monoliths (e.g. Customer Care & Billing, ERP, etc.) is gone.
• Open systems: You should opt for applications and services providing open interfaces or standardized APIs to ensure interoperability. Those antique closed systems lock your data in silos.
• Real-time or online data exchange: You should implement systems that support real-time or online data access and exchange to enable digital processes. Those ancient systems that only support batch-based data import and export prevent you from automating and digitizing processes across the value chain.
• Event Driven Architecture: You should design an Event Driven Architecture (https://en.wikipedia.org/wiki/Event-driven_architecture) and focus on implementing applications supporting EDA principles to ensure flexibility and ensure that you can tackle increasing complexity related to processes but also changing data volumes. Those outdated workflow-focused systems and integration solutions will be too complex to operate in an effective way.
• Cloud-native technologies: You should strive to chose applications built on modern cloud-native technologies to ensure that you have operational flexibility to deploy the solution both on public cloud, private cloud or your local data center. Plus, that your solution can scale for future requirements. Those old-style systems that run on an outdated technology stack (i.e. Windows Server, relational databases, etc.) create unbreakable technical limits for you to scale in the future and to adapt your operations model to regulators' requirements.