Chris Conway
Chief Architect, Quantiv
I’ve had several discussions recently about the need to allow data in one system to be used to control processing in another.
These conversations have involved both developers and designers but what’s striking is the differences in approach of the two groups.
The developers’ viewpoint
Unsurprisingly, the developers (software engineers) leaned towards solutions that solved their immediate problems. All of them were senior, so they weren’t being distracted by what was ‘in vogue’, but they were instantly reaching for notification services from Microsoft, Amazon Web Services and a specialist supplier.
Discussions around persistence, granularity, structure and semantic meaning were less important than how an immediate solution could be produced.
Deep functionality (i.e. knowing exactly how the specific problem would be solved) was critical, closely followed by familiarity. Documentation and supportability were also important.
I understand this intimately. I know too many developers who have found themselves using an unfamiliar, undocumented product, which they become experts in after multiple hard-won lessons.
In doing so, they’ve found themselves pigeonholed as the only developers capable of supporting the solution. That means they’ve been lumbered with responsibility for it for its entire lifetime, or until they leave.
The designers’ perspective
The designers (solution architects) also favoured solutions that solved their issues.
Again, all of them were senior, so they weren’t being led by the latest trends. But in contrast, they were more concerned about the solution context than the actual tech.
Wide functionality (i.e. knowing how the solution would affect other systems) was more important than the nitty-gritty of the implementation. And the non-functional perspectives were also different. For them, traceability, auditability and repeatability were key requirements.
It seems the major technical difference between the developers’ and the designers’ approaches was the level of data persistence.
Data in transit
The developers favoured messaging or notification solutions for handling data ‘in transit’ between applications:
- These generally provide limited long-term persistence, with the most you can hope for being that messages get logged.
- This storage is often more aimed at supporting a limited number of specific/known uses. These uses include diagnostics, fault-finding and monitoring, rather than more general querying, sharing and usage.
Data at rest
Designers, however, preferred solutions involving data ‘at rest’ at one or more points on its journey between applications:
- Preferences were for solutions providing at least some data visibility.
- And this visibility would ideally support data sharing (general querying) and governance (change management and access controls).
Both approaches have their place…
- Messaging solutions: provide simple, accessible and scalable ways to move data between applications. Agile messaging solutions will outperform more ‘fussy’ data-storage approaches when used in circumstances where the source and destination are more important than the route.
- Sharing solutions: provide robust services to allow applications to use data collaboratively in a repeatable, auditable and traceable way. More robust sharing solutions will outperform looser messaging when used in circumstances where the route taken by the data must be known and provable.
Which approach should you use?
Choosing between messaging and sharing may seem difficult. After all, familiarity and agility always feel like good things, but who could argue against robustness and collaboration?
Messaging will usually be your best option if the data:
- Only has value within the context of another application
- Is effectively moving in a single direction
Sharing, meanwhile, is probably more suitable if the data:
- Has value in its own right
- Can be updated from both directions
NumberWorks and NumberCloud
Quantiv’s NumberWorks method helps identify situations where data sharing is important by defining the data associated with critical points in a system or process. And our NumberCloud service is aimed at ‘sharing’ data in those situations, ensuring solutions are traceable and provable. Plus, these services allow the collected data to be used, and updated, in a collaborative solution architecture.
So, while messaging applications have their place, we aim our services squarely at supporting data sharing.
To find out more, talk to our team today on 0161 927 4000 or email: info@quantiv.com
