The mission of this group is to bring together utility professionals in the power industry who are in the thick of the digital utility transformation. 


You need to be a member of Energy Central to access some features and content. Please or register to continue.


The Good, the Bad, and the Ugly: About Enterprise Architecture for Utilities

image credit: Image from the Movie "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.
  • Silo'ed 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 dive into the Enterprise Architecture Blueprint for Utilities (contact me or leave a comment to get access to it) and / or share your thoughts about bad architecture - good architecture.

Thorsten Heller's picture

Thank Thorsten for the Post!

Energy Central contributors share their experience and insights for the benefit of other Members (like you). Please show them your appreciation by leaving a comment, 'liking' this post, or following this Member.


Matt Chester's picture
Matt Chester on Oct 16, 2020 4:20 pm GMT

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”.

I'm curious-- do those running these see them ad problems, or are the suffering from the 'well we've always done it that way' syndrome and blind to how much more improved things could be? Put another way, are they actively seeking out solutions to their accidental architecture, or are you finding you have to point out that a solution is needed in the first place? 

Thorsten Heller's picture
Thorsten Heller on Oct 16, 2020 4:51 pm GMT

Interesting question.

What I clearly can see from the discussions with our utility clients: They (at least the CIOs, CDOs, IT guys and the enterprise architectts), have a rising understanding for the short-comings and challenges with this kind of an Accidental IT

Many also agree that they have built up a huge "Technical Debt" over the last years and that they have to get rid off this debt. Otherwise they won't be able to transform into an analytics- and data driven utility and the distributed energy system. Otherwise they are just a "Simply Wire Utility". 

But I also strongly believe that we need a shift of mind-set in utilities too to drive these iinitiatives faster and smoother. Many other industries have understood that IT, data and software is not longer supporting function, but has become core business (ref. "software is eating the world"). So I guess, we'd might need more IT and diital competencies in the utilities' executive management or the board room.

Would be great to get some inputs, feedback or thoughts from the community, too !

Frederik ten Sythoff's picture
Frederik ten Sythoff on Oct 21, 2020 12:26 pm GMT

I think we can all agree now that digital transformation is not only crucial for modern day business survival, but also critical for maintaining relevance in the energy sector. Other than a lack of resources and skills often mentioned, one of the biggest obstacles preventing the successful execution of digital transformations is reliance on legacy systems. This isn't a new issue for utilities, some 62% of IT leaders pointed to legacy systems as their biggest roadblock even some years ago. So yes, utilities are actively looking for solutions to this dilemma and finding a better way than depending on traditional system integration methods to build a customized solution with a lengthy, costly and high-risk integration project.


The good news for utilities these days is that there are options without compromise. Modern iPaaS solutions provide the platform where utilities can integrate their legacy and business critical applications and at the same time build or buy best of breed applications designed for all those new applications we all read about including AI, DER, EV or other customer-focused service innovations.

Jim Horstman's picture
Jim Horstman on Oct 22, 2020 7:06 pm GMT

Underlying the problem with the accidental architectures is the multiplicty of databases with multiple and sometimes conflicting views of the same objects. For example it is not uncommon for there to be multiple views of the electric grid or network. One in the GIS, multiple in various planning systems, a different one in the outage management or distribution management system and so on. This can result from both the use of homegrown applications as well as best of breed solutions. While the former may be 'tweaked' to start to solve the problem, the latter may cause greater problems. I will be interested to see if/how you blueprint addresses this issue.

Paul Korzeniowski's picture
Paul Korzeniowski on Oct 22, 2020 7:20 pm GMT

Interesting points. In the old day, IT was viewed as a cost center, so management's goal was to reduce its expenses as much as possible. Nowdays, it is becoming a conduit to business change, so it needs to be viewed more strategically by top executives. Some companies seem to understand that a change has taken place but many do not. 

Get Published - Build a Following

The Energy Central Power Industry Network is based on one core idea - power industry professionals helping each other and advancing the industry by sharing and learning from each other.

If you have an experience or insight to share or have learned something from a conference or seminar, your peers and colleagues on Energy Central want to hear about it. It's also easy to share a link to an article you've liked or an industry resource that you think would be helpful.

                 Learn more about posting on Energy Central »