The Better Business Analysis Institute. Presence, the Better Business Analysis podcast with Kingsman Walsh. Hi, everybody and welcome back to the Better Business. Analysis Podcast with Benjamin Walsh and. This week we are going to be talking about a technical area. Which a lot of Bas should understand and to be honest. I have had some conversations. Previous IT managers and CIOs who believe that this will form. Part of the BA role. In the. Future the topic. I want to talk about.
Today is what we what's. Referred to as Low code or No code applications now if you haven't heard. Of that term before. Then I'll give you just a quick. Intro so the idea. Is that these apps can be created through kind of a drag and drop interface with. Minimal coding as the idea. Will come back to that minimal coding ** You can drag and drop and create an interface and you can. Use these tools to.
Put in a bit of. Bit of logic, and we'll talk about what logic is in terms of the mechanics. Of how these tools work and then you can connect. That application to a database and that database. Can be very range from things. Like a Google sheet to. What's called an air? Table to a relational database. Usually free ones like MySQL or. This whole app could be. Living in within something called a container on a cloud service. Like AWS? Or Google Cloud or Oracle? Cloud or Azure?
So you might have heard of all these words. I'm. Specifically using words that you. May have heard of before, so what's the main purpose behind these low code? Apps is that? Those who are not developers can rapidly create applications to. Meet a requirement. It's usually. They're usually used for. 1. Kind of use case or one purpose. A good example might be a tablet application. So you're. Doing a bit of what's. Called Field Services, so you're
out and about. Talking to customers and maybe. You just want to sign some people up, for example. For your mobile phone provider. Or an Internet provider, you know. You always probably get door. Knockers around your house. Actually we had one earlier. Today. So they'll knock on your door and they might say, can we sign you up? And they'll. Ask for your first name, your last name. Your e-mail address and whether or not. They can send you some details
and. The type of application they could use to enter that information such that the information. Is accessible for the back. End functions so they can you know. Add you to a marketing list or ring you back. Via the call center that kind of app that. They're running on their on their tablet would be a great candidate. For what I would call a low code no code app. And So what does that mean? For the BA profession, as we know those who are in business. Analysis and those who are still.
You know, getting in there. Well, this might be. A fact about our. Profession that you need to know. Which is we're usually seen as a Jack. Of all trades where they're connected to it, however. People don't necessarily value or. Understand exactly. What we do and so if we're someone who's sitting down and getting requirements from. A group of stakeholders or. Elicitating them. Then there's sometimes there's an expectation from a. CIO. Or someone who's come. From a very technology.
Space that Bas can do some, you know, lower level technical PA work to. A point of implementing or configuring systems. Sometimes known as systems analysis. So because that's an expectation for some BA. 'S out there. I would suggest that being able to use low code apps and produce low code apps. Or at least. Advise on them could become part of your job. And for those Ba's. Who are more? Business focused who aren't technically focused more on the process. Side it's good to understand.
That the how these apps. Work how they're made and you know just in terms of what options there are out there these days. Because they could be possible solutions to problems. That you? Are uncovering. Also, and you, we've talked about AI before, but a lot of these low code, no code apps can. Interface with things like ChatGPT. Open AI as the actual platform and it can send. Information or retrieve information. So understanding that and seeing that. These AI tools are kind of being
plugged. In to these low code no code apps means that that's. You're going to see a big skyrocketing effect. Of more of these kind of low code no. Code apps. Happening in the market. Okay. Cool. Finally, I think another another point, when we talk about low code no code apps is they I've seen. Of late quite. A lot of. Use cases where. They are created not just for one use case to say. For example, what Door knocking? Knocking, you know, data
collection app. I've seen them used as extenders for systems. That are quite. Old school so SAP. For example, is a pretty old school system. It's not going to change. You know it's going to iterate, but it's not, its. Interface isn't going to change anytime soon. It's a large ERP type. System that's quite robust. The same in the the dynamics family, the same in the Oracle family and. Sometimes these low code no code
apps are. Literally used to develop modules for add-ons to these enterprise apps so that other business processes can be rapidly developed without you needing to necessarily. Spend a whole lot of money developing the. Big ERP systems that can be. Expensive and rely on. You know, qualified. Specialists on those tools. Okay, so I talk about. These low code no code apps. I'm just going to call them low code apps going forward, so I don't. Have to say. That that double whammy.
So what are they? So I think in order to understand what a low. Code app is we kind of need to understand what an application is. Anyway, generally and what makes up an application now I am. Going to simplify architecture here, I don't think it matters. If we go down to. I don't think it helps and. Matters that there are different variations of. Application architecture I think we. Just need to. Know about 3 layers and the three layers are. The interface, So what you the.
You know what you're using on your device. So if you were on your. PC You might have an interface you use which might be running a. Website kind of a web what's called a web application. So app. That you go to your browser and you view and you use. So there's, there's that, and then. There's also, I guess interfaces in terms of a mobile. App which is actually usually different a different. Set of code. That's written specifically to utilize.
Some of the functions and the hardware on a mobile phone. And so you'd find that, say, your banking app is quite. Different when you're on your. Versus what it is on your website and yes, there are ways of making them. Very similar to one another. And there are whole technologies about having. You know what's. Called one interface for oil. And and very similar and. You push it out. For both those different. Channels or those different device types.
Regardless, you know. Regardless, you don't have to. Do double the. Work in terms of interface design. But we'll just just as. Far as I guess, the point that I'm trying to make here is you have an interface, something that you're using to either enter information, update information, delete information, or view information and. That interface could be limited to just viewing information sometimes. Like viewing a website. But also you can have
application. When we do applications, we're generally talking about something you can you can interact. With and a. Term that we use with to describe interaction. Sometimes it's called. CRUD which is just an. Acronym that stands for Create, Read, Update and Delete. And so when we talk about apps, we're generally talking about applications. Which allow you to do those things. So create an account. Update your details. And of course there are other other functions apart from those.
I've just talked about in terms of. Viewing and of course of potentially kicking off or triggering an activity. But that's what we talk about when we talk about. So you've got the interface layer, that's the top. That's number one. There are only three layers. In this. What's called three layer? And yes, I am simplifying this and it has changed, but to be honest. I'm going to. Talk about the level that.
BI needs to understand. Is the interface layer and like I said, could have could be similar looking it could be completely different. Depending on on the. Channel or the device in. Which you are designing an interface and then in the middle. We have kind of what's called the logic layer. This is where all our business rules should sit. They should be common across our different interfaces. As they are what drive our business and so one example. If we talked about for a banking app.
It could simply be the rules around transferring money from 1:00. Account to another. Could be baked in at this. Layer and so regardless of if you're using your mobile. Phone or you're doing it online? The same logic or the same code? I guess that's fundamentally behind there, the same. Workflow if you like. Workflow is a really good. Way of thinking about this layer. Is is the same? And so there is a trigger or an action and then something.
Happens and there's a result. So in this layer you can generally draw quite nicely in a process diagram and your process. Diagram is generally if you. The system steps implemented in this middle. Layer the logic layer and finally. Underneath we have the data layer, if you like the. So the actual information. That the various fields that make up the application in terms of your name and an address you know. First name, Last name. Phone number for example is stored in.
Some kind of table? And the data layer and usually in what we call. A database. So you have those 3 layers database at the bottom. Which has got all the data in it and it's usually you know. Defined by a data model, so you might. Have your customer details in one area if you're building a customer driven app. If you're signing them up, you might have a provider. Table and you might have an offers table or a deal table and they might be the three kind of.
Tables that you had if. You were signing customers up for Internet services door knocking and you might have another table for the person who. Was signing them up. So they will all. Connect down the database, but it is actually easy to understand and most BIS should understand that at a high. Level and then you might have at that. Second layer, the middle layer. In the sandwich you have the logic which might. Send a new new customer details that have come through. A sign up form.
Either on the website. Or on this tablet that these doorknockers are using when they enter information. Through a form, which is a term we use for a type of way of capturing information on an interface like. The customer themselves. Or the door knocker will click submit and this middle layer. Will be used either have code or workflow to send. That information to the database and create a new. Customer record. So that's kind of how applications work.
It's just. Very Those 3 layers you've got an interface. You've got logic in the middle, and you've. Got a database and so that's how most. If not all applications work. At a very. Simple terms. There are ways in which you can drill down into those various areas and explain different ways of. Optimizing all that, but effectively that is how most. Systems in the world work, and you know the. Interface and the middle bit and the database.
Can all be different flavors these days, so the reason that's important to understand is that. When we talk about low, these low code apps generally when you're dragging and dropping your. Elements like the say for example we want to create just a one page. Application where we want to have a form to capture. Customer details that we're going to sign up, we might. Be at we will need obviously, a sign up. Form for that. We need some code or.
Some logic and we need a database to save the customer. Information like a table of customer. Fields and so these low code apps. Generally they don't come with the database, they might come with their own. You generally have to create. That separately. Or it goes into your enterprise data store, your warehouse. Is sometimes called. Referred to as your data lake or your data warehouse. You connect to that. So you get your. Dbas to create that. Or you know, or you yourself can
go through. Kind of a wizard to create that and then you start dragging and dropping. The fields you want, you say OK, I. Want a new customer I want to have. I want to click their name. Their first name? Last name, their phone number, their e-mail address and kind of maybe. When they're interested, or if they're interested in signing up for the deal, we've got on offer and a submit button. And so all that can be done through like a drag and drop interface.
Very, very, very. Similar to you know any other drag and drop interface. You've used, you know it just as easy, if not easier. Than say a Word document interface or a PowerPoint. When you're dragging elements on there and then and then we need. To, they're generally clever enough. To have all those fields within. Something called a form element and. Then we've got our submit button and and and and we. Usually the, depending on what. Log code app you're using, you
would hover over or click. On the submit button and that that's. Where you would tell it that you were connecting. To the customers table and you wanted to. Create a record and that's as simple. As that so the log code. Apps are actually not just. Providing the interface, they're also helping with that middle code, and some of them will. Have tabs for. Workflow to say hey look not only. Will we click this button? Do we want to? Send this information to the
database. We also want to change the information. In some way or send an e-mail. So they're actually, they're quite advanced and I've been playing. Around with some of them I've been actually really interested. In this area for years. And I'm going to talk about. Some of the pitfalls with some of these tools and why I still haven't. Found the perfect low code tool out there in a minute but I have been playing with them for. As a BA or as an entrepreneur
I've been. I've had heaps of ideas and I've you know, I had to. Work through development companies to make things happen, and sometimes they've been very. Very very simple use cases of trying to solve and I have enough technical. Ability in myself. To be able to create and deploy these apps. The thing about these low code apps, of course, is that they're generally running in the cloud. You can get ones that run locally and you know. Depending on the flavor or who
makes them. There could be different security concerns or non functional requirements that you have to worry. About so your IT department might not be happy, for example, if you. Just downloaded one of these and started using it. Which we called shadow it. Sometimes. So generally, the organization should decide on an enterprise Lowcode tool and then you know. That would allow those what we call. Citizen developers or non
developers to create? Forms where they need to capture information and obviously update. Information and and and. Show customer information. OK. So if you work for a large enterprise, you may have heard of these two tools, which are. Salesforce and Dynamics Microsoft Dynamics or used to be called Dynamics 365 Salesforce and Dynamics. Are two massive players in the what we call CRM market. They they use to, really. Manage your customer information
and they also have. What I call ERP, enterprise resource planning tools that they offer as well and at one point I think. We refer to these tools as Xrms, which means anything, relationship management and both those. Offerings were. Can be used to manage your internal CRM you know management of. Customers usually just internal. Use those they some they have slight differences. But at a very. High level. They do exactly the same thing. And you know, your sales.
Could use one of these tools to work customers through the lead to. Sales process and your marketing team might use them to market other. Players in the space are HubSpot, Zoho, they're generally the bigger. Ones in the. World and if you were working for a large. I would be surprised if you hadn't heard. Of those terms before okay, so. Those. Big behemoths they both have. Low code, no code tools. So Salesforce has something called.
Salesforce Lightning is its latest name and Dynamics has. A tool called. The Power Platform or Power Apps and these. Came out of their own engines and their own internal kind of systems. Which you could customize heavily if you. Knew what you were doing and they both developed these, kind of. Even simpler tools to extend their own application or allow these non developers. To be able to create these low code. Applications I talked about and. Rapidly create.
Applications to solve problems that that you may encounter, and not only that or that information would then flow back into the database so information could. Captured through the Sales Force, Lightning applications flow back into Salesforce. And their database, And of course they're charging. You for the space you use, but it's good to have it in one place if you're using Salesforce. And equally Microsoft will send all the information from Powerapp. Back to what's called the Dataverse.
Which is their equivalent or their database that sits under the Power Platform and Dynamics Now I've. Used both of these tools. I've used task force internally. I've used dynamics, I'm actually. Certified in Dynamics, I know how to configure the. System internally for. Corporations. But also I've played around. With. Parents, they're very good. That all what I would call would be easy to get certified by any organization in terms of. The nonfunctional sides are all taken.
Care of security. All the rest of it. And. And they're relatively cheap, I mean. Perhaps I just looked if. If you yourself wanted to play around there and just grab a license. It's around 30 New Zealand dollars 20. U.S. dollars to create an account, and that's just for. You just just to be clear, no one else and will come to this point soon. You can drag and drop. You can play around. However, they all involve a little bit of pseudo code that
you need to know how to write. So you do actually need to understand. For these tools and specifically the ones I'm talking about now. The language they use or how to write. The logic I talked about before. So in. Power apps you might You can drag and drop. A table quite easily and connect it to the customer. Table that you created earlier or created on the fly and you can suddenly see all the customers there and a big list and like a table and you might be like. Wow, that's happy.
You know, I'm really. Happy I was able to do that. So quickly, but then you. Go to create a new form to add a new customer and everything's going fine. You automatically. Drag and drop the form to a new page and it automatically knows exactly what fields. Are connected in the table and it. Throws them on the. On the page for you and again you're like. That's pretty good, but then if. You want to now change these things like for.
Example when you click the add. Button, you want it to navigate back into the. Previous page after you've added a new customer and some. Around how to use the application now navigate. Or you want to do some logic like filtering and sorting? You do actually have to understand how. These tools work. And how each each individual? One is quite. Different. And that is the disadvantage with using these tools. So if you became a Power apps. Developer you would know how to. Do power apps.
If you then jumped over to SAS Force Lightning, you might understand the concepts, but you would have to learn a whole. New kind of language if you like. Just like programming. If you wanted to use. That app OK. So there's the big. Players out there, however, from another angle, not from the. ERP. Big behemoth CRM world. There has been some small. Players that have propped up. Who have just said, especially now in the last 10 years.
Where they've created tools from what I would say bottom up. Not for the purpose of. Connecting with Salesforce or. Dynamics or just, you know, for the purposes of smaller companies. Really. To be able to create apps quite rapidly and so. Let's talk a few here. There's something called Buddy Base, which I'm. Playing with at the moment something called air tables, there's. Another one called App Smith. There's quite a few of them out
there and. They range from what I would say is semi open source and usually the open source ones aren't designed nicely and have less functions. There are the kind of freemium ones. Where you get like 5 admin users for free and a certain amount of space, but then you have to pay. If you go over that and then there are these premium. Options which you know can be in the hundreds or thousands of dollars per user. Which you can then pay for, which do much more sophisticated
stuff, and so when you. Write well, that's that third tier. The Dynamics or the the Power apps? Licensing of about $30.00 a month isn't bad. So what do you have to consider when using these? Apps Well for me. If it's a true low code, no code development tool, you can get quite frustrated when. You're trying to, you know, change the standard functionality, and for me, I judge them by how. Fiddly they are, or how much
learning I have to do? I did study programming at university and programming languages have got quite advanced. These days that if you, it may. Just take you just as long to learn a. Very high level abstraction programming language as it. Would be to learn one of these. Tools, so you know you need to weigh that up. So when I'm playing around. With them I kind of. Weigh that up.
I would find that power Apps in my mind is not that hard to learn, but you definitely need to understand the Microsoft way of doing things. The other thing is, you can't necessarily have the same flexibility. That you would have you just programmed it. Or you would just. Yeah, just got to program it to develop it. Some of your designs are. Limited but based on what the what we say the container or.
How the app looks the. Theme behind it all that design elements are usually standardized, so you might be. Able to change your logo and the back. Color, but apart from that and apart from. Writing what we call custom. Which is basically the style of your application you're pretty. Much locked into whatever this app looks like. And again, you know, depending on the low. Code app you use.
There are more. There are some which are more flexible in that area, but then you find that they're less flexible when it comes to programming. Or it just becomes a tool in itself, like a Photoshop we there's so many options that you just get lost in it the other determining factor that you needed. To really weigh up when you're a BA, who suggests? One of these tools as a solution is whether or not it integrates
with your existing architecture. So as I said before, if you've already got Salesforce and you've got this need. To rapidly create applications for various. Use cases. Maybe it's legislation changes and you don't have. A Salesforce team that you can use and you want these apps. So we'll talk about this very, very soon. You want these apps? Exposed to both internal users maybe authorized users, so those that you can authorize and. The public then these apps are
very good for that use case. And of course it would make sense to use the Salesforce version of these stores if you had Salesforce. And if you have Dynamics where you have the Microsoft family it probably makes. Sense for you to use the Microsoft version of it because then it would just you just know natively. Integrate with all the other. Stuff you've got now if you have
not. Got those two basis applications then you have a. Bit more freedom and if you're smaller then you probably want to look at some that are about. Or you know free ish like premium or very low cost now. How do these tools make their money and so? Therefore, what do you have to consider when rolling one of these out? And the trick here is all around users and. Who is going to use your app? And you need to. Decide this up front, I would say functionality, as in how? Easy the app.
Is to use and. Publish and get out there and how easy and how. Much sorry. How much? It costs. You are probably the two factors you should be thinking. About, I guess the final kind of unwritten rule. Is that does this tool? Integrate with your general. Architecture or the other applications you have, and that's important. It's not generally driven by you, it's driven by your enterprise architect or your
enterprise architecture. Or the other tools you have, so you should always think about that. But if we just think about what the BA is really thinking about, it's probably the cost, how much this is going to cost and how easy it is to use and when it comes to. Cost, this is. Where we go down the This go down a complicated path, we'll come back. To the SAS force and the power apps. Or the dynamics area? Both of those tools. Usually. There's a cost for those.
Who are creating the tool and it's not generally that much. And sometimes there's even a lower cost for those who want to use that tool internally. OK, so if you've got an. Internal user, so they're already on your network. You already know who they are. Generally, the cost. For them to use one of these tools once you've created your application is quite low, but then if you want to authenticate. So you want to know who's logging into the application You want to add a user.
There's generally a, There's generally a higher. Cost and. Specifically, there's a cost. For the public to access these apps. So if we were talking about the example where we had door. Knockers who were signing customers up for an offer. For an Internet service. Those people that are signing up may not be your your Internet provider users. They may not be staff. That you work, they work for you. They may be staff that you're just hiring to. To do the door knocking and
therefore they might be using. You know they are not. Specifically our users. They are authenticated users because we want to know who they are. But they would require an account, and the reason that's important and the reason why you want to work at how many public users on average, how many authenticated users and how many kind of. Local, If you like business users, you're going to have is that they generally charge you for the amount of. Users you. Have on these platforms. Starts off.
Free or very low to. Create these apps and then suddenly they. Charge you a per user. Per month charge now if there if those. Charges per month are. $30 per user. Per month and the number of users you are going to have are 1000 a month. That's $30,000 a month that you're paying. So you've got to be very. Careful when you choose these tools that it's actually going to meet your. Requirement if you're a smaller. Company, I would suggest that you look for those low code
apps. Which are free? Unlimited customers or interactions? Or portal views like web views, but maybe a cost for the internal users. For me that seems like a. Fear of better model and so you maybe only need 5 administrative users who are creating apps and so somewhat there are offerings out there. I talk about Buddy Buddy base before, and that's one example. Or some of the other EAR table for example. Quite low cost for those who are creating the app and maintaining it.
You only need maybe. Five of those users and it's actually. Free for external users. To be able to use those apps. And yes, there's other things like paying for plugins and all sorts of add-ons you can get however. That's a good scalable model if you were thinking about using one of these. Tools to solve. A problem? Otherwise, you're better off just using the tools you have. Or Excel for example. However, if your tool on the other end. If your enterprise is already.
Paying for Salesforce and already paying for Dynamics. And you already have users, then you're not actually adding in any additional cost apart from, you know, the. Package you already bought, however they. Both this is Salesforce and Dynamics. And also source Soho, which is generally cheaper. They all charge you for public users. So for example, you create an app and you used it. To publish some form on your website. Or portal so external users could.
Log in. Your customers could log in and maybe manage their Internet connection details, or sign up or manage their account like, I don't know, like a. Bank. Website they would charge you. For those public users or the public views as well as if you needed to authenticate those users. That would charge you so. That's why it's important. To segment users in terms of public those anyone. Who can visit your website? Those who need to be authenticated. And then those business users
and then look and see. What these various tools are? Going to charge you for I would say that some of those tools are still worth. It very much worth it, especially for your internal users. To go out and do. Like I said, door knocking. May make sense sometimes. They're not the best technology for your public website. Okay. So if we then I guess circle back. To what? These low code, no code apps could be used for. I think that some of the use cases. That I've used them for is when.
For example, you're working. For a government department or you're working for an organization that just rapidly needs to capture information and you don't want to capture it just in Excel, You want to have it structured and you want. To be able to update that information, it's. Really good for those different use cases, especially if you can then connect that low code. App to A. Database where your other data. Data resides, so you're.
Enhancing the data you've got. One great example might be, for example in the situation where. We've got customers, customers who we provide Internet for this application we're using to sign. Customers up through door knocking. Would be a perfect use case because we could literally if that. We already door. Knocked to a customer. We've already got, we could look up their details and we could kind of try and upsell them. Or see how they're going. Ask them for feedback and if we.
Door knocked on someone else's door. And they weren't a customer. Because they're not in our database, we could add them straight to our database. That means that back in our call center or back in our main office, those details are automatically captured and automatically in our. System that we use for Internet providing and. For, you know, provisioning
accounts, so we've missed. Out a whole lot of double data entry that would have to happen with the information stored in our enterprise repository in the same. Format it was captured, which means it's less likely to be any. Mistakes And you know, we've extended what our enterprise application. Can allow us to do by just pumping information through the Slow Code app and they're. Great examples. So if you can. Think of examples in your.
Business as a BA where you know it's really expensive maybe. To change the enterprise app or you don't want. These door knockers or these kind of. Contractors or extended people to view the main app, then low code no code apps are fantastic. The other use. Case that I would say. Would be a great one. Would be if you're a startup company and you. Just want to mock up a simple. App or a simple? Website which allows some kind of interaction.
These are perfect for doing a very very simple mobile app. Some of these will instantly. Convert your app to mobile and publish it. If you like for cost generally to the App Store and. To the Google store, so both the Apple and Android store and your designer can generally. Work with these tools as well, so you as a BA may not be. Working in them, but knowing that they are a solution there and that they are. Possible.
Tools in your. Toolbox to talk about or to at least challenge and ask about will make you. A better BA and if you want to have a bit of a play with some of these. Low code, no code apps. I will check on our website in the next week. A bit of a. Review of maybe the top ten. I have reviewed maybe 50 of them. Over the last little while. And I'll probably put on there the top, what I say is the top ten, they are pretty fun to play with. If you've got any technology
background then you might. It can be quite fun and I think you had some of the frustrations I talked. About where maybe it's easier just to, you know, hire a programmer and you'll be. Able to see what databases or back end these. Systems can connect to and, so maybe you. Can think of some use cases. In which they might be useful. At your. Organization, finally, I'll just remind you all you are. BA's so don't try and you know, create a solution and then find
a problem for it to fit. We start with problems first. BA's and process problem, so this wasn't an endorsement. To just go out and create apps. For the sake of it, but I do think I've had this many times in my BA career where we have been spending, you know, literally. Millions of dollars on creating changes to. Some of our systems. Because that was the only option
we had. Whereas now there's, you know, a very standard way of extending these applications without spending a large amount of money, especially for one specific use case that you want to do. And allowing that information to flow back into the Enterprise repository means that a low code, no code app is something that every BA should understand.