Built Triangle

built-triangle
Welcome M to Fusion talk with Anouk and Steve.
We are back.
We are back.
Yes, we are.
I'm m back baby.
We are back with a few Fusion charts.
We are on the road.
We are so. We are back actually.
Why the hell are we doing in this room recording when there's a beautiful blue sky and mountains outside the window?
Because we love doing this.
Yeah, I suppose so. So yes, we're here in sunny Austria. yeah, taking some podcast time, doing a bit of this, a bit of that, a bit of everything else and we're gonna do some live quickly released podcasts.
Yes. First time we are doing this live.
It is a bit and it's, it's not actually live. It just basically means I'm not going to spend hours editing it down.
Oh yeah.
Yes, good. So everything is recording.
The idea of today, where did we got it?
Well, Office 365 distilled Marin and I used to do this every year. So we used to disappear off, take some time, come up with a number of subjects and then just do quick short podcast recordings of a number of subjects.
Yeah. But the little series we are doing today is actually based on something we saw in San Francisco and Seattle.
Yeah. Yeah. So we've been doing a lot of travel lately. the whole Microsoft world is being a lot of travel lately. and we did some presentations in Miami, separately. that was cool. And then we went to MVP Summit in Seattle and took the opportunity because you had a friend.
Yes.
To go and see two campuses. We saw both the Gmail, the G, Google G Boys campus, in San Francisco and we then also went on to Microsoft of course to see the Microsoft campus, Seattle. And while we were in Google, Google, which was very cool.
It was, it was a completely different atmosphere than the Microsoft campus. But it was so great to see both of them.
It was good to compare them, wasn't it?
Yeah.
So you have an old school friend.
I do.
And he was into software development, computing hardware.
Anyway, most of it he was in networking. So he started in data centres.
He built data centres. That's right. He built the Google data centres in Ireland and such like. And now he's in San Francisco doing security and looking at processes and stuff. And you reached out and said hey, we would like to have a tour of your Google offices.
Yeah. And he said normally they don't do it, but if you know somebody, they will give you a door and let me know when you are able to come and I will get some Time off.
Yes. That is cool. I have to say, recording podcasts is one of those things that you can do in a very professional way. Or you can pickle your toes while you're talking.
Sorry, my toe was itchy.
So, yes, we are on that road. Oh, we are, we are, we are. So, was it Joachim? Was that his name?
No, Joachim.
Close. Joachim, yes. So you guys hadn't seen each other for.
14, years or something.
Wow. So cool. Yeah, so they did a bit of catching up. I sat and watched the sunshine in San Francisco and the cars and stuff like that. No, no, no, it was pretty cool. So, but let's talk about that for a little bit. So we, we saw a lot of the new buildings in, Google. What impressed you most about that sort of two hour tour?
I think everything they do for mental health and making sure their employees are feeling good at work is something, was something impressive. But also the little old box with the, data centre in it. Data centre in it, yeah.
Not many people know this, but when the two guys that created Google got together, they couldn't get the computers they needed to do what they needed. So they used to take old laptop, old computers and rip them apart and modify them to their own standards. so just like Apple did, building the first computers in the garage, they actually set their first data centres up, which is, and you're right, there was a great cargo truck in the middle of a marked Google Data centre. And it already looked like it was live, but it obviously wasn't. But yes, all these motherboards just slid into a, frame all connected together. That's how they put their computing power. Apparently it's a bit different now.
Yes, it is.
Anyway, to move on because this is supposed to be quite short. So while we were talking about it and he was explaining around some of the philosophies around Google, he came up with three words and he had to look one up because he couldn't remember which one it was. But they were security, scalability and liability.
Yeah.
And they're guidelines that they use at Google in terms of, you know, we shall do no evil and all that kind of stuff, but basically to guide their path, their development. And I kind of quite liked this. so we made a note of it and we've been sitting there chewing over and stuff and so we thought we'd just take app development at our stage. So creating power apps, creating apps and working out how best to do them and just do a very, very quick look, an app. But Considering those three words, security, scalability and liability.
Yes. So we did a little bit breakdown and try to think about how they are working to each other and how we can change it to, to do things.
Yes. I was just trying to put some light on the situation. cool. So let's start off with security. We obviously, whenever we're creating anything, Whether it's a SharePoint site, whether it's a form, whether it's a, ah, power app or an application, security is key always. But it's not just simply who can run it and who can't run it. There's a lot of things to think about when it comes to security.
Yes. one of the things that is maybe more important of who can run it and who can't run it is how to protect your data.
Yeah, it's important that you think about the data. We're going to talk about that when we get to the end here on the liability section because that's key. But you know, you need to do a risk assessment of what content you're going to be including in this application. It needs to be suitably protected. and you need to work out whether there's any compliance rules associated with it because if people are filling out this, you're taking some kind of data, some of it might be ppi.
Yeah. Some of them can be protected or you cannot even ask in Belgium with gdpr. And also, if you are thinking about data protection, roles and permissions is another one that we need to think of. We need to be aware of who is able to ask for the data and who is able to see for the data.
Yeah. For the compliance there will be some legal requirements about who and can and what they can do and what.
Yeah.
But also it means in terms of roles and responsibilities, whoever's using the application is also a requirement for that compliance as well. Which I think that's where he was coming from and I didn't understand it first time around.
And also if you think about the security is what is needed, what is the minimum of data that we need to have to run an app or to run the code we want to run.
No, that's true. If you was building an app that tells you what the weather was going to be like, then doesn't really matter. You don't even need a login or an ID or an identity. But if you're putting an app together, for example. Well, being we talked about how much Google look after their people.
Yep.
And I, I mean I've heard about These massage rooms in Google and one or two other places, never seen them before, but there they were. and, you can book yourself a massage if you're feeling stressed. But, of course, depending on that kind of data, then you need to set up the security model to start off with and then you have to develop against that model, of course.
Yeah. And one other thing you need to know before you start developing is if you are an organisation, multiple, in multiple countries, is it needed in every country? Is it just for Belgium or is it just for America or anything like that?
Yeah. So basically deciding, you know, where the app and the scope of the app is in terms of location and what kind of compliance you're going to hit, also you know, what kind of risks you have as an organisation. And, then the same, we're not going to get into it now, of course, but touch on a little bit liability, I suppose. but yes, what that is going to happen to that data and when it can be deleted and what it's needed. And that'll be all part of the early documentation, of course.
Yep.
That's okay. All right. And then the next one we talked about was scalability.
So with scalability we are willing to know what will be the end scale of it, how big is it going to grow or, how many people are going to use it and how do you keep track on all of it?
Yeah, I think this is something that many people underestimate, because they don't think through the life cycle of the app. Everything has a life cycle, content has life cycle, team sites have life cycle, forms of life cycle and apps have life cycle. You know, what is the strategy and it may change, of course. You know, it could well be that after two years this app is so freaking popular you've just got to rebuild it from scratch because you don't see everything. But generally you will. To better define security. For example, you would obviously need to know how big this is going to get and where this data is going to be stored.
and a good question to think about, is it for one specific team in my organisation or for the entire organisation? This will already say with your. How big it's going to be in your N scale to give you some ideas.
Yeah, exactly. So, is this something that is likely to just be attached to one list, one table, or is it going to be multiple tables? This will often give you some idea of where the scale is going to be.
Yes. And if you want to scale it like that, you need to be able to monitor it as well. Because if you don't monitor it, it will go completely loose and run out of, Control.
Yeah. So basically the way that I do approach this kind of stuff with anything, of course, is you go, okay, look, I've got to build this. This is the need that's defined by the end users or the requirement or the uses of this application. This is the number of people they need today. This is how they think they will grow. This is the number of times they'll put data in, and this is the number of times they'll get data out. And then you can sit there and work out what point you need to go to the next level. So you need to go to add additional databases or you need to add additional resources to it. So you measure it to the point where you're using those resources and then you add in the additional resources you need. Because that's also how you pay for this thing.
Yeah, true. So, and then it's something we need to think of and people need to be aware of. But the other thing is you need to maintenance as well. The app, you need to make sure it's keep on running even when you are growing. It has all of the licencing if you need to have premium connectors or something like that. So you need to be aware of it.
Agreed. And they'll start to sort of get to the point where, it becomes unusable because you miscalculated something or because it just got popular. When's the worst time for an application? The most unpredictable time? Is it a long way down the line or is it when it first gets launched? When you start to understand how many people need to use.
Can be both. So if you start building an app just for one team and then, you notice when launching that maybe 60, 70 people start to use it because.
You'Ve created something that is a piece of magic that you hadn't worked out at the time. I know what I mean.
But it can also be that you create an app for your entire company and you know that they will start using it and then just at one moment in time, everybody will maybe use it at the same time. Can also be a pain in the ass.
Yeah. So there's an equal risk that you can misjudge by not putting enough resources into it. So people suddenly start using it and you have to very quickly get in. Also the other way around, you think, hey, this is going to be dead popular. And three people use it, not 600. So either way around, measurement and understanding what's happening at any given time in that application is equally important.
Yes.
And the thing about scale, of course, especially as you move on to liability, you can think about the costs of these things is the total cost of ownership.
True.
So you sit there and go, hey, I need this application to monitor furniture positions in our offices while we're here for the next three years. So you've got a three year application, you know that it's going to do this and do that the other. You can sit there and say, hey, people are only going in the office for two days a week. So therefore, you know, they'd basically be, everybody will go to the app three times a week, probably to change a desk or book a table or whatever they want to do with it. And it will cost us this amount of money. And then the organisation says, hey, no, everyone's got to be in five days a week because of X and Y and Z doesn't matter. Completely irrelevant to the app. And all of a sudden you end up tripling the number of inputs and outputs on your application and they have no idea, even think about the fact that they've just blown your application up.
True.
And at that point you've got to work out whether it's still cost efficient to do it. It was okay. It's nice little power app that's deciding what desk you want to be on. but as the company grows, you think this is just not going to cope with it. I never really thought I'd end up with 700 seats being booked today. You know, it was only designed for X. Y.
True.
And then you suddenly got to get something in quick because the real problem then is understanding what the owner's vision was for this application. So the ownership somebody will own the application or a team will own the application. And if they don't understand the growth path, then there's a liability around who's liable for the cost? I guess the owner.
Yeah. not sure. It's always a team or a person that owns it. It can also be owned by a company. That company is taking the ownership of the app, by getting the C level involved and saying, all right, you can do this and this and this, and this is the budget or resources you get for it.
Yeah, I kind of agree with that. Except it's always better to have one person to deal with rather than a company to deal with at least two persons for ownership. Yeah. So if one is not there anymore, then there's somebody else can back them up. How many times have you developed an application and not really had a clear direction because different people are giving you different directions.
not that often it's in development. Not that often it's more in that side of defining the scope and all of that. That's where you most of the time have those issues with people giving you the other directions and talking about it. So that's the first thing.
But that's not normally a problem, is it? Because it doesn't matter that you get bad ideas or lots of ideas at the scoping stage. Once you've defined the requirement, the initial launch requirement, then you can move forward. So ownership at that point I think needs to be one person or two people that you can meet with, regularly. It can't be a company. The company may be liable. Because we're talking about liability here, aren't we? We're talking about the decisions make and who stands up if they're bad decisions, the liability. Also the company's liability around data and HIPAA or GSBN regulations. So this liability thing is a biggish kind of subject. but in terms of the process for the development direction, owner, user requirement, I think it's got to be a small management team or.
Yeah, you need to have a small team doing this. You need to have an owner, you need to have somebody responsible for the end users in there that is able to say this is what works for the users and whatnot. And of course the. I can't read your notes, I don't.
Know where you're looking at. Oh, right. Requirement, requirement. All the required. That's okay, post its are on the wall folks. So we're trying to work through our.
Posters and the owner and the user are responsible for the end users. They are also responsible for the requirements. They will keep track on it, that the app is doing exactly what it needs to be of, what is defined.
Well, in the next podcast, in the next Fusion short, we're going to start looking at these same things, security, scalability and liability from the user perspective at a business level.
Yes.
And of course at that point you will have to work out what their expectations are for the first release of the application and what direction and how it's going to progress. And the internal management of this process, of course, is that C level. If they are involved in it, because it's that high priority. The internal reporting is nothing to do with us in it. We have to keep it up and running, potentially make sure it's available. But the team that owns the application or the owner of the Application is the one that does the final decision making, because the team on the app is huge, actually. You've got. If it's. If the company is dependent on the app, C level is going to be involved, if the owner of it that's actually responsible for paying the developer's bill and the title, potentially. and they would then liaise with all of the user representation and they will manage all of the backlog and all that kind of stuff. So it's the structure around the ownership that's important, I think.
True.
And making sure that from a development perspective, you understand what their role is in this. And again, I think we'll cover that next time as well. All right, let me try and decipher my notes on here.
Yeah.
So, we're talking about the liability. There's, again, there's two sides of this. There's the people liability, and we'll continue with that conversation. Then we'll touch on maybe some legal liabilities afterwards. So who's going to be accountable? All right. For data management within the application? I mean, the front person, again, is the owner, isn't it?
I think so.
And then the owner will probably have to talk to the data officer or.
Yes. And the security guys and all of that.
Yeah. Too. Because the accountability around that is important. Liability is, hey, you know, this thing could go wrong and have this effect on the business. Accountability is making sure that we're compliant, that it's meeting the business need, that the cost effectiveness is right. And that also ties down probably to the final thing to think about here, which is the timeline for this, the life cycle for this. You came up with a great term for it this morning, didn't you?
Biz app Lifecycle.
Biz App Lifecycle.
Business application life cycle.
Nice. We'll dig into that a little bit later on, I think. But yeah, so the life cycle of the application we build is something that needs to be up to date and.
Defined and written, down somewhere.
yeah, written down somewhere like that. Like it is every time.
Yeah. Most of the time it's not. And then it's the time that discussions are starting.
Yep, I agree entirely. But I think, just as a final closing thought on this, really, we're talking about a fair amount of structure that is required to build the app and those key things, security, scalability, liability, that drives the success of this kind of stuff also realises your legal requirements and, you know, even some of your ethical requirements about the application and what it's doing.
Yes.
And that structure is important, but you also need Flexibility.
Yeah. And before we went to Google, I never thought really in those three words and that structure in it.
Yeah. So. Yeah, because they do this shit all the time, don't they?
Yeah, it made me think about it and it's actually a great structure to start working with.
Yeah, I think so. And I think if we. So, but, but just to finish my point off, I think that within that structure, which provides a kind of nice way of, of grounding out all of the dependencies and aspects, the flexibility is there because the thing about an application is that, it needs to stay current and delivering and everything else. But we always have legacy apps. Somebody at some point developed an app 22 years ago and everybody's been using it ever since, and all of a sudden it won't run on any of your new database systems and it won't run here and you end up having to make special. So part of this structure, part of that liability is making sure that it can still be maintained and managed over a period of time that you can't really assess to. Because if this is supporting a business process that never changes, the application will always be needed.
Yes. And also, you can't predict on how long this application will stay alive.
No, I agree entirely. And it's. So you also then need to think within your scalability that the underlying technologies will change.
Yes.
And you need to build that into your timeline and into your. What do you call it, your business app life cycle that says, hey, you know, it needs now to be migrated to this database.
And that's also why we said that scalability maintenance is important, but it's coming back in liability as well. You need to be aware of the maintenance you need to do on your app.
Agreed, agreed. And a lot of this stuff I've just talked about talks about total cost of ownership. So it's all right running it on a database today, but if I have to maintain that database past its efficiency, because I'm not going to move it to another database, then I've done a poor job in terms of managing the scalability and the lifecycle.
Yep.
Like when we were at Google and we looked at the data centre, which is right in the middle of the campus, right in the middle of the beautiful San Francisco sunshine in a cargo truck with a glass window so you can see inside it. It's a piece of history that they constantly get to see. And the fact that that was not scalable, they had to change the way they build their data centres like everybody else. Of course.
Yeah, I think That's a reminder for them that how they have been growing and changing. And that's also a reminder for other people that everything you do in IT will change at some point in time. Every underlining hardware, software, everything you use changes.
Yep. And if you're building an application and you think, hey, this will last three years and it lasts 10, then you've got to think differently for the last seven. At some point you need to think about upgrading, you need to think about capability, you need to think about numbers, and that's cool. So security, scalability and liability. If you think about those three things on an app, then I think at least you've got yourself a good plan in place for short to medium term sort of period, of time for that biz app life cycle.
Yes.
So what we want to do then is to say, well, this is from an IT perspective.
Yeah, but what for the end users.
Yeah. Because they have got no idea about data protection, they've got no idea about scale monitoring and measurement and the cost of ownership. They just want an app.
Yes.
So let's go and talk to the end users. Tell you what, let's do that in the next podcast.
Great idea. So I'm going to say bye.
I was just going to go and turn it off.
We never close a podcast without saying bye.
No, it's because we doing all these shorts. So consequently we're doing one straight after the other. So you're right, I apologise.
So, yes, bye from me and bye.
From me and, we'll catch you in the next one.