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.