Models Dressed

Anouk: Welcome to Fusion talk with Anouk and Steve. I love models. I like the way that they walk up and down the catwalk sometimes. They've not got many clothes on. But I really like the fashion. I've always wanted to go to a fashion show. Have you ever been to a fashion show? It doesn't really matter anyway because I'm talking about what I feel like at the fashion show. Sorry. Couldn't resist.

Steve: So it's the men who didn't knew how big fashion shows were until we saw something true.

Anouk: Isn't it In London.

Steve: The Vogue experience.

Anouk: Yes. That was pretty cool actually. The Lightroom.

Steve: Yeah.

Anouk: Yeah. We get some UK people. If you've not been down to London to the Lightroom, it is well worth going.

Steve: It is.

Anouk: Have we done one or two of those now?

Steve: Two.

Anouk: Yes. We did the artist Hockney. Thank you. Because I'd forgot. Yeah. That was really good.

Anouk: And then we did the Vogue one. That is true.

Steve: Yes. I wanted to see the vocal.

Anouk: That was. You're absolutely right. I had no idea how much. How many millions they invested in a crazy. Yeah.

Steve: So it's on my list. Once I want to go to a fashion show in real life, I want to see it real.

Anouk: Is that true?

Steve: Yes.

Anouk: It's not Fashion Week in New York when we're on the way there and to Vegas. No. I'm sure would have noticed. I think it is October now. I think we might just be missing it. Fashion Week New York.

Steve: I will check that out. Yeah.

Anouk: It's not going to be on. I'm sure. I'm sure it's

Steve: And probably it won't get. It won't be easy to get tickets for it.

Anouk: Virtually impossible. So anyway. Yes. So I like models.

Steve: Yeah. Only that kind of models. No.

Anouk: I like all the kind of models as too. So we finished off the last episode. So we're basically working through the presentation we did where we identified 10 get started tips and tricks.

Steve: Yeah. For Power Platform.

Anouk: Which we did at Bletchley for the first time.

Steve: Yes.

Anouk: Which we will do again.

Steve: Tunisia.

Anouk: Really? Yes. We're only doing the workshop in Austin. In Oslo.

Steve: Yes.

Anouk: Which I might not be there for, but we'll worry about that one later.

Steve: Well, if you are not there, it's covered. Somebody else will fall in for you now.

Anouk: Moraine will cover it. I'm sure he's already said he would if need be. Yes. The fact that I don't do timelines. So I double booked myself again. Yeah. But it was my mother that got done Last time, not you. Yes. Anyway, so if you are going to Oslo to to see the baseline SharePoint, and PowerApps, it is a great workshop.

Steve: Yeah, it's fun doing.

Anouk: It is. And basically we're seeing more and more people. You start talking about document libraries and content types and everything else and people go, what? I just want to learn how to build a workflow.

Steve: True.

Anouk: it's not easy unless you get it right. So we decided to kind of just do a level 100 get started, no, nothing kind of thing kind of workshop.

Steve: Yes. It's similar with the training that I'm giving that I done on Monday and I will do tomorrow. It's also about all of those basic. So by the end of tomorrow they are maybe have built a first workflow. It depends on what they have still remember of Monday. But yes, that's what I'm doing for training.

Anouk: So that's what we did and we decided we'd deep dive down into a number of things and what we're going to do more on the business side because there are five tips for the technologists and there were five tips or areas for the business. And today we're going to do more on the business side because last time we did environments. Environments. All right. Which is obviously more technical constraint and a way of governing them. So that's fine. And next time we're going to do.

Steve: No idea, no idea.

Anouk: full of surprises. We might decide before we get to the end.

Steve: But for the environment, if people would like to know more about it, I'm writing a blog about it.

Anouk: You're writing a blog about it?

Steve: Yes. Also how you set up environments a little bit more technical about how you create and all of this. So yes.

Anouk: So what we're going to talk about today is really, strategic models around adoption of Power Applications and Power Automate, and around how you manage within the business to roll them out, but in a way that is still innovative, still not restrictive and that kind of stuff. Okay.

Steve: Yes.

Anouk: So that's basically what we're looking at. And effectively what I wanted to do was to create a model that you could start at A, move to B and go to C. And so you didn't kind of have to do a lot of relearning as you move from one station. there is a natural process and each one has its own governance that is fairly simple and easy to do. So that sounds like a perfect model.

