I’ve been involved with a charity that had a great idea as to how to support and develop learners and more experienced speakers of the Manx Gaelic language. This language is not covered by the usual educational tools such as DuoLingo and can rely on the goodwill and comfort of an experienced speaker.

Seems like a good opportunity to use it as a case study for exploring Microsoft’s Power Platform, and build on my existing certifications and knowledge.

We can call this a “Buddy System”.

Where to start?

As with any solution, establishing the correct architecture is crucial. We should consider:

• Requirements
• Stakeholders
• Performance expectations
• Security
• Cost

Requirements

We can summarise our requirement:

Solution that will connect learners and experienced speakers of a language, considering levels of skill and preferred communication methods to facilitate time-bound meetings which must be paid for by the learner.

Requirements can be broken down into Functional and non-Functional, which allows us to separate our requirements into directly related requirements and those which could even contribute to emotional responses (“this thing is so slow!”).

Functional requirements

Functional requirements relate directly with the the potential benefits of the solution.

• The solution should allow all classes of user to use the solution to satisfy their own requirements according to their role.
• The solution should manage payment of matching, which are payable by Learners.
• The solution should deliver reporting and provide opportunity to create matches based on the administrator’s own knowledge, or rely on recommendation heuristics based on preference of learner and mentor and/or AI-generated suggestions.

Non-functional requirements

Non-functional requirements can be regarded as the “softer” requirements of a solution, which if got wrong could even create emotional responses.

• The solution should use an interface optimised to each class of user.
• Personal data must be secure and only accessible to the inputter, where a match has been made or by an administrator.
• The solution must meet performance expectations of users.

Stakeholders: Identify the users

The stakeholders of a more formal project will inevitably include Project Managers, Champions, Business Analysts, Testers, Developers, oh, and Users. We’ll dispense with everyone except the Users.

I’d like to build a solution which pictures three groups of people:

Learners

These people sign up to learn a language, expressing interest in learning and specifying their level of skill, comfort and preferred method of communication. These people cannot be expected to be IT literate and should be able to express their interest as friction-free as possible.

Ideal interface: Power Pages, which offers a web-based registration interface, feeding into the shared Dataverse database.

Mentors

Mentors can register as being available to mentor one or more learner through their chosen language, considering their level of skill and comfort in the language. These people could be expected to be slightly more IT literate and may require a one-stop-shop for multiple mentoring opportunities.

Ideal interface: Canvas App, which offers a simple dashboard-style interface capable of interacting with the shared Dataverse database.

Administrator

The Administrator brings together learners with mentors, creating matches/pairs following payment by the Learner. These users could be expected to be able to use a more powerful interface, requiring access to enhanced functionality and reporting.

Ideal interface: Model-driven app, which offers a comprehensive interface into the Dataverse and provides numerous editing and reporting opportunities.

Performance

Performance of the solution must be measurable to allow objective determinations to be made, but we should consider the emotional aspect of performance.

• The solution should return responses within three seconds in all cases where network connectivity allows.
• Where connectivity is unavailable, a managed experience must be created, avoiding unexpected behaviour.

As a learning exercise, I’m going to dispense with requirements around disaster recovery and resilience. If this was for real, you’d need to consider SLAs and how many ‘9’s can be delivered in uptime. Since we’re working on Microsoft’s Power Platform, we can hide behind their statistics.

Security

Security must be a concern from the outset of a project and working with Microsoft’s Power Platform has the benefit that we can avoid many of the low-level security concerns such as security of data at rest or in flight.

That is not to say we’re entirely without responsibility. We will still be subject to legal and regulatory obligations such as GDPR.

• Data must be stored securely and access to the data restricted to known individuals or service accounts.
• Opportunity for exporting or other methods of egress of data must be restricted to only immediately related data or aggregated through reporting.
• Governance of data and its transit must be maintained to ensure it can be assumed that there is no data leakage and data we hold is accurate.

Cost

This is simple. It has to be free.

As a learning exercise, there are options to getting hold of a usable environment for Power Platform but there are restrictions to consider. Or, you can create your own Environment in an existing Power Platform tenant with the knowledge that that Environment or its contents will never make it to Production.

What will the solution not do?

Just as important as what the solution will do is what will it not do – and defining those expectations from the start.

• Application Lifecycle Management (ALM) will not be used. Nor will Software Source Control (SCC). Power Platform’s implementation of SCC is really not good and implementing this, alongside wider ALM techniques such as testing and project management, would distract us.

More in this series

As I go through this, there are more posts which I’ve created.