Enterprise Architecture Blueprint for Utilities Part 1

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

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.

At Greenbird, we work to simplify the complexity of big data integration for utilities to kickstart their digital transformation. We have put together an e-zine with articles which speak to these questions. Download the digital magazine to get more information on enterprise architecture, the build vs buy debate, understanding the digital integration journey and how to simplify the IT/OT relationship.

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

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 or random “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. Ready to Read part 2?