Steve: I think it is. And if we keep it basic and people can start at one level, it will make it more, Will make more sense and easier for them to understand what we are trying to say.

Anouk: Yeah, yeah, that's fine. So that's a size four. And then we go on to a size six with tall heels. And then we go on to a size Wrong model again. I keep getting distracted just the thought of it.

Steve: Your ideas are far away from, from technology.

Anouk: All right, so let's start on the bottom level then. So the bottom level is often called shadow it.

Steve: Yes. And every company has shadow it.

Anouk: Oh, different levels, technical debt. Shadow, costs us, Costs it a lot of money.

Steve: True.

Anouk: but it's also where innovation happens. So it's, it's like, you know, hey, look, I can have a shared mailbox. And, ooh, that shared mailbox. I've got categories in that shared mailbox. If I use the categories, I could build a ticketing system out of it. And so you get some super smart user that takes a standard kind of applic application like a shared mailbox, and then they suddenly start building processes on and using some features to create a manual way of managing tickets in and out of this shared mailbox. And then all of a sudden the mailbox gets upgraded, and then the categories don't work the same way anymore. And they're suddenly on top of it saying, this doesn't work. And we used to do this and this and this and this. And you, know that's shadow it, which is not necessarily a bad thing because, hey, somebody's just saved the company the cost of a ticketing system.

Steve: Yeah, true. And that shadow it is acceptable because if your company is focusing on Microsoft M365, it probably stays in that area. It's not that you are going to combine it with different kind of tools.

Anouk: No, I agree, I agree. And Power Automate is in a similar stage. You're going to end up with some users that go, oh, I've heard of Power Automate. Let me go and do some Googling here.

Steve: And they will start building small things and start using it, for their own use or maybe their team use. But most of the time it starts for their own use because they don't want to do the tasks manually anymore. If they have repeating tasks, they have.

Anouk: An idea it's not always a task. It could be a repeating task, but it could just be that there's something they're trying to deal with. So, I had one recently, at Linnaeus, it's about a year ago now. And we've done nothing about it. We just let the guy carry on with it. It's not. We stopped him. and they have a pool car and somebody takes the keys for the pool car and then next person can't find the keys because they've not been put back where they came from and they have no idea who took them before. So now what they do is they have a little power automate, a list. basically when somebody takes the keys, their name goes in, they're given the key, and the automation just reminds them to bring it back where it needs to be brought back to. After a certain amount of time, it says you need, you know, and, basically it's just emailing them and letting them know that they need to bring the keys back.

Steve: Yep. It's more use of it because otherwise, people need to track it on a list and keeps looking at the list, who has it done last time and I need to mail them. This is just doing it automatically.

Anouk: Yeah. So, Jan, if you're listening, well done, mate. That was very smart. He's now got seven power automates, though, and he's now actually taking data from our systems onto a spreadsheet and then he's using that spreadsheet to actually do other kinds of workflows to let people know what their orders are or to remind people where they're at. So he's turning himself up into this little fiefdom of data, and we need to think about what to do with it because at some point he's going to leave the company. So then there's nobody to look after it. It suddenly get asked, oh, yeah, the workflow for the key car keys don't work anymore. It goes, what workflow for the car system? So, so, so that is shadow it. But at the end of the day, it's innovative, all right? It's saving some time or it's fixing something and by leaving them alone, by leaving them alone. If it suddenly stops being used, chances are they doesn't work or it didn't do what they wanted it to do. So you can try and just ignore it.

Steve: True. I had a conversation today with a customer and somebody created something that they use on a regular basis to make sure that people working for them are evaluated very well. Because it's a construct, it's a building constructor and they have subcontractors. The person that created it left the company, of course. So it was connected the app, it.

Anouk: Was connected to his account and his.

Steve: Email, personal account and email, and also stored the information in An Excel file on that person's OneDrive.

Anouk: Okay. And they left. And then they took the licence away and somebody said no, they were smart.

Steve: Enough to not do that.

Anouk: Okay.

Steve: But they came, to me with the question, how can we change the owner? So we are checking what we can do to change the owner to make sure that there is a general account owner now. But of course, because it's with a personal account, they need to make sure that there is somebody having access to that personal account to first share it, then do the re ownership.

