>> Hey. Good news. We have another episode
about how architecture is changing.
This time we're going to talk about low code development.
Join us on Armchair Architects.
[MUSIC]
>> Welcome to the Azure Enablement show,
where we'll be discussing the challenges you,
and our other tech-savvy customers have encountered.
Together, we'll be talking with [inaudible] to find
out how they think about these problems,
recommended tools, and best practices,
and tips they've learned from
years of experience that you can use.
Today on the Azure Enablement show,
we'll do something we've never done before.
We're going to take our script, and we're going to
simply rip it up
because we want to talk today about
architecture and architecture is discussion.
We're back with Uli,
and Eric to continue our conversation.
In our last conversation,
we were talking about some of
the contexts that seemed to
have an impact on how an architecture,
and it's actually changing architectures certain amount.
We talked a little bit about containers,
we talked a little bit about collaboration environments,
we talked about serverless.
Now what I'd like to do is talk a little bit
about this other thing that's going on,
which is this concept of low code.
Which I would love to know what you mean by low code
because I can write low-code pretty easily.
Like here's my tool, I bash script,
but I bet that's not what you're talking about.
What do you mean by low code when you're talking about low code?
>> The way I think about this is low code is an environment
where you can start to build
solutions without having to being a professional developer.
You still might meet coding experience or technical experience,
but the tuning is more graphic,
it helps you with positioning information.
You can drag, and drop capabilities into the environment so that
your focus is on
the business problem because your domain expert in finance,
in operations, whatever it is.
You're trying to design a workflow in an interaction that
optimizes the behavior or the functionality for you.
This is not a new thing.
If you think about the Visual Basic of the day,
Windows programming was very
painful because if you could only do it in C++,
and it was really hard.
Visual Basic changed all of that.
All of a sudden, there were
hundreds of thousands of developers building Windows solutions.
Before that were thousands of developers,
and it was really complicated.
For me, low code is an environment to
think through of how do we engage
the non-professional developers in a way that
allows them to build solutions for their specific scenarios.
>> Yeah, go ahead. Sorry, Eric. I want
to ask a follow-up question when you're done.
>> Yeah, sure. I was going to add that what Uli
stated is it means that there's a lot of power.
We've democratized software development
into a designer driven interface,
and we pushed application development closer to the users,
and the consumers of that app,
which is largely a good thing.
There are challenges that I've walked
customers through when they start asking questions like,
well now this app is viral within my organization.
Everybody loves it, but it's slow, and it doesn't perform.
I changed something in the app last week,
and I broke everything. That's super bad.
Now that my app is super popular,
we've got this prospect of having to teach people
about application lifecycle management,
and how to version things,
and how to deploy things,
which is that a conversation that
a business user should have once they design these apps are not?
The jury is still out on that one for me.
>> Actually, the good news is that
the new generation of
low code scenarios like the Power Platforms of the world,
and so forth, are offered as a SaaS,
as a software as a service product,
and not a stand-alone product like Visual Basic was.
Therefore, you can actually start to put services,
and intelligence into it that wasn't possible before.
Governance, like the scenarios you could viral application,
and change management,
and so forth are built into
the service because it's offered as a software,
as a service solution.
The other piece that is happening
is that a lot of these low-code environments,
again, I'm leading with the Power Platform,
but there are others,
also now support integration with solutions like GitHub,
where you can take the software,
and manage it professionally if you so desire,
because you don't have to,
the SaaS platform does a lot of that for you.
But if you want to say, actually I have professional code,
and I have low code,
to use these two terms,
and I want to manage this consistently
because there's dependencies between those things,
you can now use solutions like GitHub to do that.
>> The question that I have in my head is,
from a user's perspective, I have my app,
I drew it up in my application in my low-code environment.
Somebody else took that, and they're like, "Hey,
I know how to improve upon that," and they made a change there.
Or, and a third-person is like, "Well,
what's there between Uli's version, and Eric's version?"
I'm hoping that we're getting to
further maturity around that because we
have learned some things around software versioning,
at the very least, the ability to be able to understand it.
One of the places that I wonder about
is from an architectural perspective,
are we bringing some of the lessons that we have from
software engineering to the low code stuff
in a way that, which is,
I think a tremendously hard problem where we can
help people who are not coders understand versions?
>> I think that's the key. Uli,
he knows more about this area than I do.
But I'll speak for the Power Platform that I'm most familiar with.
We've got solutions, we've got a backing store,
and what we call the data verse,
and we've got source control integration for Power Apps.
But I think the gap will be teaching people that art didn't grow
up in that capability of
a software developer to leverage those components.
To educate them that source control
should be your single source of the truth.
That you shouldn't just be able to just point people to this URL,
and then you can change things in the background.
I think that's going to be critical.
>> Again, I would point back
to the governance model that's built-in.
For example, there are ways for me,
if I'm the original author,
to prevent Eric from changing things.
There's authorization, and
authentication that's possible in the system.
I can give rights to Eric,
I can also revoke those rights centrally.
There's a bunch of things in the platform that helps you.
We need to certainly continue to be enhancing the governance.
The team is currently doing that,
our teams, because again,
it's not just the power platform.
The integration with things like GitHub can help.
But that requires IT support because
a normal local developer or businessperson
will not know and want to
know what GitHub is, and they shouldn't.
>> Well. I guess I want to say
that I like government stuff very much.
But I want to say, I'm taught more towards,
and maybe it's just my progressive streak
towards not constricting what people can do,
but making sure that, million flowers can bloom.
I want you to make versions of my thing
as long as we can all play nice together.
I want you to improve upon it,
not necessarily lock it down.
Which I think is important,
and a definitely important in the business,
and in an enterprise context.
But I also think if the goal is to
tap into this resource of people who know their domain,
they just don't know how to code it but now they can.
I want to lean into that as heavily as I can.
But from an architectural perspective,
what guidance can architects offer somebody
who is a domain expert but not a coder expert,
or even the people that are building stuff for these people?
What do we know as architects that we can give to
them that is helpful to them?
What would you tell somebody if somebody came to you and said,
"Hey, we've got a new recording thing.
You know a lot about building software,
I don't know anything about building software.
What should I pay attention to as I'm dragging and dropping?"
>> I think it's asking well-placed questions.
I know that I'd approach it from a position of
humility where I asked questions such as,
how many people are going to be using this?
Where is it going to be deployed?
Is it going to be deployed in a specific region?
Does it need to go all around the world?
What are some of the dependencies?
What happens if this app isn't up and running?
Asking questions like that that are
topical and you're not just scaring them with
Githubs and source control and
all these types of things will actually help bridge the gap,
and then to allow for you to have a conversation
about bidirectional education almost.
I thought where you're going with this question, David was, well,
how do architects know whether or not
a low code solution is better
than good enough versus writing the code.
>> I like that question too.
>> My idea is the way I
approach and this might be a personal style thing,
the question I always ask is,
is the simplest choice good enough for a good 70,
80, 90 percent of the use cases and where it's not,
how can we fill in the gaps?
Then once you're proven wrong, then you say,
well these are the reasons why I can't
actually implement the low code components or
low code application but
I actually need to invest time in traditional,
more well travel patterns of software development.
>> David, to come back to your original question,
how do architects help?
It's very simple. The platform is a SaaS solution.
There's a lot of thought that has went in there to enable and
expose the tooling that effectively is in this visual designer.
Every connector to a database or a share point or whatever it
is has been carefully designed so that a casual user,
a domain user, can really overwhelm the system.
There's a lot of the stuff that we talk through
the series that's built into the platform
itself because we know we have learned a lot
from Visual Basic and [inaudible] of
access and those environments,
and really culminated those learnings into
the Power Platform and the dependencies you take.
For me, should some people that build applications think?
Yes, but they should think much more
about functionality than about the rest of the stuff.
That I think is a really important piece
because the platform itself has templates,
has connectors that are predesigned for you
to effectively achieve efficient usage.
Is it perfect? Never is,
but it certainly is a great start to get
really good applications that scale to a very large point,
and these platforms will continue to make
improvements to get even better.
>> Let me respond to that with
a last question as we come out here.
I'm a little hesitant to be as enamored with
The Blind Watchmaker idea, like,
we the architects have thought very hard
and we have brought down from Olympus this thing,
and now we don't want to
participate in this, and there's nothing we,
as architects can learn
because we have given you the perfect world.
It's your job to use it.
What do you think architects don't yet know
about low code that they are still learning as we're going?
Because I don't think it's a solved problem.
Otherwise, we'd all be
doing a different job. Let's put it that way.
>> The round that's really start to be explored is if it's,
let's say a database or share point and so forth,
a lot of work has been done.
But now you're saying, "Hey David,
wrote this awesome microservice or service functionality,"
and now I would like to expose it into a low-code environment.
Now you, David,
have to build the connector so that
it effectively becomes efficient,
be usable inside a low-code environment.
We call that the fusion developer
or development approach where you
fuse together a professional code that somebody wrote like you,
and low code where business domain person wants to change
the flow or have a specific user interface, whatever it might be.
This fusion development I
think we're at the beginning of this journey of how would
I take code that anybody writes
and exposes it into the local environment.
They are not carefully curated,
there are now masses of
developers exposing their functionality into low-code.
Again, the fusion developer
is something that we care about a lot.
Good news is that if you, for example,
use Azure as your environment for hosting your solutions,
you can expose your code using Azure API Management,
and the API Management Team is building
the Power Platform connector for you automatically.
Again, that has drawbacks because anything that's
automatically created makes general assumptions.
But it is better than
a person that doesn't really know how low code works,
exposing their application in
a way that doesn't scale, and so forth.
The API Management protects your service and
the low code from misbehavior or over usage and so forth.
It's certainly a nice buffer in
between your code and the local environment.
>> I think David, [inaudible] if
I can jump in and add to what Uli's saying.
I think the perception is from
an architect or a technical person will
hear low code and assume a lot of what Uli just said,
oh, it's making
all judgments and I actually can't get under the hood.
I have to get behind the seat and
just be another passenger in this car.
Whereas I'm used to actually making
these things behave deterministically,
how I want them to behave.
To that I would say we need to
explore it because I know from our perspective,
the fusion developer and
the Power Platform development experience is
actually just accelerating in terms
of the number of people that are going to be able to write code.
It's not going anywhere. I actually to
this day when someone says low code, no code, I'm like,
but what really I need to do is change that response and say,
this is going to actually be something that's productive.
Maybe viral, maybe super important and may end up being
better because it's closer to the domain of
the people that are using it, that will use it.
>> It's actually far different. I hear you, Eric.
Again, if we could write all the applications that are
necessary with handcrafted tools,
maybe that what's the right thing to do.
>> By the way we are not arguing for
this, I'm going on the other side.
>> Well, the problem is that we have
a backlog of applications in every enterprise,
I don't know what the numbers are.
There's impressive numbers that effectively
say the developers that we have,
the professionals cannot write all this code to
automate business processes and
therefore we have to come up with this fusion.
But the professional developer deals with
the things that need superscale or resiliencies,
self-healing, and customization.
Whereas the local person is
the business domain person that
effectively goes and builds the workflow,
the user experience for their scenario on the back of giants.
Be that David as my professional developer,
I'll be that companies like SAP or Microsoft or whatever,
who exposes their capabilities into this local environment.
Again, for me,
the combination is what makes it interesting.
>> I think we've run out of time.
I just want to say it's interesting because this connects back
to me for the collaboration environments
because fusion developers now have to understand and
contemplate this very unique context that
they're writing things in that
doesn't behave what they're used to.
I know another one of those things has
to do with when you're dealing with machine learning and ML stuff.
Would you be willing to come back for
another video to talk a little about that?
Because I think we should get into,
dare I say it, software architecture 2.0?
>> Yeah, let's do that.
>> Great. See you soon. Well,
we're deep in the middle of this conversation.
I really hope you'll join us on
the next episode where we pick up right where we left off.
Join us again on the Azure Enablement show.
[MUSIC]