Enterprise architecture blueprint for utilities – part 2


“Bad choices make good stories.”

There is a famous saying “Bad choices make good stories”. What might be true in life, seems wrong for utilities’ IT or enterprise architecture. 

Part 1 of our Enterprise Architecture Blueprint for Utilities – “The Good, the Bad and the Ugly” discusses how bad decisions lead to huge technical debt, an Accidental IT or bad architecture. In part 2 of our EA series, I will focus on the good choices that make good stories and identify KPIs for good architecture. 

Related content:
Webinar recording: Piecing together the enterprise architecture puzzle

Good architecture

Whenever and wherever I discuss architecture with peers, clients, or partners in the sector, it only takes a few seconds before we philosophise about loose coupling, ease of integration, flexibility, adaptability, interoperability, elastic scalability, or cost-efficiency. It always reminds me of the good old times where almost every tender had a must-have requirement: “The solution shall have a good user interface”. I am sure you remember those endless discussions about what is considered “good”. So, let us try to be more concrete by defining what we mean with good architecture. 

If you were the pilot or captain of an “enterprise architecture” airplane or vessel – instead of flying blind or navigating in the dark – what numbers, figures, instruments or KPIs would you need to monitor in your cockpit?

Cost to serve: Instead of Total-Cost-of-Ownership (TCO), I’d propose Cost-to-Serve as KPI number one.

Marc Andreessen famously said that “Software is eating the world.” As utilities move more and more into analytics – and a data-driven future as well as a new generation of consumers that expects an entirely digitised on-demand user excellence, IT and data science has transitioned from being a supporting function to being a core business for energy companies. Instead of reducing the IT budget or cost, utilities will even increase their TCO. Therefore, the KPI to monitor should be the Cost to Serve for all grid and business operations. 

Speed of delivery: Speed is the new black. The future utility will have to adapt quickly to changing market regulations, changes in the energy system, new requirements and opportunities. Some of our clients have told stories where changing a few fields in an interface or adding a new service to an API took 6 months or even more.

Speed of delivery would be my second KPI. I would even go as far as to monitor the average cost per change, too. 

Media/Technology breaks in the value chain: Everybody talks about Digital Transformation or the Digital Utility. Everybody talks about the importance of automating and digitising business processes and the user experience/interaction. Many utilities struggle with media segregation leading to broken processes with multiple manual steps in the value chain. The number of these manual steps or “media breaks” (commonly known in German as Medienbrüche) where data must be entered several times or manually transferred between different systems or technologies would be another one of my KPIs. 

Dirty data cleansing jobs: Bad or dirty data today is already a huge challenge for many utilities. Moving fast into the new digital, analytics-driven future leveraging the power of AI and Machine Learning requires a high degree of data quality. As an initial KPI, I’d count the number of business or case management issues caused by dirty data that the organization have to handle and fix. 

End of life applications or technologies: Many utilities have built a huge technical debt over the last decades. Many applications are running on ageing technologies or antique platforms. Several applications have already reached their “End of Life” and vendors continue to announce they will discontinue support for those applications within the next two to three years. Monitoring those “End of Life” and “Soon-End-of-Life” systems makes total sense for me. 

“It’s not possible”: If I were an Executive or manager of a utility, I’d count the number of “It’s not possible” responses I receive from the IT department on my requests, ideas or requirements. Examples like it’s not possible due to missing integrations or interfaces; it’s not possible because it’s hardcoding, somewhere, deep in the code; it’s not possible as the data is not correct; we cannot handle the data volumes anyway; it’s not possible because the person who build the system has retired and traveling around the world.

Monitoring the number of “It’s not possible” instances might be a good indicator to track your architecture’s evolution.

I could continue my list of KPIs with

  • Number of security issues/breaches
  • Capacity of resources with required the competency/skill set to operate and management the IT landscape
  • Amount of overlapping functionality in different applications
  • Copies or replicas of data 

It would be great to have a discussion on the EA Cockpit for utilities. Possibly create a set of standard KPIs and benchmarks for the industry.

In the next blog post, the focus will shift towards modern architecture principles to drive the way forward to the Utility 4.0 future.


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.