Anouk: Yeah, of course, I understand that. And that's really when we take it to the next level, which is great. So describing our level A, everything tends to get done in the default environment without changing it. We'll come to that. Well, we talked about it last time.

Steve: We talked about it last time.

Anouk: In my world, we just leave it default. Everybody tends to work in there. and then they will build what they're doing. Now there's no reason for it to be ignorant of this because you have access to that default environment. Somebody administrator is going to know what's happening in there. So we should know when there's workflows in there and we know how often they're being used and how big they are. So there's a number of triggers for this. but of course, at level A, they're owned by the person that created them.

Steve: do you now know that? Easier to know what is all in the different default environment? No, Microsoft has changed that. So it's easier to see what is created in the default environment. And everybody is able to see it that has access to that environment.

Anouk: Everybody has.

Steve: Yes.

Anouk: Yeah, no, I think everybody had access to it before, but they didn't get to see stuff from an admin perspective.

Steve: Access. But they didn't see what John created or what Tom created. But now they can see what everybody has created.

Anouk: Yeah, that would make sense because they weren't the owner of it, they were just, a user of it. Yeah. Oh, well. Well, that's because Microsoft really want people to move away from this stuff to be fair.

Steve: True.

Anouk: And that's why we have a layer two. So layer two, really, you got to work out what the triggers are. So you've got a workflow that's being run by one person. It's in their inbox, in their OneDrive or whatever else they're doing. and they want to be able to, as you say, like your user. Now, I don't really want this on this email because this user's left or anything else. And you don't have to wait until that happens. Of course, you can move it and uplift it, move it to a different environment, but you just need to work out what the trigger is going to be. So you could monitor this. And this is now being used 50 times a week. And you go, just a minute, whoa. If this is collecting data on 50 runs of a workflow, that's my trigger to say I need to share this or centralise it a bit more. but of course, you also have to understand that it can't just take on every workflow that somebody else builds because it gets more and more expensive to run. So in this case, it is still not responsible for it. I think the original builder or the team, that the team manager is still responsible for it, but you give it a more generic account or a shared email box account or some way of. You can't really do it on shared email boxes. But, you give it an account that they've got access to, but you still let them responsible for it. And so you create a new environment, move the workflow into that environment, put different kinds of permissions on that environment and just let them carry on doing it as if nothing had happened.

Steve: Is it a new environment or can it still be in the default environment?

Anouk: it would change. No, it can't be in the default environment. You can move it to a different user, but all you're doing then is moving it sideways. You want to. I mean, if it's important enough for somebody to want to move it, then then really you want to say, okay, look, let's upgrade you to level two. And level two really is your own environment in case it really grows and you want to expand it and you want Dataverse and you want other options and opportunities, different connectors, that kind of stuff.

Steve: That's also what's happening when you allow it to have automation in teams. Then there is an environment created especially.

Anouk: For that one, that might be your answer. You create a team and you put the workflow in the team and then everybody can sit there and play with it and share the incoming and outgoing emails and stuff like that. So that might well be another way of doing it, but it's at level two. It's not, managed on a single person's, inbox. and, you can give, give it certain size capacity. You can run it so it doesn't go out of whack. You can even limit the number of times it can run. You know, there's a lot of things that you can do with it versioning and all those things. You can do that without taking accountability and ownership for the workflow. That can still stay with the business.

Steve: So level one and level two is ownerships of the persons or the teams itself.

Anouk: Correct.

Steve: And it knows about it doesn't do really support on it.

Anouk: No, just checks in now.

Steve: Checks in now and again and do some monitor it. Monitoring on it to see if needs to grow to level three or level four maybe.

Anouk: But I think at that point you're. So the first level. It's, you know, we don't really care. All right. All Right. Your default environment might start to get full and busy. If you end up with 10 people creating these things, then you, you know, you need to kind of sit and be careful. But effectively you're just monitoring and letting people get on with what. This is the innovation. Yeah. It's like the playground. I think we had a slide of a playground. You've got a kids playground and kids can go in there and do what they want in a safe way. You've got rubber mats on the floor. There's nothing sticking out, cutting them. It's, you know, they can basically turn into a castle. I can be Tarzan and Jane. I can be, you know, whatever, you want. Whatever you want to do. Yeah. and and then that's exactly what that environment is for you. Then move it upwards because you want to share it amongst a number of people or let the manager also see what's happening in the workflow. There could be lots of reasons for doing it. but it's there and it is now aware. So you may list this as being somebody in the help desk is now aware of it, so that if they get a ticket for it, they can at least say, okay, so that's what it is and there's not a bunch of investigation.

