Power Platform ALM – Basic Component Lifecycle

 

Introduction

In my previous blog, I explained some words—product, component, environment, editor, and magic—that I will use in this series. In this post, we will use them with an example. However, if you haven’t read it, I recommend you do it first.

ALM is more about maximizing business value than a technical term. However, since its focus is on software and also automation plays an important role in it, the technical aspect is quite significant. Nevertheless, it’s important to consider that its primary objective is to maximize business value.

Not surprisingly, in Power Platform, projects are all about adding value to a business. Otherwise, no business wants to pay licenses and receive nothing in return. In other words, every company wants to provide value quickly while paying licenses.

Let’s see it with an example.

Example: A magic for Bizchitect Recruiters Co.

Bizchitect Recruiters Co. is a fictional company that finds employees for their customers and earns money. They started their business very small with some talented people. They did it well, and now many customers trust them. However, they primarily used Excel files and didn’t have many systems. So, now, they are suffering from distributed Excel files, and Recruiters need to check the shared mailbox to find relevant job offers, which is time-consuming.

They employed you as the Power Platform magician and told you this problem. You understand if you can satisfy the following simple statement from recruiters, you will add value to this company:

As a recruiter, I want to:

• View only job offers relevant to me.

• Minimize form filling time.

You decide to do your magic by using these products: Dataverse, Power Apps, AI Builder, and Power Automate.

Here is the list of highlighted components you decided to make:

• Job offers table
• A Dashboard for Recruiters that is supposed to show the important information to recruiters for daily use.
• Bizchitect Recruiters model driven app
• AI builder: You trained one AI builder and called it “Extract job offer,” which extracts some information from the attached PDF.
• A Cloud Flow called “Convert Email to Job Offer” creates a Job Offer record whenever a new email is received from a customer. By leveraging the Extract job offer AI builder component, it fills the Job offer record as much as possible from the attached pdf.
• One security role called “Recruiters” to provide access rights to the team of recruiters

Assume they have purchased the required licenses, and their administrator created an Environment called “Bizchitect Recruiters.”

Fastest way of doing magic

What an excellent opportunity for you to be a hero in your new company! Let’s not waste time and start doing it as fast as possible. By the way, what is the fastest way to provide them with this magic?

You are right. The answer is to open the corresponding Editor in the Bizchitect Recruiters Environment, create the components, and provide our magic. Why not?

It took you one or maybe two days, but you are done. You have made it and published the components and see they work. You write to the CEO that you are ready. He asks you to meet him in his room. He looks at you surprisingly and can’t believe what a true decision it was to hire you.

You show him how it works. You send a test email with a PDF attachment, your flow is triggered, and the job offer is created. Amazingly, the job offer’s Title, Description, and Budget Range have also been extracted from the PDF and shown on the form.

He asks, what’s next? And you decide together to train users and prepare them to use the system.

You need demo data, so you might think, okay, you will delete them right after the demo. Then you go on. Your demo goes quite well. However, somehow, in the middle, you encounter some bugs. No problem! You continue your demo and promise to fix the bugs before asking them to start working. After all, the demo is booming, and users like it. One day after, you fix the bugs and tell them they can use the system. 

Amazing! For the first time in software development history, you provided a software application to be used by end users without bothering to install something. You just saved it, published it, and they are using it. How fast was it?

Now, you can find another area to add value to the company and do more magic there. For example, let’s create a Power Pages portal that shows job offers and allows people to apply online.

Unluckiness

First, do you know something? We forgot to delete the demo data, so we ended up with dirty data from the beginning of our magic. What if they want to have a report later on the number of job offers? We have created many fakes of them. Not surprisingly, recruiters also tried some fake data to practice working with this magic. Damn it!

But wait, there is something worse than that. A colleague told you in the chat that something is wrong with your magic. There is one Job Offer record with no extracted information.

After investigation, you realize a customer sent an email with a Word document attached. God, your magic only works with PDF attachments. They told you customers always send PDF files! What a misfortune!

You think to yourself, how much unlucky you are? Why it happened to you? Was that your fault? Of course not.

Magic has Lifecycle

Should you have designed your system to accept Word documents since the first time? Maybe, yes. But, even in that case, could you be sure that your magic can’t be broken in another way? Add to that, if you are sure about the bugs and failures that won’t happen, can you also be sure there won’t be some new requirements? Are you surprised if I say users also asked to add some more columns to be fetched from the PDF? Some customers added this information in their attached file.

Is that the last request they have? No one knows. And probably not at all. There will be new feedback that you can add value to the magic again. If your magic is used, new ways of improving will always exist. Believe me, only dead magics have no new requirements.

Okay. Let’s see what we did. We planned first, made it, and then provided it for use. To make a long story short, this approach would be perfect if digitalization magics could be done in one step.

