concerned by the comments that the lady from the World Bank made.
Yeah, right. Um, yeah, so. Yeah I mean I think that seemed like we kind of resolve those though like just explaining that what the project is and isn't right. But it also is kind of like, so similar thing, I mean there's sort of like we're trying to follow this agile process and some people kind of get it more than others, I guess. Maybe it's partly. Yeah. Yeah, I, you know I'm not. I'm not sure which group she's with I never encountered her before.
It's always this chicken and the egg thing. I mean, they always expect you to come up with a 100% proof product, but they don't want to invest in, like getting their rating.
Right. Yeah, exactly. So, yeah, we'll see how it goes. Um, yeah. Welcome Ramkumar. So, um, I guess I'll pull up the agenda. Um, yeah well so any kind of action items from yesterday, that you could think of like to deal with that, you know those concerns or, um,
I kind of, I think it goes back to, you know some of the very first discussions that we had about where it fits into the overall picture. And it is, it is explained, but it is hidden away, I think the only action is that we need to make it explicit. Yeah, about what the what the call stack actually is, and sort of spell it out. You know, because, as you say there's nothing here that we haven't heard before, but it's I think it's more recognition that, you know, four or five months down the line, the confusion is still there.
Right. Yeah.
So I think it kind of goes back to whether we should put a reference architecture in place, or because this is more. This is more about facilitating the glue, rather than the submittal I'd say rather than the bricks itself. Right.
Exactly. Um, Okay,
so, um, I mean I think probably the, you know, Jake's idea of updating a website to reflect that is a good one. That's the first thing a lot of people are gonna see,
it's I don't know where else to put it I mean it's like there's like these, you know, I don't know, lots and lots of documentation right.
And I also, I mean I don't think I am certainly not mandated to say this but maybe your perspective is to try and get the aims and objectives, maybe a little bit narrower. Yeah, maybe align it to some of the other objectives. Like, when the when the Horn of Africa Initiative presentations were being done. The World Bank, kind of highlighted three, three major things, which was digital identity digital payments and security. And I think if we were able to align more closely with that in terms of providing a system that broke down silos, and reached out to citizens, kind of make the scope, quite tight, and then expanded it might firstly resonate with more of the stakeholders and insurance, you know, alignment, and then just narrow down the scope because I think the dial scope is very very very broad. I think that if we were to say, right, well, let's just assume you have a payment framework, let's assume that you will have some kind of identity management system, or we'll be using most, then what we will help you do is build a portal that allows you to integrate that across the government stacks, so that you have something that kind of fills the gap of the, you know the sits in the middle. Yep. And maybe it's just reframing what we have to make it specific, so that it's easier to understand because I think it's very abstract, which is easier for technical people because we're naturally abstract, but for people that were, say from a government agency, they may not see it or get it or even understand is relevant to them and I think that that's maybe so it's more of a positioning thing been changing the work that we're doing, but maybe that's something that we need to take back to either do as aid or ICU and spell it out.
Yeah. Yep. Yep.
And then experience from, From what we do in open them is what I never thought would be that important is when you really talk to those political guys or policy guys. They need like like very short graphical things which which look. I don't know. Process Flow was was boiled down to, like, four blocks with pictures in it and like the PR stuff is quite important for those people I think that's the only language they understand.
Yeah, so I mean I agree and I think, probably, you know, I think we need to be, I think, again, the appropriate place for positioning is probably not in these architecture documents because unless you're fairly technical it seems like people's eyes just glaze over. So I agree with what you're saying, Yeah, I mean I think we need to kind of focus on, on the PR kind of methodology of, you know, how we, how we position it and how we, how we phrase it,
and it's something that we have given to like professional designers and stuff like that I mean, I've been doing a lot myself but I mean if you're an IT guy and you think that looks cool then they they see it differently so if you have a professional designer, like like brush up on some of the graphics, and some of the texts and all that. It looks much different than the budget for that in the project. Are you aware of that.
You know, I mean there is I mean there's, you know, like a, an agency was hired to do the website right so, but I'm not. Yeah, so I mean there is some sort of like but I mean, this seems like, you know, more of like a communications issue. So I'm gonna bring it up with the comms team here, I mean because they're based in Estonia, and I'm talking to them. On Monday, so I'll just raise this and say that hey we think maybe, you know, I don't think we I don't think we can change the scope or the focus of the work we're doing but I think we could position it differently. Right. I mean for us in
the end it was like, maybe four or five key slides that we, we always keep presenting whenever we have a presentation on special topics that we're gonna like easily get people on board and what OpenAM is this and what it's for and those are just standard and I don't know it wouldn't be too expensive, I guess. But, no,
no.
But I think it also helps if you align the positioning with use cases. You know it helps to tell the tall, straight Grandpa, you're on mute still
your muted Ramkumar. We can't hear you.
Can you hear me now. Yes,
yes, we can hear you. Sorry. Yeah.
No, I think they're too important aspects. One of them was, is what we're saying is we have accumulated a lot of technical expertise right now across these groups. What we are missing, is product teams product teams as in agriculture for acting as an education product team as in healthcare product team, which is nothing to do with technology and they will appreciate technology, they may, they, they may not know, whatever it takes. Right. So from that perspective to the end customer, the government what sells is that product viewpoint, because even if they put somebody in a health ministry to talk, the guy who's sitting there and make decisions has been seen. He has not seen, necessarily, the techies, right. So, that is one applicant I think we have to, for positioning our, our communications has to work on how to showcase a certain product which resonates with the need in that top line that domain in the healthcare ministry or education ministry or whatever. Yeah. Second. Second thing I think is given in AD is fundamental question listening to, because yesterday we had a comprehensive presentation of all these building blocks in a PPA. I think there are still some missing blocks. And I think we should honestly, check whether that those building blocks are also necessary because I think, in a practical system without those things, it won't work. For example, I listed a few. One is billing. Okay, very complex billing happens in your system, in any given system but billing itself is a very organized mechanism. Right, so there are so many ways of being and you cannot keep. I mean there's no infinite ways of building, there are few ways of being. There are a few ways of accounting. And there are a few ways of
claims in the youth sector. And we are having no overlap, except for probably.
So, insurance claim is only a part of the healthcare process. Right, so if care care provisioning, like the mother and child care program. If the care provisioning, the care process. If the care payments payer and pay related stuff, these are all huge things which are necessary for that to become a practical solution in any place. So, maybe we should check whether we missed out some building blocks. Is it necessary to build them at this networking thing that you came up with. That's important. It's an independent piece, others well we were thinking network and security is one piece but it don't look like networking is a separate piece. Yeah, we're building settlements settlements is an important thing because right now payments group is not saying, I'm going to I'm not going to calculate self settlements, somebody is going to calculate settlements, I'm just going to pay money. Who's going to calculate settlements and settlements is a very orchestrated process it's not some random process that people are screen inventing today right settlements are pretty good financial process. So I think they would like that if we as architecture team, let us know scavenge around and find out if there are missing things which, which are very important for enabling a kind of prioritization, using these building blocks are their reusable building blocks, which were missing.
And I think that's where we are getting into the language that they are the conceptual level that they work on in open HIE, for example, when you talk about system components that are groups, to, to, like, higher, higher level functionalities like a medical record system or administrative system or laboratory system. And in our concept we're doing this on very, like in caustic we're doing this on very granular building blocks, but but as a program manager, you can't really see what the building is being used for it's just some abstract stuff for you and then we can't we understand that if you're not an IT guy.
That was an interesting reflection that I had when looking at the ID solution, and email solution and the payment blocks. And I don't know if you remember my kind of tiered architecture thing where you have, you know, technical cross functional and functional apps. Each three of those building blocks, had exactly that same architecture. Each one had a data store, and a workflow engine and a kind of integration layer. All of them had a functional layer, a protest that set on top of it. And, you know, this. Ironically, payments, id and the registration would fit the definition of a building block, but a lot of the other ones that are were in our original use case would not. So I think that you remember some of the first discussions that we had about, you know when, you know, eat Mars set has a form and it writes to the database is that registry and we have a lot of kind of philosophical kind of discussions around that, what is actually materializing, if you look at most if your solution is that each one is a functional building, each with its own registries, each with its own workflow engine, each with its own name. That's what I would expect to find and really interoperability at that level makes far more sense. Because then if we say well, this is a most building block, this is, you know, a registration building block. This is a payments building block. It is actually more similar to an integration, what you know the GOV stack is, is more of an integration layer, and what I can probably advise that if you wanted a government to borrow to buy this, they would be more interested in the content and the outcome than the technology itself. So if you took digital ID, you took payments, and you took a another back end, and you build an end to end solution, where people go in and register for birth or Read or request a new birth certificate or a copy of your marriage certificate or something simple like that that use those three components. And we said, listen, is most it is payments, his registration is like your billing system. We will put something together they are far more likely to engage in it, then if we continue with something like a workflow building block or something of that nature that's, that's my personal because people want outcomes enough technology and it's real or not, this
organization. And just imagine for a moment we were wearing a cap of a company. We would first decide who is our customer. If we were building this, whatever we have right now as building blocks, to whom we sell this as a private sector to only sell it to a hospital or movie sell this to a heterozygous manufacturer. We sell it to a insurance company, or we would sell it to an insurance software manufacturer. So, so I think we, that's the gap I'm seeing that we are having something which is not our end user our end customer. Our customer is, is not the dominant, as it stands now, it looks like government is consuming something from somebody who puts together a software, which uses our building blocks. So you're trying to sell one step beyond, you're trying to sell to the government, where you need to be actually selling to the guys we're putting together this application. So who puts together this application Cerner, IBM, now know what I was sad. So, so the point is, we I think marketing too long, right.
Yeah, just, um, so, So, yeah, also just, you know, just for the, for the benefit of these four, it's likely, it's more likely than SAP partner will submit the RFI is in SAP directory. One is a permanent trees and. But the other thing is that our partners are more active in North Africa Horn of Africa in East Africa than SEP or directly. And I had a couple of internal discussions, and they have told us that a couple of our partners have already implemented those. It's already, you know, so for them to respond makes far more sense than SAP because it's not really our space so I think that this kind of hybrid kind of approach where you know gov Stan step forms the glue. Because even if you do get all of these components they don't talk to each other. I mean you still build that whole thing out. And I think that that's where the, that's where, if we were able to focus this on content on, say if we were focusing on Africa is killing digital payments, which clearly digital identity, and it's clearly on a secure platform, then I think that the chances of adoption are far, far higher because then you get the community to build the content. And what I can also tell you that in a lots of the software companies that I work for. Prior to joining SAP. That is always the reseller model where you partners build the content in order to sell some of their stuff could be infrastructure could be security could be any one of those things, they add the content and produce it open source and, and I think that that, that will get a good community and then you can specialize in different, should we say configurations for different verticals and different use cases.
Yeah, I mean, the thing that I keep going back to the deployment perspective I think if, if you had ID and security. These are the first things that you put in as an infrastructure around that you could then populate all these application domains one by one by one, because your spine card is ready. So, if you don't have an ID infrastructure and you're trying to put 15 different domains, you will end up with 15 Different kinds of systems are interoperable.
Well, I mean, I guess we'll see what happens with ID I mean fortunately, you know like, you know, we could we do have ID and payments. Right, so and we have this glue we have security we have information mediator so those things you could already do some interesting stuff right i mean potentially with, you know, like, some sort of partnership with open ms or something right. Um, if you know depending on the timing of getting back our payment building block it might actually make sense, right, to do like some sort of prototype exploration partnership around like a reference implementation but until the specs are written and until they're put out for tender until we get the results back, and probably iterate a few times, it's going to be challenging I think to actually build a reference expense.
If you take any drug in demography, you want country. Just go back and ask how much samples, a side project would be spending on scoping out and requirements specification, and saying that, not the needle requirements fix, But the requirements specs on the target demographic matching all the functional specs to match it. Right. That is very expensive. And one thing doesn't fit all. In fact, if a target building building blocks that the only piece which fits all or many. That's how we have been able to filter out building blocks and so it will be better, very heterogeneous.
Yeah,
there's also some other, I know this is kind of a bit of a fluid conversation but I think it will formed into the picture. I spoke to a couple of my contacts in the various development banks, and one of them has actually informed me that the World Bank has decided to move to the cloud and primary, the World Bank is going to the cloud for everything. And the reason was cyber security. They are unable to secure their own infrastructure anymore. The, the rate of advancement in cyber attacks has increased so quickly that they realized that they, they don't have the skills to secure their platform. So, this, and I've actually heard this theme in a couple of other instances I know of one other development bank that I'm working with that is called fully cloud for taking the structure, because he also recognized, he cannot have an end in house team. So again, even if you're looking at that, there's going to be $1 number associated with, whether it's AWS or, you know, the ability of an organization's, especially when dealing with digital identity and the security rounding that they're going to have to have it hosted, because they just cannot afford to secure the platform, and it was quite an interesting thing when you think about it because the, the development banks and central banks that I've been dealing with have been very reluctant to to go to the cloud, because they don't trust it. But on the other hand, they also realize that they're vulnerable. So I think in terms of the you know the networking building block. That's why it's critical, because again, we would need I think a platform provider, whether it's Google or Amazon or Alibaba or, you know, one of those providers to to host the solutions to make sure it's secure. Otherwise, I don't think you're going to get the thing off the ground anyway. So if you put all these pieces together and look and say well look Horn of Africa, digital ID, digital payments, maybe a another maybe education or you know maybe grant application or something of that nature. If we were able to have the scope from, you know it, your GSA to agreed that this is a reasonable scope, then it will be easiest for us to demonstrate and, you know, SAP already has, you know, CSR initiatives corporate sponsibility initiatives with with USAID, so you know that we at a platform provider all, I mean it's gone right up to our global CFO, that they've approved in principle that sap would be willing to help, you know, provide a back end infrastructure and to give you some idea, we can deploy RP in about four to five months now because we had these little companies where you basically just put in a general chart of accounts or general organizational structure, you suck it into the system, and you're up and running on a, on a public cloud within a very short period of time. So, you know the old thinking about how, you know how monolithic, you know, SAP is to be is not true anymore. And if we were able to, you know, provide, you know, easy adoption, on, on the, on the back ends in secure fashions, I think that there's a strong case for putting the whole thing together and making it work and then you have extra in the middle and you know all the other stuff that we've talked about because to get. And I think you said as well to get that we struggle with with agencies is who pays for it. If you are doing like an ID system for, you know, government affairs, internal affairs or home affairs or whatever they call them. He comes out of their budget. What you can't do is if you say, Well, I have a Government portal, I can get my tax return, I can get my ID document, and I can also get out my medical records. The first question the agencies ask is, who's going to pay for it, it's not coming from my budget. And this is where I think I've set off is such a big and powerful message because licensing becomes a an opaque topic it's not a forefront topic, it's just a generic infrastructure topic. And I think that that is where you know the Gulf State has got a very unique proposition, and a very strong one, actually, in South Africa, they still don't have a portal.
Even though virtually every government agency has a port and capability, but they still don't have any government. And I think that that, That's, if we can focus in on that I think you'd have a very good chance of uptake.
Also, can I, one on the aspect of the of the cloud platforms if we look at hardware, I, because I'm interested, I discussed this with usap colleagues in Nairobi when I was there, and we have always been thinking of ways. So what's the problem to deploy like a large solution in the cloud, and, like, especially in Africa, political leaders are often reluctant to, like, altroz into the cloud because I don't know where the data are maybe they also afraid that they don't have a way of like manipulating effects on the cloud, which would be important to him but it's not a good. Not a good selling, selling point. And then we talked about like data centers in Africa is. And at that time people were saying when nobody like Oracle and IBM dies and then the SAP guys were saying nobody is really wanting to take the risk to run the data center. They will be for East Africa or something like this because it will just not pay off. Is there, is there any, like, planning or thinking into setting up structures like that, that's interesting.
Yeah, I know Microsoft is I've got a data center in Nairobi. They have data centers in Johannesburg and Cape Town. So, in terms of the Africa, certainly Eastern Southern Africa. Microsoft probably had the largest footprint of data centers. AWS. They're an interesting one I don't know if you know that Amazon have a huge Development Center in South Africa. Most. I mean like I think there's something like eight or 9000 people that, that are based in Port Elizabeth or East London, and they don't buy any Amazon products but we write the software that delivers. And yeah, it's quite interesting that a lot of the, because he's got a lot of resources and skill sets, locally to help support it. So yeah, It's coming, and it's just a matter of time, because the government's realize I don't if you called me in here but our Durban ports, which is the largest port in southern Africa was shut down for a week because of cyber attack happened last week. Now you've got Zambia, Malawi, Botswana, export through Durban, and they got hit by ransomware attack.
What about SAP Are you, like, I mean Hana is or SAP one is mostly cloud based and are you planning on having local data centers as well.
Note because we, we have an alliance with Microsoft. So, so what happens is is that we, we basically, unless there's something very specific. Then, like if you're looking at courtyard P. A lot of the times we go to AWS or Microsoft is the hyper scalar and we just use their platform, our software.
Okay, well,
it's becoming, it's absolutely clear when you say that, we will go to say an insurance company, an insurance company will decide which software it will have, like, likewise, I mean government may award a contract to an insurance company to cover insurance unless it itself runs the whole show, insurance company decides which software to use. And now we will be put across tomorrow if you go and talk to the government and say, This is the guy in charge you know you've made any insurance to go and talk to him. We will end up convincing the insurance company about building blocks about our stack, bla bla bla. What could be, I mean it's like six months around the karma will be in this ship.
Well, yeah, I mean, keep in mind though that we're just trying to build specifications that are put out to tender. And then we get those back and then we try to assemble a reference like a demo, We're just trying to make a demo. Right now, I'm saying that a lot of every time I every time I like I asked Connie I'm like hey, I want some budget so I can, you know, so we can host some of this stuff and try to connect it all together and he's like, No, we're not doing that yet, You know, so, yeah, um,
we're just so I think what will help. I think what will help us as an architecture team what we can do to help is really take one user journey and fill all the blanks. Hypothetically fill all the blanks and say here is this only was a Germany. These three places, in different current building blocks, but then for this one, I put up two insurance company for this one, I like to talk to somebody for this one cup some, is that what we want to do is not to orchestrate the whole for Germany, or we're assuming that the insurance company will be falling in love with us to come and take all our building blocks, so that we don't have to convince them. And we just have to talk to them. I think that is the gap is we don't have this picture. Right now, there is no picture with with the whole picture isn't there. And so, we have kind of brainwashed. These 345 10 building blocks with and convincing the government will convince everybody in between. We're going to implement this, to take these building blocks. So it's the serious marketing things to consider.
Yeah, I mean unfortunately we're not marketing people though. So, least I'm not.
I see that guy but I think should be, not your problem, but then the steering group has to work around for finding someone around this, who can very clearly say how to listen to make a certain thing happen. We will build the building blocks RFP. But you have to build them together into some workflow. Yeah that is very intimate.
Well, I mean I think we've identified the need for several building blocks already, just with the existing use cases and workflows, I mean, I did ask Valerie, by the way when we would see like the ID. You know, user stories and she said, You know,
last meeting yesterday, she was, she was reviewing internally. Yeah, about our own. This cross border stuff, use case, but the other two use cases which if you remember, was his World Bank, guy.
Yeah, Jonathan. Well I guess he's been on vacation. That's what she said she just said, oh, you know, the World Bank guy who like he kind of like
those use cases where that said no, this doesn't make sense, we have to make an alternate use case and he's like well
let's go make this doesn't make sense. We'll make an alternate use case and I'll go on vacation for three weeks or something because what she said happened,
waiting for him. Yeah. And she's frustrated because guys saying,
Yeah, exactly. Exactly, so that's like an update on that stuff. Um, well yeah so I'll raise it with the marketing people and with the steering committee, I mean, um, you know, honey is a little bit out of pocket. You know, for the time being. So he's got some family stuff he's dealing with I think so. Um, yeah, so it's kind of up to us to carry the torches, I will just kind of highlight this as indeed, I mean I don't know, you know, to address your specific point Ramkumar I'm not sure that it's a good idea to add any more
people back to the list of building blocks, you had dial dial in all the building blocks for Mr. Dial building blocks.
Oh, I don't want I don't want to look at the the dial ones which which one like on on the go on the website.
No no no no. If you go to the dial side, you had our use cases listed in that same somewhere, building blocks are also listed.
Yeah well so like you're talking about the catalog of digital solutions I won. Oh my gosh, it's, it's totally changed layout, like, Oh yeah it's changed all again. Hold on. Yeah, I mean that's the thing it's like I'm not sure.
1618 building blocks, out of which we sample five initially.
Yeah, well here's like the use cases right so
I guess no I think the blocks in the building blocks.
Yeah, But then in here there's a bunch of like building blocks, you know, that are
23 Yeah, yeah, there's 23
Yeah, where are you.
Yeah, it's on.
You go to the catalog. Yeah.
There was a tab, or page earlier saying right here. So, yeah, yeah, so
that one. Yeah.
So I'm saying that, Have we, I mean, this is 33 and we're doing fine. Oh, first of all, we don't have enough.
Well yeah, I mean that's that's pretty clear. I mean I think everyone knows that.
Um, and missing stuff I don't know whether there is there is there an accounting stuff here. No,
no,
No, but there is, there are accounting
products, which
is two vehicles, one isn't is open source, but not free. And the other one is specifically for farming applications. So, you know this, these kind of building blocks are very much sitting in the functional force of the non functional or the technical domain. So they're either things like 14, ai workflow repositories, you know, that kind of stuff. Or they're, you know, hard, hard underlying
technologies in the billions in that sense is not dealing directly with resistors. It's it's
yet on the boat. Yeah, it's what I would kind of define as that sort of cross functional kind of thing where it's focusing on mobile wallets and digital payments and E payments.
So for an IT system you would need payments of course but then you need many more things you need accounts you need settlements you need reconciliation, maybe reconciliation as part of the accounts, but then you require all those who require audit reports.
Well, I think this this was the conversation I had last week around with, with the payments guys because they said that they're not going to propose that the obviously the. There are, shall we say central bank solutions there are banking solutions there are Treasury solutions, and their building block is only a mediator between them. And this was something I think that took a long time for everyone to fully understand. So they are really just more of a gateway, and a way of handling the payments so you can send out individual or bulk data, and it will then figure out where the payments should go. Does it go to mobile money does it go to cash or does it go to wherever, and it kind of sits in between that, so it sits halfway between kind of mobile money, and the banking platforms. So that's really what it's for, is not going to do any reconciliation, or even settlement.
So, what, what, what is your Frank assessment of that kind of value proposition when it comes to. Then are we saying you need to have an entire financing system please go and buy that and by the way you buy this one from from me for $1 stack to plumb. That system with some other system is that the value proposition. Yeah, because you
governments are gonna have some sort of accounting system anyway I would think you know that
that is a given, all governments will have some accounting system I just that's what I'm just thinking, Are we proposing some do logic Kieran there, which many people are there. The point is, are we trying to say next generation digital governance system being built out of building blocks. Right. So I think there is a panel, paranoid thinking of about, oh my god I cannot go and tell these guys this, but if the United Nations cannot do that. Who else can do that. Right, so I'm just saying that we should not think like a private limited company was diverse that to get the next quarter. Right Dr and I'm, I'm very convinced that was not the direction that direction is. And in fact, the, the, somebody from World Bank yesterday was mentioning, right. So, you have to look at what exists and so on. I'm saying that it's actually, if you go back three years or two years. While bank looked at this, basically, to say that I was saying that 60% 40% is the same stuff that the health ministry buys and The agriculture ministry buys, and somebody else buys and they're all buying the same stuff instead of reusing what they have, am I paying these guys, four times eight times 30 times because there are 13 ministries. So, if, if, if the all these guys are coming to World Bank for loan. And if they're buying. Taking that loan buying same thing 10 times. That is where the value addition is you're saving that 10 times, but if you're still saying that oh no no no you go and buy this financial system and by this accounting system by that system, whichever you want. I'll just give you a plumping logic I don't think it's a great value proposition.
Well I think it as I said they are some open source solutions but they're not free, you know, And ultimately I think whenever you look at this, your, there's going to be money involved some way, you know, a banking switch, I mean just the infrastructure to run it is, is money, it's not for free even if you get the source code, you still got to have high availability and have secured and, you know, all of those kind of things and I think that there is a recognition that there's some in terms of consolidating across agencies. Yeah there's scope for that. I mean, if for example you had one, three say government HR system that managed government.
Exactly, it doesn't matter where they hire where they fire. There are certain firing and hiring logic, and that law to be in one place. I agree completely with that, there's got to be accounting accounting is a science, it doesn't become something else just because you move from this department to that department. Right. So I think that's where, if you don't do that if you don't have an accounting building block, and you're depending on somebody else, and that's somebody else's super customized to a particular department because for him, business sense as selling 25 Of those, and not to make one. It settles everything. Yeah,
I mean, it doesn't, it's maybe not as simple as it seems, particularly with governments, because each agency has to track its funds. So within public sector funds management is quite critical and budget management. So, usually with HR. HR comes out of the fund, and comes out of a budget within the fund. And when you centralize the payroll as an example, but don't centralize other things like project management, because not all agencies have project management,
and housing, budget, no I. Okay, this is something that we had to work with the government because for example, in India, money for IT infrastructure, I mean I'm saying government infrastructure is all under IT department, no matter who else consumes it. So far the internally for the IT ministry. Right. Their customer is health ministry their customer is agriculture ministry Human Resource Development Ministry blah blah blah. But all of them among their budgets, they transfer something to the IT ministry in order to create its budget for automation and blah blah blah for the next five years. That's our five year plan is written right so they, they get cross program and the budget gets cross pollinated from within the ministries from one industry to another ministry niches, there is a consumer and a provider within them. So if the ID ministry is not taking care of automation, there's no ID ministry, then there is an issue.
Yeah, but I think it's going to be a tricky, tricky subject to include, you know, all of the various components that you need for example for for a fully fledged payment infrastructure so if you take Atreya I think their central bank hasn't got a real time payment switch. If we were going to propose one, I think the Mojo loop doesn't fully cover it, you'd have to go to one of the other ones. And if I have a look at some of the other product products they're not even products their standards. So the open banking one I think was a set of standards. The only one that I think that was a true sort of product was the country, let me find my iPhone
seven fineract.
It was something like that, my false, yes. Because that does provide a lot of the elements that you would need to be build an infrastructure but even then it's not fully complete.
Yeah I mean I think, you know, the reality is that nothing is going to be fully complete right I mean we're gonna end up even if something is put out for tender and this is kind of what you're saying. The payment group is discovered and I keep trying to bring this point up, including yesterday with people is that this is only, even after they're brought back for 10 You know from tender right they're still going to be, maybe 70, maybe 60% Complete. There's always going to be some work to enter to integrate it in the current, you know into any even into a test environment, right. So we integrate with sa P's payment system as a demo that you generously proposed right for a demo platform for payments right then, you know, we'll be essentially taking the open API and bridging that into sa P's payment API's like there's always going to be a fairly substantial amount of work to make one of these building blocks work in, you know, a given environment,
but then just tell you, you will have to do that to find some platform find platforms like that. Well, you're gonna find that.
Yeah, I mean, I don't know, I mean it's like several stages down the road I mean it's like stage four is like, you know we're in stage one. Then we go to procurement then we go to demo, then we show that around, then some government gets excited enough that they say like okay, I want to build a prototype or I want to I want to do a prototype in my, you know for my government that's sort of step four. In this process, and at that point, you know, who knows who pays for the World Bank, you know, maybe the UN i don't know i mean there's all this, it's it's kind of amazing like people keep throwing money at the project, right, like we didn't ask for it, and now there's like, 10, million euros. So it's like I assume some of that is gonna go towards like, you know, actual attempting actual deployments, but I mean it's just it's a long, we're a long way off from being even being able to do that right, so, um, you know, I think is the reality. So in the meantime we'll have this nice blue and this nice interoperability standard, you know, but I mean I think the, the other person who might do it though, is some payment company who's super excited about the opportunity of like being this, you know, kind of, first on the App Store. Right. Maybe that's SAP I don't know. Uh, you know, that they do the that they, they kind of contributed an integration right I mean. But usually, that doesn't really happen right I mean, I think it's the burden really is going to be on us to build example adapters for SAP, right, that proves out example, an example adapter for fire to connect to healthcare systems that just does some small, and I think that's the way to kind of get more interest and more you know like I think it's clear to me that the architecture group that we need to, you know, or that part of this process is like. Once we have these workflow building blocks, we're going to need to build out adapters somebody is right, we're going to need to write a spec that's like, here's the SAP adapter,
yeah, guys like it you are brand new to this concept. We did this up in 98, in the Bay Area with what we did was to go and buy a reference code reference architecture from it for the various codecs that we wanted to put in voice over IP. There was C, there was a C program that was available, and you had to pay for it, and you had to license it out of it you. And that was a reference standard it G dot seven to nine was the reference standard like that there are several reference standards, so people went and actually paid for it to go over the baseline board which is a vanilla C code, it may not be the best optimal whatever but it works if it works according to the standards, and they took that, and they had to convert it into their own reference platforms and everybody did. You know, name anybody was building a VoIP platform in the base references come for G dot seven to nine from it. So, like that, unless you have a reference model that you can. I'm not saying that you should monetize it, I'm saying, unless you got a reference model to refer to and say, this is the input the output, and if I take this and implement in my own way. Great, I will be able to do this. It's really otherwise just, again, instead of TPT we'll have a Word document. Beyond that there's nothing much. People will see in terms of tangible stuff that they can take off of the shelf. Right, so I feel this is not new. This is not new to it you got tons and tons of candidates written out there. Even today if you go there, in answer to my multivitamin, two, three, you will find reference for there, you can, if you're a member you can buy. So if that way, we ended up putting reference code of building blocks, it is a baseline, they can take in extended, they can modify it, they can, whatever. Very free of the specifications is all that restrict what goes in, what comes out is what we stick to but basic functionality, word of define, they can extend it. So, in that case if we don't have even that. And I think the RFP is meant to create that kind of reference models right. Yep. So then we should be only focused on saying, Okay, how many more Building Blocks can we actually map, you know, and keep mapping and create a stack. Yeah, well, well, what are you building blocks.
Yeah, well, I mean fortunately we're, you know, gonna be onboarding, three more groups so may think figuring out that, you know what we can do to actually make this probably successful is to look at how the onboarding process, right. I think that's like a big, big thing, you know, is this worker cookbook the right way do we need to, you know we do we need more videos of that, you know, Steve had this great, you know, comment about considering, you know, extracting functionalities from existing digital goods. So, um, I mean this is going to be starting pretty soon. So I'll just put a link to it again here.
But I think it kind of goes back to the point we need to get a more narrow scope from the cub scout team because there's too much coverage and not enough resource. And I think, you know, if everybody's pulling in slightly different directions or has a different perspective, more likely, then it's unlikely that we will come out with something cohesive that the government can do. And I mean to run from this point, if there was a government that said Well listen, we don't have a payment infrastructure is gov stack, you know, able to provide us with that. I couldn't answer that question based on where we are today. And I think that that's where they need to come up with a bit more strategic direction about what exactly it is and is not, and they need to be more precise about it because otherwise every time you open up a building block you just end up with either more gaps or too much overlap. So I think that they need to focus on, on what what is their desired outcome. And if they had a first customer in mind, what would it be to keep it simple, because I think, you know, it kind of showed yesterday as well. It was a big fragmented fragmented, you know all of the building blocks. If somebody is sitting there from a government agency they were saying, Well, how on earth could I use this, what what problem would it solve. And the outcome. And there's always a risk would you take a bottom up approach that you come up with a really good solution to a problem nobody has. And I think that that would always be the thing that we would try and involve and say, in that region, what is our outcome. And I think if we can't define that within this group, I think we're going to struggle to get these specifications finished until we get to that point.
Yeah, I mean I call this, like, you know, day one with with honey that the fact that we're not actually addressing real users on the ground is a huge risk, right. So I think that's just kind of like the nature of the, of this project right and you know, Until we actually have target customers, and the use user stories that are built around this target customers, right. There's even like this, kind of, I always see the customer is the citizen right but they're not really, it's the government but I feel like if we're not being citizen focused then this thing won't be useful at all, right.
And it's a dangerous. If we don't address like the essence digital principle design with the user. Yeah, and from all the principles, whenever I visit people go into digital projects. That's the first one you hear design with the principles on my team, principles, which I like. I'm not really important to them but design with the user that's always what comes up from the program managers and if we don't have a good answer on that. That could be quite dangerous.
I mean that's why we do these user stories right but I mean, they're completely like Intel they're based on actual users, you know, I mean they're entirely made up right. It's like we have to start somewhere. So, you know once based on Djibouti and the actual, you know, users the actual constraints and the actual gap analysis of what we have and what you know what the what the government needs right what they have and what they need, like, it's going to be very very difficult. So I mean that's kind of just a big risk with the project, I think, but that's just the nature of it.
Yeah, frankly, that, that cannot be the responsibility of the building block groups, right now they need that they need a scope very clear scope in order to put out the specs. Yeah, the scope gap analysis which has to be done by somebody who understands the system. Yeah. All right. So collusion. Yeah,
so, you know, um,
yeah, yeah, okay, that's a clear call out, and one clear I mean what is clear about is that we have done well in five groups, and five building blocks, and that has itself spun out another two three building blocks, sub building blocks and separate building blocks. This is a good direction to go as far as when we are setting this course, and being this this course should go on, and we should keep populating more and more basic building blocks without, and they should not be burdened with the responsibility of trying to showcase that. You know our whole healthcare we'll use this, somebody else to use the ongoing borrowing to define it.
Yeah I mean I think they do need to, I think we do need to really spend a lot of energy in making sure that we have at least a story and a plan for interoperability Right. Um, I think that's super important
and reusability, I think, because if you can show a particular building block is useful in five things when they were investing five time per year. That's a selling point.
Yep, exactly. So I mean I think I'm wary. You know I think I'm really excited to see the World Bank use cases. First of all right. Whenever those appear, I think that's going to be great because those are going to be based more on experience on the ground, then you know what we have now. Probably so. Yeah. And and I think that I you know it just I would be really cautious about adding more use cases. Until we are actually you know hopefully now that we're talking a horn of Africa Initiative, and you know the Ukraine and there's this list of countries like maybe we could narrow in on one of them. Right, and just try to build the use cases around that, like that would be my kind of recommendation right is like, let's pick a country. And like a target deployment and if we're going to add more use cases, let's add them around that, rather than
our quoting, then the key. The key aspect of reusability comes when you cross pollinated in different domains. Yeah, so you do need more use cases for the same building, but to prove it is worthwhile using it. Yep, maybe in a good zone, but that, that, that sampling of different examples are required as a value proposition.
Agreed. So I wanted to show you guys.
Can we can we kind of converge on on a list of building blocks now at a stage where we are we about these things mapped out the next few things. People are coming in. We have made all the action we create another roadmap to say okay these four done by one team are going to happen. Well next four will be.
Yeah, I mean it's worth noting though that we already have. We've identified the need for workflow messaging scheduling marketplace already, like we have, you know, basic functional requirements for those even though those workgroups aren't even spun up yet so that's kind of encouraging because like at least the user stories have kind of generated kind of concrete directions and fortunately we're doing some of these in the next batch right, I think workflows one of them. Not sure about the.
I'm saying one step beyond this. What next for building blocks. Yeah, which, you know use cases may not be there and so we trigger guys to use cases on that. Well done.
I mean I think this, the, the 1234 There's four there. And then the fifth that I would propose is networking. Right, because that's like a huge gap. You know,
that is the security stuff there, but then, do you think the same guys can do that. I mean as a group. Now the building block,
no they like expressly said there, we're not doing that because we're not networking experts or security experts. So we need. Yeah. So, you know, I mean I think that that's probably what all, you know, I mean that's five right there, right. Um, and a lot of the use cases like the hypothetical dial use cases were kind of depending on messaging anyway, right, like they, there's like this. A lot of those steps in the user journeys even for like the two user journeys like the two that we're focusing on this postpartum infant care and unconditional Social Cash Transfer or depending expressly on messaging. So, um, so I think, you know, once, once we have those, then we can you know I think we can add more but I'm a little bit wary of adding more use cases because I feel like we've already like, I think they should come from the outside, I guess is what I'm saying. So they come from the World Bank, or they come from my country. You know in country like an actual potential partner, then I think that's a, that's a good direction. But I don't think we should continue making up, use cases, you know, and as far as making up new building blocks like we've got five that we could do, and that's plenty, in my view. Right.
The network one is the most important one because if you take this to the World Bank that cyber security is non negotiable. Yeah, so this they have some kind of RFP for a platform, then, then they're not, they're not even out of the water. So, right, you know, and very, very nice, I think, you know, If you were to say that we wanted to have a because this is what I think we need, you know what, what's the first solution we're going to solve, because that defines the building blocks, we need. So, if its ID is to say registration and linked into a payments engine. So that's the MVP. And it's got to be secured in our platform, so they, you know your thought. You can't have less than that because no one's going to use their desk, or something, you need a lowest common denominator, to work from an inside right, what's the next thing that we need to add but strategically they need to come up with what, what do we say is our low hanging fruit, because at the moment, the scope is too broad, and I think the teams are focused, and where the teams have made progress is where they have been very specific focus, and said, these are the outcomes and examples we're dealing with. When you go into the generic, it just disappears into an either.
Yeah well, agreed. So, you know, I guess. I think as far as it goes. It'll be great to have some use cases that actually integrate foundational ID. I think it's probably good that those are coming from the ID group. Right. And, you know, and hopefully they're really well considered and they're closer to the realities on the ground and then. My hope is that by adding these additional use cases, you know we can focus in on one of them and say like okay well this is going to be the first demo, right. Um, but I don't know exactly how to do that because we have to pick a country we have to pick a venue we have to pick a partner and it's kind of early to do that but I, another, another thing that I wanted to raise with you guys is this whole procurement process I think I talked to you a little bit about this last week. So, we're in phase one right, I mean if you look at this. Which one is it. Oh geez, here. So, yeah, I mean if you look at this cookbook like we're sort of in phase one of like what we're doing right. And then this, you know, a reference, like that tender process is just being designed. Right. Um, and so that's another, you know, and then only the So, so I guess like each one of these is kind of adding risk, right, like I'm kind of more used to designing for a specific country. Um, so, but I think what we can do is maybe try to take a hands on approach to managing the reference, like what the actual implementation of the reference building blocks, right. So that's something that I was kind of advocating for I don't know how you feel about that but I feel like if there's if the NGO stack is more actively managing, or at least actively involved in the management of that development will be better we'll be in better shape and if we kind of take charge of the stewardship of it, right. So, certain things like requiring that it be done on GitHub and that we have a specific, specific way of doing issue tracking and that we're kind of like actively involved in this sort of agile process of rearranging and reprioritizing stuff, then we'll get closer to actually step three sooner, is kind of what the argument I've been making in terms of like how the, how this kind of tender process goes. So I don't know how you guys feel about it. But I
might say, it was, let's say from. Let's take an example and see if there was a specific country in view on Africa, Africa again seems too big to bite right now. Like, it's talking about regional stuff and so we're still fixing ourselves and extending from one country to one pilot something and what. So let's say let's say some some target country signed up and said okay guys from tomorrow. Let's start working, and then
some, we're sort of talking about step five, then right.
Yeah, yeah, map to map. See building blocks will be modified configured, deployed to support them. Before that, what modification configuration deployment has to come is dependent upon the needs of the country, right. So, somebody is. That's why I'm saying the product team has to go there. They should know ghosthack On the backside, they should know the requirement of the government from the front side, they have constraints there, whatever you know the politics that constraints that blah blah blah, which will all finally decide what is the priority and what are the five minimum things MVP, that, that can sell there,
Right, so, but we're sort of, we're, remember we're in step one, right that's What's so weird about this process, right. So, step one, yeah. And we're making these specifications and then, you know, now there's somehow I got looped into this meeting about the tendering process right designing the process for putting these out for 10
Yeah, I see it differently. See, that's where I appreciate Inmar schoolwork, because it's good, it's got a building block in the sense that he can configure anything in that domain. Yeah. So in that sense if the payments guys come up with this building block which can be used to configure any type of payments process. For right now they are let us say they have six different methods of payments that you can configure easily. Then they make it 16 Tomorrow, that's their roadmap, but then, then you have got something that you say that, as far as in payments is concerned concerned to forget about the problem, we have got all the stuff in our toolbox. Yeah, and this is payments like that, in order to design that if we, I mean, I think, to find completely, that if we had a customer inside a very tangible assessment of these for our sakes, that we are putting in payment gateway, it's a requirement building block or another building block are enough, Or is that something new. The Seventh One, which we have not seen so far. Yeah, but if you waited for that in order to populate your first four or three capabilities in the building block. The challenge two years ago was that, that's exactly the problem we had in terms of saying, Where do we get started, who is going to give us the use cases, without trying something that's already on the table. So we said okay, let's create hypothetical cases. Take some programs running here and there, sample them and take it, which is still good. Okay, you don't have to have necessarily a customer signed up to do that, we looked at, agricultural programs we looked at UNESCO's education initiatives in some places and outdated health care. You know what's happening in India. So we got some glimpse of it doesn't mean that all the use cases are mapped out. But we got some 234 capabilities that are definitely required in a building block. So, that is the step one was. But step four is when you have sufficient you know you're got a stack of capabilities inside each building block where you're going to map them and only do a differential analysis, something is missing. To come back to the drawing board. If not, then we map it. So, so it's kind of chicken and egg if you wait for countries to sign up, they're going to ask you what do you have, and if you are working ahead on some assumptions. You may not have all the capabilities that they need,
but we're probably not right. So, I mean, that's why I think this work about figuring out how we interoperate with existing solutions is so critical, because we're not going to have
any, any input for artists to look at existing DP G's and map their capabilities,
and a scenario. The scenario that I described with him and coming up with his registry tool and claiming he can build a solution just out of the box. That was actually my night person might scenario just imagine, we get a vaccination distribution thing. And then they will come up with the mouse tool instead of using a dedicated open LMIA. that is already
qualified by state statement. What I meant is the kind of building block registration thing has got that it can wait up any night or Screenflow and register any kind of data. Is this a capability of the building block or not the whole solution I mean, in my claims you can build a solution for the planet. That may be a different issue, but I'm just looking at. Similarly, you just take, you just take payments blog for example, right, they, they have, We give them one use case or two. And they saw different methods and capabilities report which were not there in the two dial use cases, and they came up with alternative scenarios pathways, and so on, closing those capabilities within six months. So the point is answering that is an ongoing process, we cannot say six cities. Maybe there are 60, but we have to have this parity, that we have to go with five and start working with some target demographic. While kitchen is still running, we make 616 2025, as we discover more. So there's got to be a milestone, where we say, okay, good to go now, I've got this little thing, you know, this version 0.1 Whatever, let's go. Question one, what is those that question one. Yeah, how many capabilities.
My well. That's why, you know, when we put these out for tender. I mean there's kind of two ways we could do that, we could say like, Okay, here's a specification. Come back to me when you're finished. Right, yeah. Or we could be taking a more active role in the development, you know, and at least.
If people are saying no, this doesn't fit what I need. Then we have a play, you know I see we have a play because if it doesn't fit what they need. Then we have got to dialogue where to say okay what do you need. Right now there is this gap between I'm seeing, what do you need somebody knows what can you build somebody knows in between. Yeah,
certainly. So I mean, so
what if you extend this point to instead of writing, reference building blocks is built based on a specification, which sounds like you're building something from scratch, that you like, say, a building block is built on, or adopted from existing global public goods, like in the vaccination example, open Ella miles would, would come up and, like, do whatever is needed to get open Ella Maya's fixed, to be part of this scenario.
Yeah, I think that I think that's a, that's a great improvement
DPG is can be made out of somebody. If so, willing to start from scratch, or you can borrow existing DVDs and tweak them to match your specifications.
Yep. I think both those are great, um, you know I guess what I've been really strongly advocating for is that we have, you know, an active role in the development of each building block. Right, so that you know it's the development is done in a certain way that's out in the open. Right, so we can see what the development teams are doing what their priorities are. We can, you know, interact with them and change the priorities. So that hopefully we can get, you know, a really early alpha, that we can play around with sooner. You know,
I believe. So I think there is. Obviously, there's got to be an interaction. But I think one at this point of time, it's still not too late. At this point of time while we discuss how to do that. I think we have got a lot of work on hand, with four more building blocks and also existing building blocks. I mean, I need a figure of merit here are these existing building blocks really in a specification pattern now. Is this something that you can hand over to an RFP month or two months. What maturity, we need to bring up, in terms of looking like a specification. I think this is something we have to see because right now you still have a lot of inputs. I mean, max S. had his challenges in trying to get people populate one template. Right. And now from all those populations of five building blocks, and we get to a stage where it can be given out for an RFP. So this is something that I think we have to think about how much we have time in terms of doing that, because right now they're coming and handing it over to the architecture team, and each team is saying 100 over that one. Take care of whether it is right or wrong and tell us. So the expectation has to be very clear, just as much as you are saying. Max, the architecture team has to be involved in mapping out to a particular demography, and it should also be in writing, agreeing, how to spec it in the specification.
Yeah, well, I mean we will be, I mean we're going to do a formal review of each one of these. So,
yeah, I tend to agree. I mean, if, if you sent a building block definition template out to a company and to the distant RFI they'll just say well, what do you want to know. So it's really kind of a statement of solution rather than a statement of requirements about what the system must can and should do. And in some cases as we separate things like security is just essentially just a list of is a catalog of requirements that each of the building blocks has to incorporate into their own. So I think the point that you're making is very valid and I actually didn't, I don't have an answer, because, again, you
just want to do that work. That's it. Yeah, to sit down and do it and I don't see many there are such capabilities in this building block groups and I don't, I don't think there is so much of capability to write a spec out in that way, a formal spec, while they may be able to map the requirements very well. So in the end I think Max it will land on your table. There probably,
you know, and that's okay. You know, that's fine. I mean we can do that. It's just,
yeah, put it on the roadmap and stand up there it will mature or some time, but at least it's good because we will know is involved. Okay, so I'm just gonna add
reaching into the same gap. I think when I look knowledge number four when you talk about the sandbox. And the ddpg is I think the two steps shouldn't be too far away like an agile approach he would try to bring them together as soon as possible. And there, the question comes up for me how do you structure the tender will you have one tender per building block, or will that be one big tender for all of it.
That's part of the debate, right, I mean,
yeah. Just a second. If you do one per building blocks and you have to make sure that you have one overarching candle. The practical things of running the sandbox and making sure that things like install together and, because if you if you give them responsibility for central management to the building of groups as a whole. They will not be very organized and will start blaming each other as things don't work so it's always good to have one neutral implementer in the middle who can do the quality assurance and stuff like that and just make sure that this thing is up and running and works together with the other building blocks. Agreed. Well,
I thought, I thought this specification is perfect and interfaces are designed perfectly. They're supposed to act like black box, you must be able to marry these building blocks without consent issue, that's the assumption, And I'm not saying that there really would be particularly, but that's the assumption for which you write a spec. As long as it follows the spec which.
Yeah, but still I mean if you have different areas of responsibility. People tend to really, like, stop at their system borders and not look at the other system and when you talk about interoperability then you always have to have both sides in the same discussion. That's where
my what Max was saying matters a lot. There's got to be an overlap with the architecture team who can be, you know, RFP will happen, and building blocks will build, and then you guys come and take a look, I don't think that's a good process, there should be a hand holding. And there must be an overlap.
On a technical level, it can't be like Max or anybody of us like doing this, doing the installation on sandbox servers, stuff like that, must, must be somehow. Technically,
it must be the technical team, which takes the responsibility but then must be mentored. What would you say, what's the right word, it can be kind of guided by the architecture team, because otherwise they will become a silo.
I think you're right, but I have an answer, because you know you can't really write a specification for something that you don't know what the problem solving is going to take again look at the building blocks, I mean, if the requirement is not for citizen ID, then what's, what is your requirement.
I have a different view there where it depends upon the level of aggregation you are looking at, say for example, if I am designing style. Okay. I know very well to design a style, but the guy who's designing a catering store is probably also requires a stop. Isn't he saying I need style, but he's not going and speaking out. So we are like that, we are defining how the stuff works. You know how your fan works and how we were probably the pottery to works, but we are not defining our home is built right whereas the home guy requires as power as a modular piece, requires a water heater and a light and a fan as a modular piece. So in that sense, building blocks have been defined at absolute that granularity. But the drive was defining how to use all these and stitch it into a home or a catering service, or a healthcare service or whatever service that I'm saying that's the right team, so that guy has to define and manage because they are seeing what actual information flows in between these things, and which way these things will interoperate. But if, if that were built building these power when fan and whatever, are just given a spec, and then they're supposed to build it still be this one, backside. Data Inspector saying you're building this stuff for a home, You're not building this for a restaurant. So, there is a difference, even though you call it. So, there are so many options. Yeah,
I was actually kind of being with you but I think the point still remains that you were putting the cart before the horse, asking for requirements for problem that doesn't exist. And it goes back to the very first point. We need someone to tell us what I expect or what their best guess at the solution we will have to build as part of the prototype. And without that, frankly, everybody's wasting their time. And I think this is B, this is manifesting itself in the in the workstreams, is this a okay well, when we do get a use case for country A B and I'm gonna have to redo half of this anyway so why get it to the point of completion. Because specifications are simply not valid. I mean they're simply not valid. So, I think this is why we're getting pushback from the teams, because there's no clear outcome. Well I think it's basically Yeah,
I think the outcome is though that we're gonna have something that has an open API specification that we can use to validate functionality in some way by by manually assembling these together and trying to build a working solution but you know that that's the expected outcome but it's, it's not going to be a working solution, like there's going to be some amount of work done by somebody before it becomes a working solution. So, yeah, yeah,
but what's the solution going to do this is you don't, we don't
really know until we're dealing with a specific country in a specific application
or a best guess of what that specific application would be I mean, the thing here is that nobody is completely ignorant as to what the challenges are in these countries, but someone needs to make a decision and it's not this forum. Right, that's I think we made it up the absence. Now we've got to the point where I don't think there's going to be much more progress until we've got that and maybe we should have mentioned that in as an outcome in our meeting yesterday.
Well, yeah, I'll raise it, and the reason, the reason I have been raising this by the way, I just don't want to raise it in that particular forum because it's kind of demoralizing, right.
And and this is, this exercise has added value and I think for every new building block, it will go through this exact cycle this exact phase where you don't have a immediate need for the building block, you're hypothesizing five things that it can do and then you get invited to have them go to the dustbin. Three capabilities, you add to that cycle will go on, but to get a starting point, you need to have something to show, otherwise people don't take us seriously. So that, I think this is an ongoing process. For every new building block this will be an ongoing process. You have to feel this level. When you are able to say, okay, how am I going to implement this without this customer. And then we'll we'll jump to the next level. At that point,
So I feel like, Yeah, I mean I feel like this is, this is something that we just, I need to raise with honey in the steering committee, you know, so I'll do that Monday, and just make this you know point again. Um, so I did want to. I'm just looking at the clock, and we're you know we don't have a ton of time left so I just wanted to revisit some of the, you know, previous key decisions and like other stuff that you know I'm right from last week so I just wanna make sure we don't, we're not missing out on any so we already you know, so we talked about open Ms. And you know how we need a fire, interoperability adapter we talked about this last week we talked about the payments team and your discussion Stryver last week.
By the way, of openness I've fed back that he was surprised that they were a bit reluctant. On the last developer call yesterday. So the feedback then was actually they think it should be quite easy to convert fire to open API. But I think just the start over discussion and we'll we'll go more into this, there might be a call where, well we have a deep dive like on what it would look like if you convert fire to open API. And I don't know if you want you can, I can invite you for that again.
Yeah, please. Yeah, I'd love to. I mean, you know, I think, what would make both open MS and go SEC stronger is if we somehow work together on one of these things. Yep. So, you know, I don't know what the best way to do that on a pragmatic level is I mean, maybe we build a, maybe we build a prototype, and then we're like, Okay, here's a prototype that handles one of the fire API's so, you know, a or something like that,
eventually, yes, but at the current moment I think it's important to keep the discussion going, and the life. Then we can like narrower in more precisely on what is really needed on the technical level.
Okay, great. So then Ramkumar you presented your checklist to track progress. I think that's a really good thing. I just want to, it's it's good to review these things so they just don't disappear down the memory hole. Well yeah, so great work on that. So I'm just, you know,
let's establish that one. Next, all hands meeting. Okay. Okay, uh, the group, you know, stand up. Okay,
great. And then Trevor, you gave an overview of this, you know, proposal. So I just want to close the loop on that.
Yeah, so I put it up on the, on the Arctic's page, I must say I tried to edit it in Google Doc, and it didn't work so well so what I might do is just, it's gonna be quicker for me to in Word because I know how it works. And then to keep uploading versions, rather than trying to within
oh yeah that's fine I mean I you know, that's totally fine whatever is easiest. I mean, you can upload a Google sheet like you can upload a docx, right, and then it will attempt to allow you to edit it, but it doesn't always work so well. So is this the document.
Yeah, yeah, so I was trying to the numbering right there just the format and layout and, yeah, kind of got the numbering wrong so what I'll do is I'll probably take it, just keep a version of my machine. And then, just, just keep on updating that version.
Yeah, I mean, That's fine. So, is there, you know, an action item we want to take with this I mean are you still, still we're still working on it. Okay. Yeah, great, I just want to make sure that
okay cuz I mean it's such a critical thing and, yeah, I need to just get it done. Yeah, okay, good. Great. Yeah, so, and here's the key decision
on point number one I think it's a question mark, it's not a statement, but is it um, is it more a glue that brings us to be better. Okay. That's a question,
yeah this is just my like I tried to summarize the conversation. So, you know,
I like a blue but I'm Franklin value is not just being a blue. Yeah, it can be a global unicorn in our direction. Yeah how complete, you know, solution can be 7060
or 70%, complete. After we received them from tender reference implementations.
Right, you know, those the 30 to 40% integration work
on customization. Yeah,
integration and customization. I mean I don't want to put too many these comments in here, Because like maybe it'll freak people out. So, yeah. So I think these points that way. Ooh, they raised. Oh, I didn't mean to do that. Um. Oh come on, open my comment history. Yeah, so, um. Okay, so this is good. So I just want to capture these because these are good, good questions. Right. Yeah. Yeah, I guess I'm kind of advocating that we do the central management which is kind of insane but we'll probably get the best results is kind of my feeling,
don't manage the implementation but man is provided. Exactly the kind of
thing, which was monitored closely, but if you really want to do like the installation and making sure that I don't know any any raw logs are monitored on the server and all that. You can't handle it, you just go crazy. Yeah,
about maybe, probably an outsource work for some company to do whatever. Maybe, but then the dominance of that work, which I think might mean central management. So, yeah, okay. Yeah. Okay. Okay, um, yeah,
I mean there's a bunch of open questions right, how do you call it, how do you like what are the acceptance criteria. Right. So who, who, who, who's who, you know, signs off on the building block once it's like been delivered, you know, um, yeah, what are their selection criteria for selecting who delivers it. Those are the kind of questions that I've been asking about this
is a big area who would pop them.
Exactly. Okay cool, so we're gonna continue so I just want to review these real quickly while we still got time so we reviewed that. So you're gonna try rolling using it. Well, I don't know, we'll just see how they do. Let me security's already filled it out. Did you see that. Yeah so that was, that was it. Yeah. So, alright, and then this is still the same. Right, this is still the same. And yeah, so I like this, I auto publish from Google Docs idea as well, but I want to make sure that we have a standard first so. Okay, great. So, um, yeah, I just want to make sure we didn't lose anything. Anything else that we should cover today.
Yeah, there's quite a bit of admin to do, I will have quite a large project starting soon, so it's going to impact my availability. So I wondered if you had a choice between me doing the Thursday stand up or during this session, what would be your preference.
Ah, geez, that's a tough question.
I mean,
now, because I've got a couple of weeks of storage all sorted out. But it's, I will be sort of getting additional pressure on my time, you know starting within sort of month or so probably at the end of August, more than the beginning. So we've got a bit of time to think about it, but you know they the capacity issue we just need to shouldn't be cognitive sort of, so we don't need to interrupt now but
we need to be aware of it. Yeah, I'm just going to note this. Okay.
Um, all right, well that's that's noted. So we can think about it, I don't have a good, I don't have an immediate answer, we can say both. Yeah, yeah.
Okay, just has to be consistent, you know, just because it will be at the moment I don't currently have a full time project, but this will be full time projects until the end of next year. Okay. All right. So, you know, I could manage a couple of hours here and there. But at the moment where it's kind of sometimes half an hour or more than half a day, a, a week that's when it starts to encroach, so that's why we just need to think about it.
Yeah, I mean what are your thoughts I'm curious.
I think it would be better just to remain in the Arctic for, because that's really the role that I was brought on to and then if I have availability to do the stand ups, just to keep an earring on to discussions then I tend to I would, you know, my feeling was that should be the priority. And then the stand up, I can do, as in when you know I'm available. Yep. Fair enough.
That makes sense. Okay. Um, so yeah, I've got a hard stop at five so um yeah that's fine. Anybody have anything else they want to raise. Um, I have one more thing I wanted to show you guys, which is like, this is like, Christos take. So, first of all, he's saying it's very important make sure that every component of OpenStack systems externalize one autonomous in its security so that means that it should be able to validate requests made to it and don't don't rely on the security of say a public API gateway or workflow building block. Right, so sort of like security in depth approach. So, what it means is it should be possible to make requests directly to a building block as well if it's open for public network and has its own API and you sort of like redrew this diagram up here. Right, so that you know these things are actually the building blocks are actually expose right on the open internet which is like you know, conceptually, probably not what you would ever do, but it's, it's, I think it's an important point, right. So you still have the information mediator to secure API requests but then some of those API. API requests are going to be, you know, so I mean I think you'd always use an API gateway is my feeling, but you should we may want to require that each building block do its own security assertions like validate the security assertions itself. Right. So,
usually also non functioning makes sense to do that. Sorry. From a non functional perspective, from system loggings and faultfinding and things like that, you know, it's also a good idea, Because if you've already got, shall we say, a large number of the capabilities that information mediator has then adding an extra leg into the chain can actually degrade non functionals, though, because it adds an additional point of failure.
Yeah. Yeah. So the point is valid. Yeah, I think so. I think it's a valid point, but it's also just like, I don't know, I've been sort of like in this happy place where the information mediator is, you know, handling security, and, you know, the building blocks don't have to be so concerned about it but you know I think this is kind of a good reality check that, maybe we should reconsider that.
No, as I was thinking of it this only goes to say that every building block has got a back end and a front end front end does its own exposure managed security and authorization managed by back end evolved through information mediator.
Yeah, well,
that is still there,
that doesn't really change, but you know I guess what he's proposing is that, in principle, there's no reason. So if each building block has autonomous security. And that means that it's checking the authentication and authorization of every request going into it and not requiring not relying on some, some external service to do that, which is a good practice right. I think we can agree, then, conceptually, you could just put that the API is out on the open internet and not everything has to go through information mediator. I mean that's kind of what he's saying I don't you know whether or not that's a good idea. That is debatable but I think
I thought max you had written out. To go back to just a little boy a little about. Yeah, you had you had very clearly indicated ingress and Ingress, and he had put a API signal. Yeah, so, so you you have that stuff going from within to external world through information mediator, we kind of had nailed that down right. Yeah, sure. Incoming, incoming lead to API gateway you don't need the mediator again.
Well, it goes through the API gateway then through the information mediator, so just two layers. But I guess what he's saying is like the citizen ID off should still be checking, you know, should still be validating the authenticity of request, even if it goes through the information mediator is kind of what he's saying, no, no
struggle right now if that happens it is that, imagine this that you had put this API gateway in front of each of these building blocks into a permissioned mediator. Yeah, that's what it would be, then there is no information mediator, there's only a gateway.
Oh I don't know I mean, yeah, well, maybe. I mean, so, you know, I don't know I mean I'm not sure.
Most of these independently, and sell it, I would put a nginx in front of this thing, then need information mediator today. Right. Yeah, well,
that's fine for the actual web pages, but what about the API's, so I mean I think, yeah, so this is kind of like it. It raises an interesting point. Right. Um, so I would just propose that you know, please, you know,
give your feedback there. I mean, I think it's a valid point, that you can't rely on API gateway for security is basically what he's saying. So, okay, well anyway, um, you know, I guess we can just make that asynchronous, sorry to throw that in at the last minute, but I was like interrupting and then you know he's got this other picture alternative view which is like yeah I don't know if this is the best one, but, you know, you could do, there's a need for an eighth, you know, right, so he's not sure is actually better but there's technically no need for a public API gateway, as long as each API is able to protect itself by relying on a security building block, right. So,
how would you implement single sign on. Well,
yeah exactly so you probably, that's why you would probably want to use API gateway, But I think what he's saying is like, even if you do, once the API gateway, a request for citizen ID goes here. The Tizen ID and auth building block should still authenticate that request rather than just trusting it blindly. Right.
So, I was just reflecting on that I was applying it to most. Yeah. And in his technical architectures sort of specified a whole load of, you know, it is basically on, I've put the link in the, in the chat too so you can reference it as well as I'm looking at it. It's basically based on either zero or AWS, on a Java stack with the spring development framework, and he kind of has some of the tools available. If we say looked through this technical stuff and said Listen, we didn't feel that he had the, it didn't have a reasonable API gateway, then you know the information mediator is mandatory. And so a lot of stuff by the way, I don't know enough about this type of technology to see if any of these tools are, you know like, development, you know, encryption or development validator or object mapper I don't understand enough about this infrastructure, to understand whether he would meet those requirements or not. But again, the the acid test and when it has got a proxy server, which is engine. Engine.
Engine X engine it's is that API, it has the capability to but it's
more of a proxy server the API gateway. Just to be clear, okay, yeah,
just the proxy Yeah, yeah. and he's also got a and so if you've kind of for example looked at that, and we say, well. Does this meet the requirements of the information mediator block, then it's mandatory. Because if it's not, if it doesn't meet the standard then, but I don't know how I would apply it, because I don't I'm not technical enough to make this. Yeah,
I mean if that's how that makes sense. I mean I guess I would I would advocate for keeping this architecture where there always is an information mediator. But then in addition, making each building block, have a requirement that it validates the incoming requests so if there's an authorization header, it gets passed through all the way here. The information mediator validates that somehow before it allows the request, or sorry the building block validates it here. So, I don't know, it's, yeah, it's kind of it's a big topic, Sorry to raise it at the last minute.
No, no, yeah the major thing, by the way is not passing through the information even later. So you still need an external URL those front end that exposes the UI of the building block.
Right, exactly. And that's why this networking component is so critical because we don't have a reverse proxy. At this point, at all in gov stack so. Um, okay. Well cool so, you know, um, yeah, good, good stuff to think about. Um, thanks for bringing that up Trevor I think that's a really useful lens. Okay, well, anyone have anything else we should cover today. All right, well, um, have a great weekend.