Steve: Yeah. And it will go to level three when, your manager or some management teams is getting involved in that flow and use it on a weekly or monthly basis.

Anouk: I think moving it to level three is where it takes on responsibility for it and ownership and it's usually because of how many times it's been run, how much data it's storing. they keep asking questions on how they can improve it. So this is now meeting a real business need.

Steve: Yes.

Anouk: It may want to connect to some data or you've, you're finding there's data in there that really should be in your business systems. they, you want to connect it to messenger or to teams or you want to Connect it to any number of different things. You want to run it on a mobile, they want a form, there's any of those key things that are taking it to a higher level. then you would move it to. You would joyfully accept it as a corporate application or a corporate workflow for.

Steve: The part of the corporate organisation. Because it can also be that it's a workflow that runs for the management team only for them to make sure that they follow up on numbers and all of that. It's critical enough for your organisation, but it doesn't need to be available for any. Everyone in your, organisation.

Anouk: It doesn't need to be critical. I don't think it needs to be critical, it just needs to have purpose.

Steve: Yeah.

Anouk: So I mean, it would never be how to manage a key in a car. If somebody said we need a solution for managing the keys in the car, that wouldn't mean that I certainly take on this application. It means that I copy it to new environment and I say, hey, okay, you're still responsible for this. And because you no idea whether that will want to go in the same direction. If they suddenly wanted to add a second pool car, second key, then you might need another column in there that says key number one, key number two. but that wouldn't give you, you know, they may never have two keys next door. And not only that, they just want to look after it themselves. It's their pool car. It's something else. Now if you suddenly made a decision that all the pool cars are going to be managed by facilities, then all of a sudden you might go, okay, all right, so we need to manage the keys and the booking of the car and so that, that grows and then maybe it starts to become critical. But no, I mean, I think I could put 200 users on a level two workflow, quite happily and not care. I don't think I would worry about it. If I've got 200 users and they're each running it 200 times a day.

Steve: Then you will care then?

Anouk: I care because it's level. So I think there's a number of criteria that moves things across. So moving from one to two is really about more than one person having responsibility for it. Probably a manager saying, john's got this workflow, John's getting fed up with the emails. I still want the workflow to run. Can we do something about it? And then. And you then say, yes, I can, but you still own it. But we'll put it into a safer environment. Going to level three, really Requires a whole different thing because when you're at level three, you're falling into audit NIST two, qualifications, data management, gdpr.

Steve: There are a lot of more things you need to manage and you need to track and keep an eye on it. And it's better that it does it, because normal, users that building those kind of things probably don't know everything that needs to be managed in an organisation. So.

Anouk: I agree. And IT are not taking over it, they're basically managing it technically, and making sure that it's up and running all the time and data is backed up and supported. and then the business is still the product owner. So if they want something adding to it, you might even still let them do it themselves if they're competent. but you then might put it through Test and Act and all that kind of stuff, your choice, depending on where you're going to go. But of course, if there are some changes to it, you need to think about training because now it's probably got a larger audience and the help destiny is to kick in.

Steve: Yes, indeed. And also I think for level three, it's a good idea to put it through Test and Act and all of that, just to make sure, because it's been used in your organisation maybe on a daily basis, you don't want to change something and break it.

Anouk: No, exactly. I mean, you need them to understand that this is at a different level. So it's really just about good communication and understanding of what entailed. And what's really neat is that you started off with something small that was there to fix a purpose and you've let them get on with it and they've eventually said, look, this is useful, but for goodness sake, I fix this. This is my job, I build this. I don't really now have the time to manage this. And you take it to number two, so that can be shared. Level two. And then of course, when it gets to the point where you need to scale up, you take it to level three and then you scale up accordingly. And you just need to understand the model is quite easy to build.

Steve: It is. We have a level four.

