Winds of Change Copyright (c) 2024 by George L. Willis. All rights reserved. When I first started to work with a large eastern US utility over a decade ago, there was a large gathering where I asked a member of senior management if the utility intended to internally develop any of the SCADA or Grid Control ICS software they wanted to deploy, as my background was in large scale software development and architecture. The response was simple -- "We are not a software company. We prefer buying over building." An understandable policy which has been adopted by many utilities. So we bought a DSCADA and ADMS system for two different regions from a large vendor, went through a disappointing FAT where system scale and performance were below promises (SLAs), and remember saying to the OT lead on the project who was very upset -- that given the timeframe for federal reimbursement, victory would be declared in the face of disappointment. Recently in dealing with another major utility in the Northeast US, I was made aware that they were unhappy with their current ADMS system, and were moving away from their current vendor. They had looked at other offerings, but were not impressed with any, given the current issues that distributed solar generation and energy storage were bringing to the forefront. The age of large scale DERMS had brought another solution as an option -- "why don't we build our own?" As daunting as the task may seem, there are many good reasons to consider developing an open architecture on standards that favor integration of components, or as Gartner has named it "Composable Business Architecture". I wish to discuss SmartGrid Industrial Control Systems (SG-ICS), where past solutions have missed the boat, and what enablers we have a decade later that are leading to the option of integrating best-of-breed offerings with internally developed components to tackle DERMS at scale.

Why use Event-Driven Archtecture (EDA)? [color=blue] We have a dangerous misconception in distributed computing. We started doing something that was fundametally wrong, and we haven't stopped -- like lemmings off a cliff. Let me explain. All modern day processors require RAM or "cache" to process code. We divide or "map" RAM into 3 regions: Static or Global Variables that live during the lifetime of a process The "Heap", where relatively large things of an indescriminite size are temporarily stored

[name=George Willis, Founder of OpenLedger] What is a distributed ledger (blockchain) vs a distributed log? If they both store entries into a journal of record in an "append-only, no eraser" fashion, just like an accounting ledger, what is the difference? If Serverless (see CNCF Serverless Landscape) and Function-as-a-Service (FaaS -- IBM Cloud Functions, AWS Lambda, Google Cloud Functions, Azure Functions, etc.) can ++react++ to data streams, isn't all of the above "Data-Driven" or "Event-Driven"? If a distributed Key/Value (KV) store like AWS S3, Apple FoundtionDB, Snowflake, Couchbase, Yugabyte, Cassandra, etc) (or any distributed SQL database for that matter,) is used to store ledger entries, and triggers on insert used to "react and invoke processing", doesn't this yield the same mechanism? In all above cases, we can add entries to a "ledger", which trigger processing with the entries as input. It's all data-driven "reactive" processing, right? If so, could an Open/Interoperable Framework be created with "plug-n-play" adapters for various "ledger technology" one wishes to leverage, so that ++capabilities++ like **++storage, distribution, and "reactive invocation++" of "entries" could all be handled by configuration of these technologies, and developers could just code to this standard API/Framework? This would allow switching providers of these capabilities for any reason -- cost, performance, consolidation, evaluation, etc. -- ++without recoding!++

What problem are we trying to solve? ++Interoperabilty++ amongst Event-Driven, Change Data Capture, Distributed Log, Distributed Ledger, Distributed Storage, Local Storage, Consensus, Programming Languages, Operating Systems and Event Schemas. In 2017, Gardner declared that the biggest obstacle to Event-Driven Architecture (EDA) adoption was "Event Thinking". Today, this was not the biggest obstacle in EDA adoption. Today, the EDA marketplace is flooded with offerings in Messaging, Pub/Sub, Function-as-a-Service, Serverless, Streaming, Change Data Capture, Distributed Log, Distributed Ledger, Distributed Storage, and Local Storage -- from Apache, Solace, IBM, AWS, Azure, Google, Salesforce, TIBCO, Confluent, Akka, etc. -- ++and they each have their own EDA APIs++! Compounding the marketplace are these truths:

Topictopic.pub(datastruct) // publish a msg, payload, event, dataTree, context, blob,etc. topic.sub(topicMask, agent, actorInvocation) // Agents work on behalf of Actors to provide "fast reject" capability and standardized filtering. Agents invoke Actors. Ledger ledger.host(topic, parentTopic) // Ledgers host Topics ledger=Ledger::new(scope, name) // Host a Ledger within a broadcast Scope Event

 <iframe width="150" height="99" src="https://www.youtube.com/embed/i4njPe2_rho" frameborder="0"></iframe><p><p>Wolfman Jack says:<p/><p/>"Don't call us.<br/>         We'll call you." [name=Author: George Willis] [time=Thu, Apr 19, 2018] What is the Hollywood Principle? An "Inversion of Invocation" design pattern (for those familiar with the IoC design pattern.) ::: info :trophy: Transform "<u>Explicit Invocations</u>" into "<u>Implicit Invocations</u>"

The Problem Problem 1: Lack of Interoperability/Portability Almost all streaming/ledger/storage technology have a proprietary, non-standardized API. (SQL DBs being the notable exception.)[color=blue] This leads to: Costly and lengthy rewrites to migrate applications across clouds, stacks, and APIs "Lock-in" to a particular offering/vendor and license fee structure "Analysis Paralysis" around selection and long-term commitment Wealth of choices including Kafka, Pulsar, Redpanda, AWS S3, Cassandra, Redis, FoundationDB, Couchbase, Riak, RockDB, CockRoachDB, YugabyteDB, AWS Lambda, Google Cloud Functions, IBM Cloud Functions, Azure Functions, OpenFaaS, OpenWhisk, Ethereum, Cardano, Komodo, HyperLedger, Raft consensus, and over 100 more...

[color=blue] 12v DC Systems [ ] Batteries[ ] Deep Cycle [ ] Lithium Ion [ ] Disconnect [ ] Panel