But this is not true. You can’t predict everything that might be needed. In reality, lots of valuable feedback comes from the usage. That way, you might see some bugs. Or you might see some new requirements that can make the magic even better.

That’s not a one-step process; instead, it is a loop. So, after using the magic by end users, you receive feedback, start planning for it again, make your new magic, and then enable it for use. As long as this magic is used or is alive, this loop can continue. This is called the magic lifecycle.

Indeed, so far, you just did the first loop, as the following picture depicts.

In reality, something like the following picture happens. You start creating, and then Magic 1 is created. Then, after receiving feedback, you plan for Magic 2, and so on and so forth.

Align making components to Magic Lifecycle

Now that we know how the business side forms our magic lifecycle let’s see how much our approach to making it aligns with this lifecycle. In fact, we should find a way to update our components after each loop without affecting their use, shouldn’t we?

How can we do that? Can we keep our components in testing mode until we can bring them to working mode?

Now, in our example, what should you do? Obviously, you need to update your cloud flow. Would you start updating it to support Word documents? What will happen if you receive some new emails at the same time? It now at least works fine with PDF attachments. But, in your first change, you might break it. You need to train your AI Builder again. How can you be sure it will work properly after you retrain it?

Additionally, to test if it works, we need to email the company’s actual email address. So, we will not only fill the inbox with test emails but also will make fake records in the Job Offer table again.

It seems our plan is not aligned with this lifecycle. However, to determine what’s wrong and how to resolve it, we need to grasp the component’s lifecycle.

Component lifecycle inside Environment (using editors):

What do we do with components inside an environment? We open an editor and create a component. Then, we might add or edit more. Sometimes, we realize we don’t need a component, so we delete it. Whenever we want to check the behavior of our components, we publish them.

We also need to activate some components after publishing, but for now, let’s dismiss that and keep everything simple. We assume all components will go into working mode after publishing.

Hence, here is the list of modes our component can reside in.¹

When a component is in edited mode, its runtime behavior only changes once we publish it using the editor. Therefore, we can only test our component whenever it is in published mode, and at the same time, it will also change its behavior for the end users. There is no testing mode in which we can bring our components. Right after we create and update them, we need to test them. By that, we need to publish. Then, we change the runtime behavior of our magic for everyone (for us and end users).

As we see, the component lifecycle inside an environment is not aligned with the magic lifecycle we have investigated so far. We need to find a way to align it.

One Environment can’t satisfy the Magic lifecycle

There are some other issues in addition to component modes. Assume we were able to bring our component to testing mode. Then, to test our magic, we still need to send an email to the company’s actual email address—the same email address to which customers are sending their job offers, which is not a good idea. Second, we create test job offer records in the “Bizchitect Recruiters” environment, which is under use. So, we are breaking data cleanness.

Now, we know the problems. What is the solution?

Solution: Having two separate Environments

So, our approach of making magic in the Bizchitect Recruiters environment was fast and useful only for the first loop, but then it blocked us for the following loops. So, the fastest way was not necessarily the best way. We should have considered some more aspects.

What if we create, update, and test our components in another environment—let’s call it a Develop environment? Look at the following picture². Imagine that in the first loop, we provided our Magic 1. Then, we moved it to the Bizchitect Recruiters environment. Now, users are using Magic 1, and we can start making Magic 2 without affecting the end users. So, we don’t touch components of that environment until our Magic 2 is ready to move.

More than that, we can test our magic without creating test data in the system under use. We can use a test email address for the Develop environment and send our emails to it. Bingo, it seems we could solve all the problems.

We wish we could have started this way, right? But, we didn’t. So, let’s clear the clouds on top of our heads and face reality.

First, we ask the administrator to create another environment called Development. But wait, our components are inside production environments in published mode, and our Development environment is empty:

Now, the question is, how can we move our components from the production to the development environment and start working with them? Or should we create them from scratch?

Can they also be moved back later from development to production? The short answer is yes. But let’s save this topic for the next blog.

Conclusion

In this post, we touched on the word lifecycle out of ALM. You know it stands for Application Lifecycle Management. We also replaced the word application with magic, didn’t we? Now, we know a little about this lifecycle, and we have started thinking about how to manage it.

We also learned the basic modes of components in their lifecycle inside an environment. We now know the limitations of component modes and why we needed to have another environment for development. Also, we know that we should keep our production environment just for real data and not create test data in it. Having another environment will help us manage it.

In the upcoming posts, we will learn how to move components between environments and investigate the magic lifecycle and components lifecycle even further.

Footnotes

1. Please note that these are not directly written in Microsoft documents. So, the name of the states is not my main point. Instead, their concept, attributes, and characteristics are important, and my goal is to make it clear. ↩︎
2. Icons created by Freepik – Flaticon. ↩︎