Anouk: And what's level four?

Steve: If it is an application or workflow, that is for your entire organisation, so organisational wide being used.

Anouk: But I don't think it's level four. I can't remember putting that on the slide. In my mind I've only got three levels because level three is really. I had level four, did I? Doesn't matter. I don't disbelieve you. But I guess you're right, it might be if you're doing it, we said.

Steve: Indeed. Level four is being managed and built by it. And it's being Or not maybe not built by it, but managed entirely by it. And it's are all of the processes that are for your entire organisation.

Anouk: And what is level three then?

Steve: Level three is, not for the entire organisation, but was for parts of.

Anouk: Your organisation but it still run it.

Steve: Yeah, it is.

Anouk: So there's no difference then for it from three or four? You still do. I can test and manage it, but even in enterprise it's just scaled higher.

Steve: Yes.

Anouk: I don't know whether there's a bit difference here. I could put four. I was fantasising about the slide. But, the bottom line is the IT take responsibility for it. with the business obviously directing the product and where it goes. And yes, you should be able to scale it up. I mean, let's be honest, if it gets to full enterprise wide, you probably wouldn't want it sitting in Power Automate anymore anyway.

Steve: Depends on what you want to do.

Anouk: Depends on the workflow it is. I mean if, if it's the key thing and you've now got 25,000 cars hanging in there, you don't really want to have a list. 25, 000 cars. So you'd have a different kind of.

Steve: The big question with level four is do you want your business users to be able to make changes to it or is everything done by.

Anouk: I wouldn't do that at level three either. Level three, they can't make changes. Level three is it takes on responsibility for it and there's a change process and a change request process has to be a normal thing.

Steve: Yep.

Anouk: So because you'd have that at level three or level four, so it doesn't really matter. It gets to enterprise level at level three. and so then all the standard features kick in. So we've gone from a little application that nobody was it and not providing, so they've built it themselves. Level two is. It's getting popular and it's now difficult to manage for one person that's building bicycles on the production line, and do this as a hobby on a Saturday morning. So level two is where it kind of skewed it up and share it out and put it into a shared environment. And level three, Stroke four is where it take it on as full responsibility. Now what you have to ask is why did it not, take it on a level A. All right, because, hey, look, if there was a need for it, it should have stepped in and delivered. But at the bottom line, it's going to take three or four years to go from level one to level three or four.

Steve: Yeah. And it doesn't need to take it on, because it's the innovation part of it.

Anouk: That's exactly right. I mean it's the startup that says, hey, we need this application built in.

Steve: And away they go. and the business knows better what the way they are working and what they want to have and let them find a solution that works for them. And if it needs to grow, it will grow. Yeah. And then it can step in and take over. But at the beginning, no, let them.

Anouk: Maybe there is a level four and maybe level four is where it go. Okay, look, this started off as a power app, but I can buy a proper fleet management application now and that would be better for me to take that on board than actually keep running this, this power app. So it could well be that it you then say, look, now we know we've got 10,000 people using this or even 200 people using this. It's actually better to buy this SARS solution or that solution. So yeah, maybe that's the way that you four kicks in, where you actually turn it in. You deliver the service with the professional application or a SARS application that's managed and supported by somebody else. Yeah, it's very cool. So that was our model.

Steve: Our model.

Anouk: Three layers or four layers depending on how you want to play with it. defines innovation, allows it to go within the organisation and meets a need in the early days.

Steve: I have a big question for you.

Anouk: I was about to be very rude then, but I held myself back.

Steve: Yes. last week in Zagreb we talked about the system of systems.

Anouk: Yes.

Steve: Can we build in that model, in the system of systems? We did a podcast earlier about the system of systems. I just need to check which one it is. But.

Anouk: So the, the thing about a system of systems is that so no, it's not a system of system. Why it stays as a single entity. Let's assume that you have ah, a fleet management system. Okay. And that system already works booking the car, ordering the car, processing the car and everything else. And you have this little workflow which is just managing the keys of the car. Okay. So you already have one systems and you have a different system system for managing the key system to manage the car. It could well be that those, that key process gets built into the car fleet management and then you end up with A system of systems. So you end up with those things. The other thing that you might see, system of systems is where you have one big workflow that's running different workflows and that's a system of systems. So you've got one system controlling other systems.

