The Good, the Bad, and the Ugly

Enterprise Architecture Blueprint for Utilities - Part 1

This article has originally been published by Greenbird and has been reposted with permission.

“The Good, The Bad and the Ugly”

Some days ago, I was co-hosting a webinar on “Piecing together the Enterprise Architecture Puzzle for Utilities”. During our virtual roundtable, our guests including Klaus Wagner, (Enterprise Architect, Netze-BW / EnBW) and Rinse Veltmann (Director Solutions, Energyworx) discussed an Enterprise architecture blueprint for the Utility 4.0 future and highlighted specific related topics including:

• Challenges or shortcomings with this kind of an “Accidental IT”, that is quite often the As-Is architecture for many utilities.
• Strategies such as “Make vs Buy”, “Cloud vs. Data Center”, “Best-of-Breed vs. 1-Stop-Shop” or “Pull IT vs. Push IT”.
• Principles and concepts like Event Driven Architecture (EDA), API-driven development, domain driven design (DDD), cloud native, microservices and data mesh.

Our lively debate, in which the panelist shared their views on what was good and bad architecture emphasized: What characterizes a good or bad architecture? What does “good” and “bad” mean? Does “good”, “bad” and even “ugly” mean the same for all of us? And can we measure it? See it? Feel it? Or otherwise sense it?

Symptoms of a Bad Architecture

So let me start by sharing some of the typical indicators and symptoms of a bad architecture from my point of view:

• Monoliths determine the processes, routines or services, meaning the utility has to adapt the systems’ capabilities.
• Siloed applications offer no or minimal standardized integration capabilities and make entirely digitized processes impossible.
• Core systems are heavily customized and therefore expensive to update or upgrade.
• Custom built or developed solutions serving “commodity” functionality (i.e. CRM, ERP, etc.).
• Critical solutions need special knowledge or expertise to operate, manage or adapt and create vendor lock in.
• Black-box applications nobody (internally or externally) wants to touch anymore as no one knows how those work.
• Adaptions (i.e. some new fields in an API) take several months, are costly and slow therefore down innovation.
• Applications provide overlapping or competing functionality and lead with that to inconsistent decisions, processes or data.
• Systems have been thickened, meaning new requirements are always realized in the same application by the same vendor, even the functionality would have belonged into the domain of another.
• Underlying infrastructure (i.e. storage, messaging, integration) cannot be scaled elastically or require substantial investments to meet the upcoming requirements to handle big energy data in almost real time.
• IT landscape is built on a huge variety of (partly aging) technologies, different (maybe antiquarian) architecture styles or (old-fashioned) proprietary integrations create enormous operational complexity and fragility.
• Each solution or system uses different mechanism to manage security or data privacy and its own logging & tracing framework.

Working with utilities, we sometimes meet an IT landscape that has evolved (or even mutated) over many years with lack of architectural management or strategy. That is what I call an “accidental IT” or “accidental architecture”.

Accidental Architecture or Accidental IT

A system of siloed systems:

Defined by business units’ specific needs and preferences for a given solution or vendor,

• i.e. a cloud and web-based CRM for customer service, but a on-premise classical client-server GIS implementation

Often centered around some big monolithic applications,

• i.e. CC&B (Customer Care & Billing)

With many manual, batch-style or file-based integrations,

• i.e. file based meter reading exports from HES to MDM and from MDM to CC&B,
• i.e. manual synchronization for metering point info in MDM and GIS

With unclear, random or accidental “separation of concerns”,

• i.e. VEE for profile-based meters done in the CC&B and VEE for smart meters done in MDM,
• i.e. Asset management for meters / metering points done in CC&B, asset management for grid infrastructure done in GIS

There might be by far more symptoms or examples for “accidental IT” or “The Bad, and the Ugly”. But it is more important to think about, how to fix and how to handle the shortcomings.

Therefore, my next blog posts in this EA blueprint series will focus on “The Good”. What is “good architecture,” how can we measure it and establish a set of architecture KPIs.

In the meantime, feel free to read our e-magazine on the Enterprise Architecture Blueprint for Utilities and / or share your thoughts about bad architecture - good architecture.