Two milestones deliverables document, and, as I understand them. In the workgroup of communication and with milestones document doesn't have a communication section.
Oh, yeah. So, let's look at that. That's a good question. So I think technically. Uh yeah, there's no messaging in there. How about that. Okay. Well, so, um, yeah, so I'm just going to make a copy. I'll make you your own tab, and call it messaging. This is not really this is kind of Ramkumar thing. But now you've got, you got your own tab and I'll move you're right next to workflow. Yeah. Thank you. Yeah. Cool, thanks for bringing that up. Sweet. Okay and then just to make it a little bit easier on you, Martin. I will just go ahead and share my screen. I don't know if that really helps, but then you're not like trying to open google docs on your phone or whatever. Okay, so. Oh, bummer Ramkumar is not gonna make a he's not feeling well. Okay. Um, well we'll see who else can make it, um, not everybody needs to be here. So I can give you guys more personal attention which is good. Um, so let's see. So, I guess, um, oh let me also open up the meeting minutes, and just get that going. Turn this off. Okay, And so do you guys have your own folder set up, or your own Google Drive, set up like your own folder.
Not really.
Okay. Well, at some point, I mean you might, you might want to do that, you know, this is just. So just to show you we have this like, this is sort of informally evolved right you don't have to do this but we have this top level gov stack root directory, and inside of there there's links to all the folders for other groups. So, including the architecture group. And then this is sort of, we've got all of our stuff in here, like from the beginning, right, is, is, is right there. Then we have a folder for minutes. This is just kind of how we do it. Um, So, and then we've been using Google Docs. So I mean, I, you know, I'd encourage you to probably do the same thing. Or at least consider it. Because it works pretty well like I was having this debate with honey. And one thing that's really great about Google Docs is it's super easy for anybody to get in there and comment. Right, or suggest edits as opposed to like GitHub or something like that, it's just super accessible to people, especially if they're not technical. So that's why we're kind of recommending that people use, you know, Google Docs or you can use teams if you want there's teams available but teams is just pretty painful, honestly. So, okay so what else so we got your so you guys have looked at this, I mean one thing that we can do is go through, but we might want to wait and see if more people join is go through and go through this list of deliverables and see if it makes sense to you. But this is sort of, so this this milestone deliverables, is intended so I'll just show you one that's kind of like more filled in. It's intended to show, you know, what's done when it's when the things that aren't done yet, or, you know, might be done like estimates, and it's just sort of an informal way that we report, you know, progress to the steering committees and whatnot. Um, there's also, you know like in here we can see there's like a timeframe like we put these estimated timeframes in and I don't know if this is realistic or not but, um, so, you know, under the architecture tab. Our stuff we don't really have like these timeframes, we don't have like the same deliverables. So we tried to put in estimates that you can use but I mean again everybody takes they go at their own pace, I wouldn't stress out about it. And then your deliverables everybody your, feel free to make new deliverables if these don't make sense or add deliverables, you know, whatever. But it's just to try to get some. So this is rom Kumar thing to try to get some visibility into progress a little bit early for you guys probably. Um, okay, so, yes. So what other questions can I answer for you. There's like the worker cookbook and this building block definition template. Have you had a chance to look at those.
I've looked at some of them. I've gone through them and nothing in high detail but
what one thing that I can think of right now is, there was something said about logging audit logs, right and business wise there is no question, I just want to clarify, when we talk about deleting data, it's, it goes away out from audit logging, but the when we talk about deleting data from databases. When this is just a note to consider, but when I develop my systems, I don't even allow systems to use update or delete commands. It's just writing new data and using the last one is how fixed are we with technical solutions and architectural solutions. What I just describe it suits for me but I'm pretty sure that we will use it in this use case, but in general, what are our, what, how much can we demand.
Okay so these kind of these are just examples right. So, these 42344 are just examples so. So, you're free to make the right, you know what you think the best architectural decisions are for messaging, for sure, right, provided that you know I mean in this thing, provided you know. So, in terms of audit logging like if you if you aren't going to allow records to be updated or deleted, then maybe that's less of an issue, right, because the records are just always going to be there. Which makes sense for messaging, actually, because you want to preserve the history. A lot of times, yeah. Um, so that's fine. So I would just these are just meant to be examples. And these, these are specifically, you know, so So there's two sections here there's like this, you know, these key digital functions I would definitely start out here. And again, these are all just examples right, but they are intended to be core and required functions, the building block has to be able to perform. Right, so definitely start here and they should be like spelled out in plain English, not as, you know, technical code. These cross cutting requirements are really. So, uh, Let me just add a link, actually. So, these are really more meant to call out
and non functional requirements.
Alright so let me just make this a link so you know, so that's a little more clear. So, the the thing is like this, this document here I don't know if you've seen this yet, I mean I think I pointed it out. But these are, you know, requirements that all the building blocks have to follow right. So, you know, for instance, if you, you know, if you have a really good reason why you can't use a TLB top 25 language, then you could just list that here, right, and say like, oh, you know, or if there's specific, you know notes about how these requirements like must be applied. I mean most of these are pretty sensible right but, for instance, a lot of people have this issue, where we say you know we say databases must not include business logic and you can see there's some controversy here. But the idea is that we want to keep the business logic in the code, as much as possible. So, if you have a good reason for the why you must have why you really think it's better to have business logic in the database. For some reason, generally I think that's a bad idea, but for example, then you could say, okay, you know, uh, you know, I'm gonna, you know my databases, you know,
something odd to said, deep into my expertise is when you save the business logic has to be in source code. I go step further. I cannot honestly say that I've been working for governmental projects for three and a half years and I haven't had any projects that have business logic in anywhere else but the configuration files text based configuration files Yamo files that JSON files. Yeah, yeah, I
mean, that's fine right that's a step forward. Yeah, yeah I think so. So I mean, but the general idea is like if there's something that you like that especially applies like Right. You know, much, much, I use a shared database file system, and memory right like you have to do interconnections, or API's only. So, if there's some reason that you disagree with this, or it really doesn't fit with your architecture. This is kind of a place to override that and say like well, we're doing something different and here's why. Otherwise it's kind of the,
when when we say but we can't contain, but the system can contain business logic in databases when that's not a problem there would never do it.
Yes, right. Exactly. Yeah, when we talk
about DOB indexing, we have to define it's always something that I say that okay I'm currently seen with trustees number 26 Yes, Carla 30 hazchem 35 to.
Scala is 30
Yes.
Oh bummer foodies. Yeah, so, you know, I mean if you're like, oh well, you know, cuz I used to use Scala a lot and it's actually quite good so if you have a reason that you want to use Scala then you just like, say, oh well I disagree with this, because, you know, Scala is perfect for this use case and it actually is quite good for messaging, probably it's like, you know, yeah, for example, right so I mean, you should be like following, I mean all this stuff is like these are just like basic guidelines, I mean, sensible, what I think. And what we've arrived at or what are like sensible architectural decisions like, here's another one like be asynchronous first what like what does that even mean, right. You know you might have some reason where you can't do a synchronous, you know, where you're not going to support because we have this publish and subscribe feature that we're really trying to get the building blocks to adopt but, you know, actually this is probably poorly worded right like you're always gonna have a synchronous API first,
What, when you mentioned in a Pub Sub. Is it somehow related to our messaging or communication workgroup, or not. Applications.
Well, it's it's for all the workgroups, so I'll show you exactly what I mean. So, if you see, so I'm just going to show you like that. So another aspect that you probably want to come on. What is going on that you probably want to review is this information mediator specification. Cuz this is sort of like the, this is what's going to connect all the building blocks together. Right. So this is a basically it's it's like, it's very similar to x road, but it has, You know, the ability to, for example, it has this notion of, you know, dealing with a web hooks and then it has a certain like flavor of publish and subscribe right. So it's sort of built into the, the mechanism that other building blocks could use to communicate to each other, is the idea. So, I mean, III mean so there's I'm sure you guys like you're familiar with X rooms, right, I mean, you guys pretty much prototyped it as far as I know, yeah, that's why. Yeah, exactly. So we're trying to like this is our attempt to try to build, you know, something that like we're not saying like, I guess you guys use Kafka or whatever. So we're not saying what the technical. Oh, you didn't. Okay, somebody told me that,
but it. You mean extra notes,
no, no for the for the for crop, AI, like that. Okay,
we have Kafka, we considered it but Kafka has some. It's not really stateless, if you use a lot of, if you have a lot of indexes of information, and it's not stateless A you can have the turbines for like 10 or 20 seconds when you update their indexes and it's, it's, it looks good, in most cases it's great and, but we do something different.
Right, exactly, well so we're doing something different here too and this is kind of in flux, but the idea is that essentially, we'll have like a modified publish and subscribe where you can, it's built into the security server of, you know, or the equivalent of a security server, where you can subscribe for a type of message and then be notified. So there's this basic design and we're sort of, we've been debating it a lot, right, how this is going to work but that's what this means right so we want the, I guess what I'm trying to say is we want people to at least consider, if you can send events, Then you should, you know, consider building those events into your building block right.
And then, with this link. In restrict. Yeah, sure. I didn't tell you,
the architecture blueprint, okay yeah I was just like trying not to overwhelm. Oh okay, okay, cool. Yeah, so, uh, yeah, exactly. So that's it for this information mediator. So, yeah. Okay, so,
uh,
oh, you have to use it for communication between building blocks. So, um, yeah, so that's like one note, you have to use it. And then we're, you know, we're trying to build this Pub Sub communication layer so you know it'd be really good to get you actually your reviews on this because you've got a lot of experience right. But, you know, but it should be kind of familiar to you, kind of working the Estonian government.
Right. That's not something that's familiar.
Okay, cool. All right so, well it's still just you guys. Alright, we'll see who else joins, um, So anyway, that's just an example right so, and the theory is like this all support occasional connectivity and low bandwidth better, right. Except, I think maybe our publish and subscribe system is just ephemeral like there's no message queue, right. So if you miss a message I don't think you're going to get it if you reconnect later. So, anyway, but, you know, like you have to be autonomous, right, so for instance like the payments building block might require an external payment gateway that's like, you know, run by a bank or more by a third party, right, because it doesn't necessarily make sense for government to run their own payment gateways like what's usually Yeah, so you might, you know, they might have an exception where they're like, Oh, we're not autonomous because, you know, it doesn't make sense, we have to have like, we have these dependencies on third party payment gateways. So, does that make sense like this sort of like, Absolutely, no. Okay. Everything is good. Okay, cool. So yeah, in general, I would just start like listing out the requirements right, and in general, you know, so start here, we'll start with your description right but, you know, the the key digital functionalities is really like this is the key. It's like what are the business, you know, processes and one of the business. One of the functions, you know, what are those functionalities I need to be there. In order for this to work right. And sometimes it's helpful to go look at, you know other building blocks like, you know, these guys, you know, it's a slightly different format we've improved the template quite a bit but you know they've got their
building blocks, use the same template. Correct.
Yeah, I mean we're trying to Yeah they do. Although, but this is an older version right so it doesn't have the nice numbered headers and whatnot so it's, it's, but more or less they all have the same structure right they start out with these key functionalities, there's a, you know, a section for terminology which I hope is in here. No, I don't think we put a section here for terminology, maybe we should add one, but anyway yeah I mean, they all follow the same structure of having the key digital functionalities across cutting requirements, functional requirements and then getting into data structures and then API design and workflows, right, so another thing that's super important is listing, you know, major decisions that you've made. Okay, yeah, just like with date, you know like we decided to, you know, uh, yeah, go in this direction, and here's why just this is mostly so that when people in the future join your group, or join the group, like they understand why you arrived at the decisions you made. So, you know, just for major. Yeah, just four major decisions so people can get caught up, because these documents are gonna like, they're, they're gonna evolve over time. So, okay so other questions
right yeah it should never run it the concept of how the whole concept of building blocks is very, very clear to me when I develop my own systems, I have these standalone components or building blocks, basically, the two just just matter, the one thing, and nothing else. There's no business logic, and this one here is pretty much the same. British security building block core section I don't know how to say it but how does it comply with our building block to have to take some requirements from security workgroup, or is that some kind of technical layer that is like a firewall of attempts of attacks and so on.
Right, so the security part over. Yeah, so this, this PDF here. Let's see. Go to like the building block definition PDF file. And the reason that we use a PDF file is because it refers to a specific version. Right, so this security building block is different from the other building blocks, specifications, is really different. Right. But the main thing that you have to pay attention to is making sure that you, you meet all the cross cutting requirements. Right. So, you know, privacy, audit logging source code and security, you know, I guess these are really kind of like not optional. Right. So forget what I said earlier, so we've already listed them here for you, right. So, if you know if you can't do these for something some reason you definitely need to say why. But right privacy audit logging source code so I mean it's pretty sensible stuff right. But these security are private, so, so, you're supposed to list any of the cross cutting security requirements that don't apply. Right. So, you know, for example, you know, some of these are sort of some of these are sort of more like deploy time. Like runtime things right like fully controlled Endpoint Protection well I mean he probably, you need to do that right so you need to make sure that your building block is architected in a way where it's autonomous and secure as much as possible, you know that you've got the information mediator to protect you. And then the, the other thing is security building block provides is there's some functional components in here. It's not really obvious but there's like an API gateway that you can use, right. So you can use this module of the security building block inside your inside your building block if you want to. Right. Or you could use, you know your own kind of security but, you know, there's an IAM, you know, solution built into security for instance that you can use, right, that all building blocks for us to determine like what role based access they give. But, you know, if you're using. Right, I can
see attribute based access control as well. That's my favorite. I always argue with people about rule based versus attribute based.
Yeah, well, yeah, so, um, you know, and I think, one, one thing that this has in here that is pretty relevant although this is also under flux is we're trying to come up with this uniform way of dealing with single sign on. Well, not just single sign on, but access control, and so we started with role based access control so if you have like a strong aversion to it. Um, you know, so we got these example, like workflow, you know, kind of access sequences, right, so.
Hey guys.
Hey Taylor, how's it going, geez. No worries. Welcome, good, good. So for instance, you know, there's this technical authentication and the general idea is that you ask every building block, you know, and we've updated this quite a bit. This is an older version of this document right. But the idea is that, essentially, you know, the user is going to provide an access token to your building block you'll validate that with the security I am and then you'll get a list of roles back. So, if you feel strongly that this should be roles and attributes, then we could return that as well. Right.
And we security. What's the acronym A IAM.
Yeah, so I didn't okay identity and access management so the idea okay yeah sorry. Yeah, so the idea is like the I am module can be utilized by all building blocks right in order to validate authentication tokens. So, you know, both
Geisha token is a JSON Web Token. Yeah something
like that or it could be a cookie but yeah exactly right, it's like a technical token that, you know, if somehow attach the user, it could be JW t it could be, you know, some other, you know, some other type of authentication token that basically it's, it's opaque to the building block right, the building block might know if you have it or not but the building block always is responsible for checking is this token good and then one of the roles that I can use then based on that, it determines like what results you get back.
We already have this kind of module.
Yeah well I mean that's the thing it's part of the security building block right, but there isn't really a functional, the security building block is still being worked on right so there's going to be a functional IAM. So the two modules that, geez, I don't know. The two modules that for sure we're gonna, we're gonna have in here, I can tell you right now is we're going to have this API management and Gateway, right, so that's going to have all of these functionalities and something like Kong, probably, would, would be a good, you know, fit for this. And then this would be something like open, I am right, or, you know, I think, you know others of us keycloak Right, but pretty much all that I am, you know, big I you know, Open Source, I am solutions. So there's going to be one of these available for you to use. That doesn't mean you have to use it right so if you want to use your.
Yeah, no, no, I want to, I have this, I said earlier, what I, what I see here is pretty much what I've done in government for free three and a half years. Good civic security, the building block as well, and it's pretty much does authentication with Estonian National Park, let's say you log in with your mobile ID or ID card or whatever of the functionalities that you can create custom charities. Yeah and you can always validate them. Right, that's pretty much the same I'm not selling this component, I'm just saying that this idea is very clear to me.
Okay, good. Yeah, it's less clear to some people but you know that it just depends on like if you've if you've done like systems work in the last, like, five years, then you probably. So but here's an example like network scanning and vulnerability management so one thing that we've been telling a security team that they need to do is, this is more like sort of like an ops thing than a, it's like runtime versus build time. Right. So some of these requirements like, you know, network scanning like how are you going to build a network scanner and then probably not right, so it's not going to be built into your, but that means, but it does mean that you should you should still probably, uh, you know, so this one is a little bit of a gray area like, you know, a lot of people are, you're probably not going to do this because this is more of like when you're setting up the system so some of these apply more like same with this right, like Phishing Protection I mean, I don't know you might have requirements in there for messaging you might have requirements for that right actually. Like if you can provide good Phishing Protection then that's awesome. Right.
I also again have to comment. We don't have this component at the moment but we have. We have it in our roadmap, and it's basically a specific component or a building block that just takes in raw input all the headers and everything, and just analyzes them. And in the background, and if it detects that it's, it's a fragment of a fishing girl or, or anything else. Someone is trying to do some SQL hacking, when it's just analyzing stops analyzing and says that means requests right must be stopped, and so on.
Right, but you know for example like infrastructure vulnerability remediation, I mean, we don't really have any infrastructure yet so this is more like a, you know, infrastructure kind of related security thing but this vulnerability scanning you could do vulnerability scanning, like today right using, you know sonar, or something like that, like just source level scanning so, you know, so I would you know this is very very in depth because we're taking cybersecurity really seriously but it's also like a little bit rough, right, but the point here is you should be listing, you know, any of those security the cross cutting security requirements that don't apply. Right. So. Right, so, and the cross cutting ones are really like here, right. So, if you're not gonna support privacy audit logging or security right source code, Right. Then you have to say why, but you probably shouldn't be doing all this, and then here you know you'd list specific security requirements like EG, you must use three factor authentication or something. Okay, right. So, if you want to highlight them but otherwise it's kind of assume that everybody's going to be following all of these security requirements because the thing that we, you know, for instance like one of the places that we're looking at deploying this isn't like it's either four or five countries in the Horn of Africa. And the two things that the minister said is, you know, they're really worried about is cybersecurity, right, because if this, if we put this system out there and it gets hacked on day one, then it's kind of game over for gov SEC in Rwanda say, and then the other thing is that they don't have 90% of adults don't have broadband broadband connectivity, right. So, so let's see so Taylor, Thank you so much for joining, I wanted to give you some airtime. How's it going, do you want to like give an update give a perspective, you know Yeah, sure. Introduce yourself. For folks I mean I guess it you know Martin met you but you know I'm not sure. I'm not sure Reiner did so.
Yeah, absolutely. Well, hey guys. Hey,
put the face back on I
think my camera off for a couple of minutes.
Yeah, exactly, yeah. We try to keep them, keep them off on we're actually doing the talking but nice to just say, Yeah, my name is Taylor downs. I have been working with the GOV stock initiative for quite some time because I've been co leading the information mediation, working group with Alexander Reed circus. So we've just now kicked off a workflow group. And we've got a fantastic team and the workflow group there are, I think, five, five of us right now in workflow. And we've had our first, our first three weekly meetings and folks seem to be seem to be engaging with the existing specifications pretty well. And, and starting to sketch out what this workflow building block will look like, trying to find the edges of the workflow building block and make sure it fits with the architecture team's vision for how this all works together. But yeah, my personal background I worked in sort of data integration and automation process automation in the government and nonprofit space, mostly low resource governments and nonprofits working in the Global South. For, for about 10 years. And, yeah, it's exciting to be seeing again or meeting meeting you guys.
Coy, yeah. As a runner, do you want to give it up, you know, just give a brief intro for Taylor.
Yeah, I'm Marina Turner from Mr. Sonia, I'm, I work at the information system authority, government facility. Currently, I am. I'm actually an architect at the Department of machine learning and natural language processing, and I've been hands on related to programming since 2001 Just in August, 20 years anniversary. Congratulations.
Yeah, I'm very hands on architect I do the daily programming and databases anymore but when I use some kind of new techniques or components i i At least try them out before I
actually open them up yourself yeah I kick kick the tires, a little bit.
Yeah. And, yeah, that's it. I have my previous experiences where I work now is with a state board for. Yeah, and I think that's it now.
Yeah, Martin, do you want to do you want to give a an intro, just, it's always a nice thing to do.
Yeah. Hi, I'm Martin here. I think Taylor has, has got me. So, it will not be a long introduction it will be just saying hello and really happy to see you after the event that we shared. And, and I'm also in a, in a position where we are now kicking off the messaging together with with Reiner and and getting familiar with what the expectations are from the other group, bookstores, the messaging group. So it would be an asset to have your update of the author information mediator, and which our site does messaging that could be an. Thanks.
Yeah.
Yes, I was just trying to So Taylor earlier I don't know if he was chatting down if you saw that I was just trying to give folks a, you know flavor of, you know, information mediator is how all the building blocks connect to one another, you know, this whole notion of asynchronous messaging came up, it's like we're kind of debating right now, right, whether it even include Pub Sub in. Yeah, because we don't have any formal use cases, you know like all the use cases that I can think of feel a little bit contrived and maybe far fetched like, you know, the obvious one is, we've got this registration for postpartum and infant care which is essentially registering a new baby, Right. So, in theory, doing that. You could publish an event that says like, oh, there's a new child from this registration service say it can publish an event that says Hey new child. And here's a reference to that child, you know by ID or something like that you don't have to. And then anybody who's able to connect to that registry, say through the information mediator could subscribe to that event and find out when their new child is born, so you can imagine a population registry could subscribe to that event and increment a counter when a new child is born, for example. And those two things would be sort of loosely coupled in a way, you know, except that the, the population counter like registry has to know specifically who to talk to and what message to listen for so it's not otherwise it breaks the security model so that's something that we've been sort of debating. Right. But for sure all building blocks are going to communicate through the information mediator. That is for sure. So unless they're talking directly to a user, right, in which case, you know you're going to be probably talking through an API gateway, for example. Okay, cool. So,
and it cannot. Could I actually did you get a chance to see that post I put in the discourse.
Nope, I didn't know, so Oh, that's another thing. You guys need to know about this course yeah,
you want to introduce this course and then maybe Can I can I plug a hopefully controversial post, I've just made in this course and asked maybe that you guys, you know, weigh in on it if you feel like you're able to weigh in on it.
Great, so. Okay, cool. So yeah. So, folks, you know create created this course account. And then there's also so what this course can do for us is it's a way to, so you should already have a group in here, under messaging like ready to go. And so, you should. I don't know exactly how all the permissions work, but you should actually also have an email address that you can use, right, like messaging@discourse.gov,
I can get Yes, it's active.
Okay, good. So we encourage you to CC, that message that that email anytime you are talking about gum stack related stuff. And the reason for that is, for example, if you look at information mediator and Taylor and information meters been doing a great job with this, you can see pretty much all of these open conversations that were happening through email, and they show up in a way that's, you know, public, so other people, you know my case I'm not even logged in, I can see all of this stuff right. So that's the reason we want you to use discourse.
Max, I don't know if you're still sharing your
screen but I know I'm not sharing my screen, sorry. So sorry. Yeah, so anyway you come here and it's gonna let you come to this discord so it's gonna look like that. Right. So for instance, like, yeah, if you see see that special messaging. At discourse Decosta global, I believe it is, then your emails will actually show up in here, and you know just make sure that the CC and when you're talking about anything related to messaging that you want to make public, right, and we encourage folks to just have these to do that and get in the habit of doing it because, and here you can see this is the thing. Right. So, and this is probably maybe the controversial topic. Taylor. Yeah. No, that wasn't it. Where is it correct me.
Are you muted.
I think Taylor,
sorry I am muted. Okay, if you go to guff stack discourse home it'll be the third highest post up. I can't remember if it's in the architecture thread or the information mediator thread.
Okay. Yeah, I am just like incredibly bad with this course so
scroll down a tiny bit proposal around Pub Sub.
Oh,
here we go responses.
Oh my goodness, okay right so here we go. So, um, this is a juicy one right. So, you know, while we're talking about this Pub Sub thing.
Yeah, that's, that's the only reason I thought it might be relevant is because you know we are sort of struggling to or there seems to be this really interesting tension right around, around Pub Sub and will government ministries actually want to participate in Pub Sub can we mandate that they participate in pub so how does all that sort of political stuff come out in what is effectively in my mind pumps up to just like a you know a technical approach to solve a problem of, of like, scale and redundancy and asynchronous communication.
Actually, this last sentence in this first assumption, mostly because in government they're ready to actually broadcast the message in Estonia. The, it's not rare.
Yeah, it's very, and it's very, very common there but we've been getting so much. We've been getting so much pushback. It basically people saying that they will never use Pub Sub, because they want to know exactly who the sender is for every message, and who the recipient is for every message. So the idea that like other ministries could subscribe to certain event types, and makes them uncomfortable. And I don't know if this is a valid concern obviously the Estonia case is a good example for yes, the government has adopted a Pub Sub communication model. But if that's the case then we need to figure out how to sort of prove that to the folks in gov stack, so that they're happy to move forward with Pub Sub.
Your point is not to completely wrong. I must say,
Well I don't, it's yeah I also should mention that it's not, it's not actually my point I'm just trying to sort of document some of the, you know some of the conversations I've been hearing around these different, different groups, but it really doesn't probably doesn't even need to be on this call today but it'd be really interesting if you guys because you have so much experience with this, it'd be really interesting if you maybe shared your thoughts on it.
Yeah, I can do it.
Yeah, and especially like you know I mean here's like the kind of nitty gritty, you know, the description, are all in here and you might want to, you know, I mean based on your experience Reiner, especially because you might have like some very strong opinions about, you know Pub Sub and how it could work. I mean we can take it offline though. Maybe, maybe have a special like Pub Sub debate meeting or something. Or we can do now but I just want to make sure we get other all the other questions answered. But, but yeah it's really important to cover this discourse stuff so let me know if you get, you know, stuck. Getting this working because it is really powerful. You know, I mean, just having this sort of threaded discussion board where you can, you know, kind of easily follow like the progress are relatively easily. Right. Yeah. Okay, cool. Um, let's see. On the look at the, um, so all groups are reviewing the work group cookbook, and the building block definition template, and then, so let's see what makes sure. So I guess we could try to look at the use cases and dive into that unless anybody has any more specific questions about, you know this cookbook or the definition template. Yeah. Yeah, I mean there's at least two of the groups here so that's not you know two or three is pretty good.
Yeah, I'm happy to dive into use cases, I'm going to need to need to go in, in, basically half an hour. I'm happy to engage in the use cases till then. Okay,
so, um, you know, what we can do so, this, we've been using this Kanban board, and actually I'm going to make a new project. Wave to sprint, you know, for lack of a better name. So, um, oh and I probably should have, like, made this like an automated, you know, see if I can do that. Alright so now there's an extra project but we got one of these fancy projects. So, let me just delete this one. Okay, so anyway, um, if you. So now we can just go ahead and decide kind of what we want to do, and who's going to do it, like, so what we've been doing, I'll just show you kind of like the. What we've been, you know, using this for, it's just basically everybody's familiar with this notion of Kanban board right, you just have these cards you can move them around, and then track what's done, what isn't. And we've been using this basically to try to synchronize the group's week by week, or, you know, step by step through the series of use cases, right. So, um, you know, so there are all of these use cases that we could consider doing right so the idea is we just track you know which ones were doing which are in progress and which ones we actually finished. Um, so, you know, I should probably fill up the backlog, with, with all of them, but I thought it might be worth taking some time to just look at the dial use cases. In case you guys, you know, because these are kind of underpinning what we're actually, you know, what we're doing so, everything that we're doing here is, is kind of focused on the user which is in this case I think is really I think of it as a citizen, right, so we're trying to do these, you know base all this work on these very citizen centric kind of use cases. And, you know, so they don't have a whole lot of, there's not a whole lot, you know, so, and some of these are very specific. So, you know, there's this messaging. You know, you know, so for instance in this case it's very clearly calling out the need for messaging, right. Although we're not doing remote learning we're doing unconditional Social Cash Transfer and postpartum in infant care, right. But the idea is that, for instance, and this is probably a more useful way of looking at this I mean so this is like the subset, we started with. But if you look at these use cases these are kind of like the like these use case steps, right. So this is sort of like the arc of a journey right so the mother gets promotion, which is probably involving messaging, right, so this step is probably involving some sort of messaging, I you know I don't know you have, we have to read these textual use cases, but the idea is, each of these use case steps, represents a stage in a journey so first they're promoted to, then they're registered, then the baby's first visits arranged for the pediatric clinic, then they visit the then they visit the clinic, then they get medicine and nutrition supplies then they visit a therapy center. And then finally, both the doctor and the mom are paid incentives for participating. Right. So this is one of these use cases, we're trying to do all of these steps right. So, you know, there's this sort of a question right. So, this almost seems like a, you know, a, you know, it doesn't really talk about how the person's, you know, the means that they're promoted to I mean I guess it says they you know they, this person's walking around and visiting people at homes and hospitals and then promoting them, right.
So, this is maybe not directly specific to messaging, like you might think of think it is but there's this sort of client communication. And this really is, you know, if you read this, it's like envisioned as bulk or individual communication between businesses and their clients are individuals, right, such as email, SMS IVR, or social media. So this is you guys, right. So actually, right, there might be a untargeted or targeted client communications for promotion that services through messaging, somehow, in this in this use case step. So, what we're doing is we're starting with these very kind of you know they're kind of vague textual descriptions, and like there are some transactions was helpful. And there's some contextual workflows but you need to turn off that dictionary thing sorry. So what we're trying to do so. Any questions on that so far. No. No, thanks. Okay, cool. So, you know, and the two that we're really focusing in on are. Sorry. Okay, push infant care, and then this unconditional Social Cash Transfer, just because it seemed like the most relevant to the groups that you know that we're working with, or you know the initial places we're going to deploy. Out of all of these sort of use cases, right, and so then there again, they're all these use case steps, right and this is coming directly from the World Bank, I think, right, so this is their sort of suggestion of how you do unconditional Social Cash Transfer, right, all of these specific steps. So some of these like outreach, there it is again right outreach is probably going to involve some sort of bulk, you know outreach communications right so. So let's look at this like, you know, average communication step again there's a series of steps, and the arc of the journey from communications to registration, you know enrollment payment case management, and then ongoing management. Based on that, World Bank, best practice. But there's certainly some playing communication, right. So to celebrate spreading awareness for a target audience and encouraging enrollment by mobile and media channels. So, you know, I mean, that is that messaging. I mean, that almost sounds like social media marketing to me right. But, you know, is there a way that we could use messaging for that, you know, do we need. Yeah.
But, but let's let's go on.
So, yeah, sorry. So I mean, so, you know, would we use a messaging building block for that like for instance, could we expect the government to have a list of phone numbers or email addresses for potential candidates, right in their in like the registry is that even viable, right, that the person would have like, you know debit or the government would have in some registry demographic data about the their citizens that they could use to, you know essentially send them email or SMS messages saying promoting, you know, this unconditional Social Cash. Cash Transfer, right. So, I mean there is an information campaign, you know, you guys are not going to do social media but there there might be a very clear messaging components there, right. So, anyway, what we've been trying to do is pick apart these use cases, right, and then do it in the workflow cookbook kind of has links to this. And this is kind of what we're trying to do now, right. So, um, so I'm going to just modify this because I think this should be. it shouldn't be project one. So, anyway.
So, anyway, so we should probably decide which of these use cases we want to, or which of these steps in the journey we want to cover first. Right. And it might be useful, you know, one thing that we can do is we've already got this logical process blueprint where we tried it, here's what here's it kind of how we do it, or how we've been doing it, is we try to very specifically, write out, You know the series of steps right so this is a very short, kind of, you know, it doesn't really describe like step by step, what's going to happen from a user's point of view so we try to, you know, break it in, break it down into really granular steps like somebody logs into the system. They select the registration process they enter this, you know, they store the proof of identity and mother's face, right, there's an optional registration, payment happens through, you know, validate with foundational ID system etc. Right. So, there are probably and then once we go through and write these very specific steps right and we're kind of making this up, and, you know, a lot of times like the architecture group will just go and write the initial draft and then meet with you guys and go over it. But then, what we try to do. The reason for doing this, is it allows us to get one of these flow diagrams and these look a little bit technical, maybe, but they're really pretty powerful in terms of being able to describe, specifically, what, what's happening right from the healthcare workers point of view. Right. Once they get to the ScreenFlow. Then how is this interact so all of these are basically actors, right in the system, right, and this, this will probably be very similar for all building blocks these two. But, you know, the key here is to figure out which building blocks like which API's are going to be called between building blocks right so how does this register, how does the registration get the information from civil registry and populate the screen right so what are the API's that are necessary for that to happen. Likewise, and tailor, you know you've got the workflow building block right that's you're officially representing a workflow here, you know, how do we what information goes in to validate if the mother is eligible and what information comes out and like, how is that is that specific to this, you know, want to try to drive what is the generic functionality there, right. not necessarily specifically I mean it should be specific for this use case, but we want to derive an API that covers, you know, ideally more than this specific type of transaction, right, yeah.
And just this is maybe a nice, nice point to talk about sort of what the workflow building block is doing basically, we would need. So the API that will be accessed to validate if a mother is eligible. Yeah, that's actually an API that initiate a workflow. So there's like an API that basically says, Spark workflow, and the workflow itself might be written in 10,000 lines of Python, or it might be like a you know a point and click logical gateway or shot or something like that. But yeah, they will need to be able to sort of send some initial data to an endpoint which initiates a workflow, and then registrations creating flow will need to be able to receive a response or a new request from workflow. When that script is done running or when that business processes is done executing.
Right, exactly. So yeah and so I mean I imagine it like I've imagining it something like conceptually like, you know, open a fan or like lamda, where you pass in like a header. Yeah, headers and data and then you get back. Come
on the cloud, or something like that and any of these things basically a way where you can initiate some sort of script or some sort of process and that process then can you know call back at a later time. And tell us tell ScreenFlow yeah this person is good to go, or whatever it is they need to say,
right, So yeah, I mean there's this sort of like question right. Is this like a synchronous process. Is it asynchronous like there's this sort of, that's something we kind of have to, because of this, this could be a long running thing right. So, it might need to be asynchronous. So,
yeah, I believe that one of the specs we have is that you can configure workflows that are both synchronous and asynchronous, so you could, you could make a request to an endpoint on the workflow engine, and that endpoint, would, would not respond to your request with a 200 400 500 Whatever, until the business process had executed right and that would be the synchronous style and then the asynchronous style is you make the request saying validate if mother is eligible and it responds instantly with a 201. And so it's cool. We've started, we've started that workflow. Yeah, we're gonna do the validators and, and there might be manual tasks, bureaucrats might literally sign documents before that task is completed. Yep and then when those uploaded signed documents are completed asynchronously, a new request goes out to ScreenFlow and says this Mother's eligibility is confirmed, and then that process could hang for a week or for a month or for 10 seconds or whatever. Right. But both, both styles need to be supported by workflow in my mind.
Yeah. And so one thing that I want to point out overall is like you can see pretty much the text, or most of the text from that outline that I showed you earlier, is here. But as Taylor just pointed out these things can happen in different orders like some of them can be optional. Right, the whole point really is to drive these arrows, and say like, Aha, we know we need a workflow engine here, right, or we know we need to send a message here. And then specifically, what is the API look like to, to, you know, send the data in to send the message and then how do we get some sort of response to receive a message, or like, you know, What's the response look like from that. So that's kind of how it's gonna work right and same with like a rules engine, I mean I guess that's really kind of workflow. Also, but you know payments right like, you know that that, you know, if we want to request a QR code to execute a payment, then, you know, this is one way to do that right so we've identified kind of requirements a bunch of across a bunch of these use cases, to sort of identify these kind of requirements and make sure that at least this functionality will be supported by the building blocks, right. And so, another key point is like the only API's that you're going to put in your building block specification, are the ones that are needed to support these interactions. Right. You don't need to put every single piece of functionality that you can possibly imagine. Those can be internal. And those can be functional and active inside of the building block itself right for messaging, a workflow, but you don't need to expose them as part of the building block specification, right you just list them as requirements like I need to I need to be able to send messages for WhatsApp, right, but you might just have a very specific, you know API that is kind of more generic than that right and that's the one that the GOV stack that's in your in your building block specification. Right. And then, that somehow gets unpacked and routed to the appropriate functionality or modules inside the building block itself. Yep. So, okay so messaging guys like any, you know, questions about this like overall process. No, no. Okay, cool. So, um, do we have a.
Do we have a use case on hand, like hits that already specifically his messaging, so we could like talk through what what some of those interfaces look like or,
yeah, I mean we certainly do so, you know and so again these are so there's there's outreach communications are super obvious right. Let me just see. The other thing I can do his messaging. Right. So in here I don't have a whole lot there's not a whole lot. Unfortunately, so these are the use cases that we've already worked out the cross, cross groups, and there's not like you know it's kind of a painstaking, it's like a little bit painful so what I would suggest is that we just, but we can also make it up right. So what I would suggest is that we look at one of these, you know, this enrollment process, and they're kind of spelled out here right so if there's a client communication. I mean, that pretty much relates to what you guys are doing. So I think it's gonna be a lot of these like outreach, messaging, you know, there might be in this enrollment. No, I mean they haven't listed it out but you know we don't have to follow these like, so I mean part of the thing is like you guys work in government, so you might have like specific opinions about when messaging is most relevant right, but in my view, is probably either this outreach communications for unconditional Social Cash Transfer or. Let's just go into the postpartum infant care, and look at these steps, or it's probably like this promotion, But I don't have a whole lot of, you know there could also be so we can work in some reminders right like a reminder that, oh you got a pediatrician visit, right. So even though this doesn't say like there should be messaging like it'd be kind of nice if, like the mom gets some sort of reminder right to follow these steps, like that's something that we could do, right. So, if we change the registration so that we have some way to reach them, then we could do that. Or we could just keep it simple and just focus on promotion. Right. So anybody have any strong opinions about, you know which which you'd prefer.
Maybe we can go, Martin here, maybe we can go through this example or use case. So that, in its entirety. In another meeting, or sort of use, use the time here today, so that we have from A to Zed, basically the business grows is covered with messaging, and we can decide then. Which part to cover, and which part to lead to other building blocks.
Yeah, exactly. So, you know what I would propose is that we go through, you know, we just choose one of these that involves messaging for sure, right, like, whichever one you guys feel is most viable and then we just do that, like we write out this specific business process steps.
What's your opinion Reiner, they I, I agree with Martin.
Okay, good. So do you think, do you know do you feel like promotion of the Mother Child community incentive program is like spreading awareness and encouraging enrollment or the community health program or facilitating
reading, as you said earlier it's pretty much for me from my point of view it's like a media campaign, yet he also said that the government might send the information to flu for SMS or something in Estonia, it's actually something that we do, and I have been part of it as well, sending direct emails and the direct SMS is we have this mistake basis, and we use it.
Yeah, but, so you do targeted messaging, essentially Yeah, for outreach. Okay, so let's focus in on that because I feel like it's most directly applicable. So, you know, let me just, it seems like you know, they're both pretty similar in that regard. Let's see which one's simpler. I think this one is slightly simpler. Right. So there's this sort of a, yeah. So yeah, so it's just this client communication thing right so targeted and untargeted client communications. Okay, so let's let's zero in on that maybe. So I'm just gonna open up this logical process blueprint, let me just make sure. Oh, good question, Reiner, so what we've been using is this, you know, for better or for worse for these workflows. Is this web sequence diagrams. So, just because it's so quick and easy, and it makes beautiful URLs. But what's kind of cool about it is like all of the information needed to enter the diagram is encoded in the URL. So that is sort of powerful, because then over here you can say like, oh, make an editable version of that diagram. And then you, you know, when you click on it, it launches this in an editable state, that same with the images, like, like you can say like, this is why I really like it, you can share it export it, you know, created a permanent link to this image. This URL is always going to be this version of that image. Same with this permanent link to this text, it's always gonna be this text right so you can then you can just put that in your link over here, update the image, update the text and you're done. Also, it's, you can connect it to GitHub, right so all these are in GitHub, so I can save now. Right. And then, you know, provided that I opened it from GitHub in the first place. Right, so, uh, yeah and I don't think I have GitHub connected. But anyway, it gives you this nice way to, or maybe I'm thinking of dry Oh, I don't think this has GitHub integration nevermind, but at least it has this nice clean chair and export, and the city and the syntax is just super simple right like this text here is all you need to generate the diagram on the right so like once you get the hang of it it's super quick but you know one thing that we ask people to do is make sure that your diagrams are in an editable format so that you know again in the future when people kind of come to you. Or, you know other people join your team or whatever they can edit the diagrams as well. So we ask that every diagram so if you look in here. This diagram has, you know, an editable diagram and then this is just the currently embedded image of that diagram, like I showed you before,
it looks like from for mermaid butters might have missed one looks, looks good with creative well
yeah I mean if you want to use mermaid is provided that it's text based and editable. Yeah, yeah, yeah. Use whatever you feel man, Like, yeah, so you know we're not, we don't want to like impose anything on anybody. So, alright so I'm gonna go over here and pull up our project. So this is where we will track our progress right so I don't think I posted that here.
So, so there's that. And then this. The other thing that I wanted to put is is logical process blueprint. So, so first of all, we're going to do this. What is the specific outreach communications for unconditional Social Cash Transfer.
We just decided we're going to do the first one right. And then I'm going to add another one which is like a. This other one which is for promotion, you know supposed part of AdvoCare. Oh my gosh. Promotion over here.
I think the colons are slightly better so this is super easy to use, right and then we can, you know, reorder these blah blah blah. So I'm just gonna say, you know, we're gonna do this. You know this, this one because the promotion one because it looks slightly simpler, like there's fewer, you know, just I'm just eyeballing it, right. So we'll do this one first. For the postpartum invocare so now I'm gonna move this in progress. This is how we keep in sync right so now all groups know that they can go to this logical process blueprint and edit this, you know, edit, you know, focus on this task right like promotion. So, um, and this is just kind of how we stay in sync about this. So,
there we go post-primary AdvoCare great, so I'm gonna make this heading one. There we go. So, um, and from the promotion section.
So we're all on the same page, what that means and then I'll put the link right here, so that it's correct.
Okay, so now you can click that link and you can go directly to that. Alright so, and then I'm gonna actually pull in this other, you know, dial. So, um, so promotion, right. So this table here. I'm just gonna copy and paste that just so we have like all of this stuff. So this is kind of like the inputs that we've got for better for worse. You know we get these tables. Right. And then that's what we drive. Yeah, that's what we would drive oh and I think this one is actually wrong. We just update that link right so, and then they'll use case is this other link that we were just looking at this one. Oh, so I'll try to you know, I can try to do these in the architecture meetings, if we have time, and just sort of, so that we don't have to spend as much time like this is just this, but this is kind of good because you guys are seeing how the sausage is made right. Can you read this okay let me just increase the font size. Okay so now you know you just got this process checklist so you know, I'm not even going to, you know, call it that. So now we just got this series of steps right. So, what happens like what is this targeted messaging thing, so. Right, so the healthcare healthcare worker checks for updated educational materials, and they target communications for promotion right so first, you know, how do they check for updated communication, you know, education materials I guess they're talking to some sort of registry. So, uses a education, a, you know,
I mean the other thing is there is this other kind of you know content management, you know, we could just say this is a CMS.
Right. So just cuz I don't know I mean it seems like you're really, this is more like a content management system. I would be using, or registry or registration app. So, uh, okay. Oh my gosh, we lost them. It's just like watching paint dry. Yeah.
Just to preempt any emotional damage. I promise it's not the paint drying. But I do have to drop but the bottom of the hour in just two minutes for my next call.
Yeah that's fine I mean this is great progress like let's just bang out as much as we can and then we've got, you know, something for the next meeting or other groups to look at during the week yeah
asynchronously. Okay so then they do this, uh, they, you know, CH W selects. Some materials. Right and then they ch W. Maybe chooses demographic group
registration or Registry, or, you know,
basically choosing choosing there are a list that are gonna send to you. Exactly. Yeah.
I don't know if you have like, if you got better terminology throw it at me.
No, no, I mean that makes that makes sense. I might even add, just because we have technical people, also on the I would say like demographic group, you know, parentheses, contact list or like recipient list or something like that just because we, we can sort of preempt. Yeah. And guys, I'm Max runner I'm in the draft now from my next call. That's cool. I will talk to you very soon and I'm sorry for the for the short
one, no thanks for joining, very productive, you know, really appreciate it. Okay, cool.
Okay, talk to you soon.
Thanks. Okay, so I guess it's just you and me, buddy. So, what are your thoughts. You know, I guess, then, then they would just send message you know materials are sent to are sent to contact list.
materials are sent to a list of contacts.
Right. Okay, so this is what uh you know, what do you do you have any other, you know, I mean that would pretty much I think do it right. Conceptually, yeah. Not to death. Yeah
I can see. Yeah, no, No no no. And when we are. We are not creating actual solutions but we are describing the architect, architectural input for future tenders. Correct. Yeah,
exactly, exactly, but we have to spell out these specific solutions, otherwise we can't guarantee that the architectural tenders are going to work. Right. Okay, so this is sort of, you know we do these, you know, just kind of write out these rough flows agree upon them across the groups. And this is every group, right. So, somebody is gonna come along like from registry and say like, oh I think I don't think I should be doing this or I should be, and this is how we decide who's doing what, right, like, is this education materials content database, you know, is that a content and content management system or is it registration, right, is this registration like ScreenFlow or is it more just a technical registry, right, where you browse a list of groups, and then you pass it a group and you get back the contacts, right. So we just kind of debate those technical details and then we'll, you know, hopefully get to the point where we have this flow diagram, and with each building block knows exactly what they're doing, right. So, is the idea.
Great. Did I get it right, last week, but you're the head architect of Seoul, think,
yeah, yeah, that's right. Yeah, trying to be
concept. Technically speaking, is what I've been doing it for three and a half years here. Yeah, in governments and then it's, it's very refreshing. Refreshing to see something so similar. Usually it's something that the material, per se, but let's do it. Let's, let's write some business logic in database. For example, and then it's really refreshing to talk to you.
Yeah, well, thank you. It's really refreshing to talk to you I mean that's really great to hear because, you know, I mean that's why we have an architecture group like leading this because otherwise you just kind of end up with something that isn't like, it's just not going to be sustainable, right. Yeah, so, yeah, I mean, so, I mean that's kind of one thing that's really cool about this project is that, you know that they chose from the beginning to do that right like Martin comments was like, Hey guys, well, Estonia will participate in this, but you have to have an architecture group, right, and you know that was his like visionary like he had made this throwdown, you know, and it's really visionary, and, you know, because of that and then you know crystal I guess like your CTO is too busy. And, you know, he kind of like vetted me and so that's how I ended up here. Okay, okay. Yeah, so, yeah, but I still talk to Crystal like I tried to talk to him at least once a week, but he's like, super busy.
Yeah, we're there, we're, I know I'm Krista has mentored me as well. When I came to work what I what I work. And he, he was one of the people who, who he believed in what I why I didn't leave this governmental life.
Yeah, no Chris was awesome, like I have so much respect for him. Yeah, he's great. Yeah. So, yeah, yeah, it was a man that yeah, so and I guess like, you know it's my first like time dealing with the public sector. So like all my other background has been commercial. It's just like this. Yeah, I just happen to be in Estonia and they needed an architect thing, you know like, friend, like connected this up so that's how I got involved so but yeah that's really great to hear. Well cool so I mean, you know, I'm happy to stay in talk like and just hang out or hang out and get beers or whatever. But we don't like need to keep working on this. I don't think, because it's just you me. Yeah,
I think that there right now I have to end as well. But I would be happy to meet up sometime just have tokens and so on. Cool.
Awesome. Yeah, so let me just post my email.
And then, cool, and then I'll send out the meeting minutes. With all these notes and that stuff from the chat so you can, you know, like you don't all those links and everything will be preserved. Okay, cool. Well, good stuff. Okay,
great.
Well thanks so much for taking the time, you know, I hope you know I hope it's hope it's helpful. Oh, okay. Okay, great. All right, Well, great day, great to catch up runner and we'll, we'll talk to you next week, if not sooner.