“Speed is the new currency of business”
“Speed is the new currency of business,” said Marc Benioff, Founder and CEO of Salesforce, during a panel discussion on innovation at the World Economic Forum in Davos in 2016. We could now start a huge discussion to question the meaning, purpose, and true impact of an event such as Davos. Let us rather stick to our field of expertise where we can influence and make a difference: Enterprise Architecture for Utilities.
The first three posts of my Enterprise Architecture Blueprint series focused on technical debt, accidental IT, KPIs for a good architecture and proposed some important architecture principles. In this post I will move on to discussing IT strategy, starting with the concept of a “Pace Layered Architecture”.
More articles from Greenbird
Webinar recording: Piecing together the enterprise architecture puzzle
E-zine: Utility 4.0 and next-gen enterprise architecture
Pace Layered Architecture
With all ongoing changes shaking up the energy industry, I think we all can agree that utilities must modernize their IT to keep up with the pace of disruption and innovation in the market. In an ideal world, utilities would just get rid of all legacy systems, throw out all the old-fashioned monolithic applications and start from the scratch with a greenfield approach to building a modern, containerized, cloud-native, API-driven IT landscape. Yeah right. Reality bites.
Utilities are operating critical infrastructure and provide critical services to all people and society as a whole. They must, at least from an IT perspective balance security, resilience, reliability, stability with innovation, agility, and speed of delivery.
In 2012, research and analyst company, Gartner, coined “Pace Layered Architecture” as a concept for a multi-speed IT.
Gartner defines its approach as follows: A pace-layered application strategy is a methodology for categorizing, selecting, managing, and governing applications to support business change, differentiation, and innovation.
For that, Gartner introduces different layers of software applications where each layer contains common characteristics related to speed of adaption and change:
Systems of Record: Packaged applications, typically Commercial Off-The-Shelf products (COTS) or legacy homegrown systems supporting your organization’s “commodity” business capabilities, handling core transaction processing, or manage your reference or master data.
As your core processes and capabilities do not change that often, are common or “commodity” to most of utilities, and in addition are often subject to regulatory requirements, the pace of change is quite low.
Systems of Differentiation: Applications that support or enable the unique business processes for your organization or utility-specific capabilities.
Those business processes do not change daily. But still, you want to streamline, digitize, automate, or optimize processes or business functions occasionally. You might introduce or leverage new technologies, too. So, still the pace of change is not the highest nor the slowest.
Systems of Innovation: New solutions or services that are built on demand to address new business requirements or opportunities. With a lean startup mindset, solutions in this layer usually start with an MVP (Minimum Viable Product) or PoV (Proof of Value) that is iteratively improved based on users’ feedback towards a production ready service.
This layer is the fast track or fast line for innovation with a high rate of change, high pace of delivery and short project lifecycles.
The concept of a pace layered architecture looks like a perfect answer for utilities’ challenge with balancing resilience, reliability and stability on the one side and the required agility on the other side.
Considering all the enormous changes in the industry with new players, changing regulations, disruptive analytics services, emerging technologies, etc., I’d personally prefer or propose a slight modification to establish a pace layered architecture for the digital utility.
The “Pace layered Architecture for Utility 4.0” adds some specific layers with defined characteristics:
System of Connectivity: A modern data integration layer based on the concept of an Event Driven Architecture (EDA) and reactive microservices handling all data flows and data exchange between all the Systems of Record and between the layers to establish the entirely digitized operational and business processes that define the Utility 4.0.
System of Intelligence: A big energy data management and analytics infrastructure layer used to deliver the cognitive capabilities for the Utility 4.0: Smart grid edge analytics to create insight and transparency in the network, intelligent grid operations, asset health, predictive maintenance, demand / load forecasting, EV charging optimizations, identification of abnormalities and more, are just some examples of the cognitive use cases.
System of Engagement: A digital user experience layer providing the services and digital excellence both the digital native consumers expect but also the utilities’ employees need to handle the huge amount of data.
I feel fortunate to have been given the opportunity to implement this architecture model as the foundation for a big transformation program at one of the “Big Three” utilities in Germany.
Introducing the “System of Connectivity” highlighted the value of a modern data management approach and set the spotlight on the importance of the “dirty job of data integration”. Placing the “System of Intelligence” at the center of your architecture fosters the cognitive capabilities the future utility needs to achieve the sustainable development goals and business objects. Plus, the “System of Engagement” improves the digital user experience for the end-users, meaning for you and me as consumers or prosumers. But maybe even more importantly, as more and more data is digested in real time to drive faster insights and decision-making, this applies to utility employees too.
In my next post, I will continue to develop the concept of a “Pace Layered Architecture for the Utility 4.0” and dive into some strategies such as “Make vs. Buy” or “Cloud-first vs. Cloud-Native”.