Steve: Yes, but we talked about the system of systems with integrating power automates in SharePoint which is perfectly working. But do we keep track on the model we built? We just described the model. Do we need to keep track on it? If we talking about the integration of power? Of course.

Anouk: I mean there's a dependency between these systems, inherited within the system of systems. So effectively that dependency has to become part of your risk and change control process as it starts to get to that level, as it's level three, that dependency will be part of your risk. So you write down a risk that says hey, we've now got a risk that if I buy a new car with a new set of keys, I also need to make sure those keys are built into the system that manages the use of the keys and the tools for putting them out. So there's a dependency between the two. I can't have a key on my system unless it's got a car in the fleet because they've now got a link together. So yes, there'll be dependency and a risk that that dependency could get in the way.

Steve: The reason I asked for was to come actually to the next thing is if people start working through that model and we said by test and ack and all of that, yes, they need to make sure that the other systems they connecting to have also a test environment or test place that they don't work on the production data.

Anouk: Yeah, part of the risk and the dependency assessment. So no, of course you need to. There's a bunch of IT processes. Do we really want to go into IT process?

Steve: No, no, no, no, no, no.

Anouk: But, but you. It never ever. Now let's just slower. never runs in isolation. Even if it's got its own set of users and it's on its own hardware and it's running its own software, there'll be a business process somewhere that is kicking into that that's dependent upon it. So even though the systems might not be exchanging workflows or information, there will always be a relationship. It's only when those systems merge, for example, that that actually changes. So yeah, but you are right, you need to be able to make sure that that's, that's what a change control process is as well, you know, hey, I need way this key is ordered and played with on the workflow.

Steve: Yes.

Anouk: Then that. That work. The change process would say. Oh, but let's not forget this is linked into this and this process. So consider this.

Steve: But that's we, we describe the model now and we have it in our head. So we know this. But if you start working with this and you start working with this model, make sure you document as well that you'd never forget one of those dependencies or what anything else, because it's easily forgotten.

Anouk: Yeah, but that's where the fun is.

Steve: Yeah.

Anouk: Take one system down and then you sort of remember that this is connected afterwards. Yeah, but of course, I mean it's Wow, we are getting into an even bigger subject here.

Steve: We are not going to go there. So.

Anouk: So why don't you mention it then?

Steve: I just want to give people a heads up of what is coming.

Anouk: What is coming. Okay, did we have documentation then as one of our 10 spots?

Steve: Yes.

Anouk: Did we?

Steve: We did.

Anouk: And that's what we're doing next.

Steve: Maybe, maybe I don't want to go to documentation directly. I think it will be one of the last things to talk about. we had a lot of things in there to talk to that we did. Environments, was one. Policies was also one.

Anouk: But now you're back into documentation.

Steve: Yeah, documentation is everywhere.

Anouk: Well, your policy is defining how you set something up.

Steve: We are of people in IT don't like to write documentation or I don't like it.

Anouk: Well, but your documentation is easy because you're just saying, hey, this is what it does and this is how you do it. And this is where the data's stored. You're a process person. Your documentation is about processes. Yeah, but true documentation's got processes right at the bottom of the triangle. On top of that you'll have your technical standards and processes and purchasing within the organisation. On top of the that you'll probably have a supplier policy. And on top of that you'll have a policy policy. So they will all be linked together as part of a knowledge management tree. Let's not get into that. It's a good podcast subject. Knowledge management. True knowledge management M is a good subject. But not for today.

Steve: No, not. No, no, no, not for today. Not for our governance, tips.

Anouk: So would you like to bring any of this spurious random subject question into this process?

Steve: No.

Anouk: Sure.

Steve: Yes.

Anouk: Oh, it could be good. All right. So there you go. So these were supposed to be short and sweet and a bit of a deep dive further down into different aspects of the presentation.

Steve: Yes. And I think we did it well. I think we informed people about the process we are using.

Anouk: Are we building on recommend to our, users.

Steve: And we recommend to us. So I hope people learn from it.

Anouk: And so do I. And on that note, learn well, people.

Steve: Learn well. And listen more to our podcast.

Anouk: We'll speak to you next time. Ciao.

Steve: Bye.

Anouk: Sam.