If you are a developer or engineer, you may think that you have no use for Microsoft's newly coined "Citizen developer" tools --and you would be wrong. These tools are not only a great way to keep your own teams on track, they are a great way to push your product team/business stakeholders to provide real requirements, without getting into the weeds, in your lane, or --heaven forbid --using technical terms that they do not actually understand.
What?
--NO, this is not a let's-bash-product-teams post. Just straight talk to acknowledge that we've all heard implementation specifications from product teams that have no basis in the reality of the development efforts. In the same way that most product professionals do not want or expect developers to speak to the business value or definitions of OKRs, KPIs, RACI diagrams, or SWOT analysis, so also do the developers not want to have product or business people using words like architecture, design, scale, API, integrations, Git, merge, rebase, etc.
To be clear, that is not only a preference or opinion; it is a real issue in development teams --especially ones without full processes, mentoring, and architecture in place. It is further complicated when you have several junior team members. When a story or requirement is written in such a way as to use a technical term, it is entirely possible that the developer will take that term as part of the requirement, and thus deliver something with technical limitations.
Why?
For instance, if a story was written to say that "a service is needed," depending upon that developer's experience, he/she may interpret that to mean a Windows service, a service component, a web service, a WCF service, an API, a RESTful API, a Serverless API, etc. In actuality, that story's requirement should have been coding-language and technical-term agnostic, and instead only specify the what and why. This allows the developer to seek out an architect, call for a design session, or refer to the department's reference architecture to determine how to satisfy the true requirement of the product team --which is how a development team should operate.
It is quite possible --and beneficial --to collaborate and to also "stay in your lane" to "do YOUR job." Those statements are not meant to imply lack of communication or transparency. They only mean that one should be able to trust that the person who has devoted his/her career to the pursuit of a skill will probably have a better idea of what is to be done than another person would.
How?
So, how do you get there? My own suggestion is to take advantage of these new tools. To that end, I'm going genericize an example with concepts that everyone uses daily, and extrapolate to its use in development and business collaboration.
Tools
I'm going to first assume that you have a passing awareness of Microsoft's "Power Automate" or "Flow" or "Power Apps" --which may be renamed again at some point in the life of this post, so I am trying to cover my bases. (There is also now a desktop version --which is NOT what you would infer from the name, but that is a different topic.)
If you are not sure if the application is included in your subscription, you can determine so by going to flow.microsoft.com. (That may be the old URL, but it still gets me there, so okay.) This is Power Automate.
At this point, you should see the page below.
(If you are not logged in, do so now.) To set context for the systems' design aspect, we will quickly look at a section --but not explore it today. This is for you to have in the back of your mind as we walk through the exercise.
Design aspect
On the home page, find the side menu option labeled Data. Once expanding it, choose the sub-menu option of Custom connectors.
You probably have no connectors thus far, and will see an empty page. However, you should also see a link at the top corner to create a New custom connector. If you click that link, you should see the options shown below.
Designing for integration and reuse
What I want you to notice here is the option to Import an OpenAPI from URL. and Import an OpenAPI from file.
OpenAPI (OAS 3.0), (formerly known as "Swagger") is an API description format for REST APIs. API specifications can be written in YAML or JSON. An OpenAPI file allows you to describe your entire API including:
Available endpoints (/users) and operations on each endpoint (GET /users, POST /users)
Operation parameters (input and output) for each operation
Authentication methods
Contact information, license, terms of use, and other information
NOTE: For any development efforts that have the potential to be externally available, it is a requirement of MY teams to adhere to the OpenAPI 3.0 definition. (This does harken back to the days of the WSDL for web services, but I am personally ecstatic to see these standards for development being updated and managed again.)
In defining an API, whether the intent is reuse or external integrations, and even internal-only accessibility, this is a good standard to follow. Presumably, an API endpoint should be able to be imported in this way, and this tool provides and easy way to verify that it is an easy way to verify such. (You'll see how and why shortly.)
NOTE: When you are developing or prototyping a solution, it may not be intended for reuse or external visibility. However, if you code it in such a way that it can be, you are enforcing standards and security that should always be addressed. If you plan for it from the onset, this will keep you from having to revisit the areas later, or when/if the overall requirements change at a later date. (It also allows for this initial work to be capitalizable early on, without the potential of expensing the work and effort as maintenance in the long term. That's a topic for another day though.)
Flows: Templates or Create
So, let's go back to the home screen and choose Templates or Create for a new flow.
Templates allow you to look through what is already done and available for your reuse. This means that some task was so common or requested that a template has already been created that you can simply choose and add to your set of flows, with very little configuration --usually only connector credentials.
Create instead assumes that you are experienced and you already know that there is no template for you, and you want to start from a clean slate, connectors and all.
Templates are added daily, and you can submit your own template if you think it is valuable for reuse. You would be surprised what you can automate, and this is a fun thing to keep current. --There is a template to send a push notification to your phone when your boss messages you. While definitely valuable, I suspect there are several people who have created a flow from that template for what I would call "off-label use."
For instance, if you type GMail into the search for templates, you will see the following:
Common example
For this example, we're going to choose an email template, as it is a concept with which everyone should be familiar.
NOTE: The system offloads the security aspect to the Power Automate system, but only because the developers have implemented it in such a way as to make that possible. There is a separate post that explains how this is achieved. For now, assume that the connection is secured and retained.
TECHNICAL NOTE: In the case of developing your own API, this is a good way to test and prove that you have successfully implemented/integrated authorization and authentication to your API at each level. Even if your API is intended for internal use only, a security scan will surface your "untrusted communications" and force you to remediate, so you might as well get ahead of it. (Microsoft passive-aggressively requires this in the use of their own tools as well, like PowerBI's Power Query.)
In this example, configure your connections, and then create the flow itself.
This will take you to the flow's summary/details page, at which you can click Edit. (FYI, as this example is an automated flow, it is already running.)
NOTE: If you see a screen that says "Plans," this means that you are not logged into a subscription to which the configuration for Power Automate is already set up. You can follow the instructions given or you can contact your Office/Microsoft 365 administrator. For clarity, you can see this internal post for troubleshooting.
Back to the example, you can click on the second step, titled Apply to each attachment. From the API's definition, the system knows that the output from the previous action is potentially a collection, and so it automatically included what amounts to a "for each" loop. In this case, the template is to save each of the potential attachments to your Google drive. Thus, the nested step is to Create file.
Next, click in the Folder path text box. Notice the ability to browse to folders in your Google drive.
Then, click in the File name text box.
Notice that the outputs from the previous step are available as Dynamic content, separated into the name of the action or step. These are defined by the OAS definition detailing the attributes and actions exposed by the API.
Now, click either Add an action in the contained action group, or New step from the button below the box. You would see one of the following two screens, respectively.
For the Add an action, it adds the new Choose an operation activity INSIDE of the Apply to each attachment grouping.
For the New step choice, it adds the Choose an operation outside of the Apply to each attachment group, as this step will not apply to each attachment and would be part of the overall flow.
Regardless of your choice, type in Google in the Search connectors and actions text box.
By viewing the results here, you can see a few examples of ways in which, in individual development/design efforts, you can choose to differentiate your product offerings. These are all Google, however, and they've chosen to showcase Sheets, Drive, Calendar, Tasks, and Contacts as separate products. Further, each has different actions and triggers available, as appropriate.
NOTE: If you had searched for Microsoft instead, you would have gotten a large list of potential products. Additionally, some may have been labeled as "V1" or "Preview," as Microsoft owns this platform, it is easy for them to keep it up to date with their latest and testing.
From examples like this, it is easier to provide direction in design to disparate development teams. It fosters more product-level thinking by developers, but also keeps product stakeholders abstracted enough from the technical details to allow them to focus on the what and why and not the how. Simultaneously, it instills more compartmentalized thinking by the developers in terms of creating --as I refuse to say microservices --RIGHT-size services. For LeaseQuery-specific applicability, click here. Otherwise, click here.
NOTE: This is an extremely high-level example and does not begin to touch the area of overall solutions, error-handling, integration with other Microsoft systems innately, conditionals, variables, property tracking, etc. SO fun!
Comments