Name our collection of solution ideas separately from our problem definition?

[michielbdejong]

It's sometimes getting a bit confusing that the term "Federated Bookkeeping" describes both a problem and our solution attempts for it.

Maybe we can:

1. define "Federated Bookkeeping" as the problem (i.e. "we want our computer systems to be connected but sovereign"),
2. discuss linked data and blockchain as possible solution frameworks for that problem
3. propose "the club" or some other name for it, as our solution

[mlesmenio]

1. I think "Federated Systems" are not the problem, but our solution to a problem of like "Centralized Systems" or "Vassal Systems", where systems lose sovereignty in order to be connected.
2. This is really important for presenting a better perspective into the issue and also explain the similarities and differences between those systems and federated systems.
3. I might be missing something here but isn't "the club" the same as "federation".

[michielbdejong]

I think "Federated Systems" are not the problem, but our solution to a problem of like "Centralized Systems" or "Vassal Systems", where systems lose sovereignty in order to be connected.

Hm, we could define our problem as "the mediocrity of existing computer systems" but I think that leads to a focus on negativity, of what is wrong with other people's work. Instead, "creating better computer system for the same tasks" is a more positive phrasing of the same thing, and then the computer system is a (good or mediocre) solution and the real-world task is the problem.

isn't "the club" the same as "federation".

Yes. But if we choose to make "federated" part of the problem description then it's a tautology to also include it in the solution description.

I'm not sure whether linked data and blockchain are also "federation" or not.

[mlesmenio]

Hm, we could define our problem as "the mediocrity of existing computer systems" but I think that leads to a focus on negativity, of what is wrong with other people's work. Instead, "creating better computer system for the same tasks" is a more positive phrasing of the same thing, and then the computer system is a (good or mediocre) solution and the real-world task is the problem.

I'd say something like "we are not satisfied by the current computer systems as solutions for (task X)" and explain why, but this sounds more of a marketing issue.

I'm not sure whether linked data and blockchain are also "federation" or not.

It will depend on the definition of federation, but at the very least they are precursors.

[michielbdejong]

we are not satisfied by the current computer systems as solutions for (task X)

Yes, or a little more broadly, we are not satisfied by some of the current work flows as solutions for (task X). Because copy-paste, pdf email attachments, and whole AP/AR departments tasked with aligning books between companies are so low-tech they don't even deserve the label "computer systems" :)

[michielbdejong]

I think you convinced me! I'm OK with "we are not satisfied by some of the current work flows as solutions for (task X)" as the problem statement. That makes sense, and this will resonate because everybody knows these work flows; we can describe task X and the existing human work flows for it in one sentence.

Then the problem statement is how can we make the human work easier by building good computer systems

And then the candidate solutions could be:

• monolith systems
• linked data
• blockchain
• federated bookkeeping

[mcalligator]

So I've been reading Gregor Hohpe's and Bobby Woolf's Enterprise Integration Patterns, and despite having been written nearly 20 years ago, there is an enormous amount of useful material in that book that will help us minimise the reinvention of wheels in this area. One of the points they make in the preface is that almost all software is written in isolation, without the explicit expectation of sharing data with other systems downstream. This indicates that those systems are by nature sovereign in themselves, but that there is a distinction between the systems themselves and the data within them.

[michielbdejong]

Thanks for the link! I read through https://www.enterpriseintegrationpatterns.com/patterns/messaging/toc.html and downloaded a PDF I found of the book. Its focus on messaging ties in well with the work @mlesmenio is doing in https://github.com/pondersource/CYB/tree/main/Design%20Information#logic-description where we concluded that webhooks are CYB's preferred way to read from a neighbouring system.

[mcalligator]

I would suggest that the most appropriate way to exchange data between federated systems will be context-specific. Webhooks have merit, in that the receiving system gets a notification telling it that information is available and what URL to use to retrieve that information. This helps maintain access control, in that the identity used to request the information from that URL is one that needs to be authorised to retrieve it. However, additional patterns (such as the Aggregator) may be necessary to bring data together from multiple source systems to compose an e-invoice, for example.

Another consideration is that of the semantics involved in field-mapping. The CYB link above mentions a set of mandatory common fields expected to be present in all participating systems, and a superset of optional additional fields. It is most important to be certain that the meaning of the metadata describing the information being exchanged is consistent between systems, and this is not addressed in Enterprise Integration Patterns, as far as I have been able to tell.

[michielbdejong]

the most appropriate way to exchange data between federated systems will be context-specific

Yes! Since all nodes in the network are sovereign anyway, all we really know is that we know nothing. :) We don't even know if we should consider it one network.

The CYB link above mentions a set of mandatory common fields expected to be present in all participating systems

Yes, this was an interesting conclusion, I thought we would end up with more a union format, but we concluded that to do any meaningful form of sync we did need to be quite precise.

Regarding the spectrum from problem to solution and how we describe that on the website, see also https://gitter.im/federatedbookkeeping/community?at=63c55a4a0cd40c2e89dae415