Chris Conway
Chief Architect, Quantiv
You could easily imagine the people behind electricity grid operation are jostling for position at the front of the queue for artificial intelligence (AI) services right now.
Quite how a fixed quantity of power can be shared by a variable number of users with variable demands has always seemed like one of engineering’s black arts to me (and I have a background in this area). The closest thing to magic, you could say.
Even with AI support, I still feel for those involved in managing national electricity demands. Power management may include some, though not enough, mechanisms to help balance supply, but there are precious few ways in which short-term demand can be changed.
And the vagaries of renewable energy, both in terms of availability and type of power generated, mean the problem is even more complex.
Even so, when electricity somehow arrives and appliances work, it can be all too easy to think these are just simple services.
The Spain and Portugal blackout
Spain and Portugal’s recent electricity blackout served as a timely reminder of the complexities involved in power supply.
And while we don’t yet know the root cause of the widespread outage, what was especially surprising was the extent of the disruption. You might expect a failure of a piece of equipment to cause local problems on a small scale, or even more widely if the equipment was significant. But what was astonishing was the whole Iberian Peninsula was affected.
My first reaction was that surely the system should have been designed not just to include redundancy but also to be partitioned so a problem in one area couldn’t spread to another. Indeed, the words ‘grid’ and ‘network’ suggest that should be the case.
Of course, it’s possible such isolating techniques were in place but also failed.
However, it occurs to me that perhaps the simpler explanation is the lure of centralisation proved too great. Often it can seem wasteful to use multiple components when a single one (albeit with backup) will do. And besides being cheaper, having a single component makes management easier because everything’s in one place.
The growth of monolithic applications
IT solution design has also been seduced by the attractions of a single system. In the early days of computing, designers had little choice but to do what a single component would allow. Then, as IT became more capable, systems got bigger, with the result being ever-larger ‘monolithic’ applications. And while initially those systems also exhibited some of those centralisation advantages, over time they proved inflexible.
This led to an inevitable backlash, with systems then being composed of many small services. And while this approach offered the benefit of flexibility, it also proved extremely complex to manage, as well as fragile.
Finding the middle ground in solution design
As with many things, the ideal solution proved to be somewhere in the middle, with systems being composed of a moderate number of medium-sized components (applications).
That middle ground has become established in terms of system components. However, it still feels like there’s a tendency towards monolithic system data.
Even if those separate applications manage their own immediate data, often it’s amalgamated into a single, very large database. If this is only used for reporting – and especially for allowing connections between different activities to be identified – then it doesn’t necessarily affect the overall system design. That said, it can still impose artificial external constraints on changes in individual applications.
Be wary of unintended dependencies
If the use strays beyond reporting, and into applications using each other’s data for their own operation, there’s a danger of unintended dependencies being introduced. In effect, that monolithic data has resulted in the creation of a monolithic application by the back door – with all the associated problems.
That isn’t to say it’s wrong for applications to use each other’s data. Some interactions are inevitable.
But what it does means is care is needed in how that data is used. Sharing data is usually preferable to copying it (which is almost the rationale behind the monolithic database). However, the way in which data is shared should be carefully controlled. Instead of simply exposing all data from all applications, only data an application is prepared to share should be exposed.
This means the applications need well-defined information boundaries. For example, producer applications should decide what data they wish to share, while consumer applications should decide how they intend to use that data.
And if any integration technology is used, it should just support data exchange and shouldn’t provide any interpretation.
Sharing information, the right way
Using this approach means information can be shared between applications without creating an absolute monolithic database. This means producers and consumers have minimal dependency on each other, while information is exposed as widely as possible.
Sharing information in this way also has a beneficial ‘reporting’ side effect because information shared between applications often provides a good indication of the information needed to monitor those applications.
Not only might such an approach prevent things going wrong in the first place, it might also help provide an early warning system for when they do. Plus, it could even help prevent the spread of an issue.
How NumberWorks and NumberCloud can help your organisation
Quantiv’s NumberWorks method is specifically designed to support the exchange of your data between applications in a standardised way.
Likewise, our NumberCloud service supports that cohesive model by allowing data sharing without creating a monolithic database.
Contact our team today on 0161 927 4000 or email: info@quantiv.com
