Days Six & Seven.
The weekend is here! The core code is complete and things are coming together – now just a case of going through the fairly epic list of wrap-up tasks (read more about the challenge here).
Leon M (Commercial Lead & Project Co-Conspirator)
Ahem, I feel like we need a soundtrack for this post.
Adam C (Architect & Project Lead):
Go for it.
That’s better. Right, where are we?
Technical debt also hit us really hard with this challenge.
There were lots of things we needed to automate, and when the week started I thought we could go to the portal, get the API endpoints and power through them…. Sadly that was not even close to reality. Nearly half of the API end-points we needed had to be created this week purely because the legacy portal was poorly architected before. Again, a problem of the past because the new platform would not do this – in fact the team would kill me if I suggested it 🙂
- Easier way of getting inside a tag in the description by “name”
- Inputs currently will only go at the bottom of the task rather than being able to place them where we want
- Inputs can have Required, default values and simple regex conditions. This would minimise the amount of code required on each task just to check for basic conditions
- Currently we only support a single connection to Microsoft 365 and IAM Cloud API. Although IAM Cloud API duplication is not needed, it would be useful to automatically create new instances of the MSGraph class so two different tasks can talk to two different Microsoft 365 tenancies.
- If a task fails, have the ability to auto continue so the user is not interrupted. This is useful if the task is doing a loop of some kind and you want to log an error but not cause a fatal error.
- Allow a GCR task to be assigned to the licence key as a conditional load. This would allow the application to behave differently based on conditions and allow the tasks to be tagged to conditionally to the output.
- Adding a menu to the desktop application will allow the user to navigate around easier and allow us to use the app for things like installs by providing a default menu. The menu will support a two tier system and will present themselves as big buttons (similar to the tasks) that are clickable. It will also be used to populate the menu on the top right.
- Large configs caused the UI to hand for a second or two so we want to make the config loading an async process just to improve the UI
- Licence Keys will only be applied under menu items – this is so we can licence different configurations within a single application
- Prevent a future task from being able to manually be run as an option on the task. This will prevent users from being able to process tasks out of order if they were clicking around
- Auto scroll – when there are many tasks you need to manually scroll down. Instead the scroll bar should also be places to the top of the previous task to give plenty of UI space to see what is going on
- Integrate with Global Code Repository – this will allows us to easily update tasks code and the client will re-pull automatically and will also simplify deployment and accessibility
- Logging – currently each task is responsible for its own logging but it already has a centralised logging mechanism which brings it through to the UI so we can use this to also write to text file if the setting is on
- Logging – Process->Process, this is a further improvement to the above but this will allow other applications that the framework kicks off to also route back so other apps can report back to the UI and the centralised logging
- Prevent the default images from appear and saving in the task as it bloats the configuration when patching
- When the next task completes successfully get the task to wait 3 seconds before moving to next task (config based in global settings)
- Once the logging framework has the process->process built in we will be able to have the migration service report back exact updates and files being processed in real time
- Auto install the migration utilities to remove the demand for it to be included in the initial download (important for when this utility is used for non Cloud Winch jobs)
- Add the ability for when selecting users to migrate it can be done in a TreeView mode where it will render AD into an easy and searchable manner and automatically update the selected users
Me too. You guys rocked it. 🙂
Commercially speaking, we’re good to go. The website updates are complete. We’ve come up with some initial pricing scales. I will likely review these again in time. Take a look at the live page here, click the pic:
My final step is coming up with some post-launch tasks, which will help guide the next few months. Here are my main to-dos:
- Create a simple demo video of Cloud Winch to share with partners and prospective customers
- Organize a webinar for IAM Cloud Partners
- Evaluate pricing, potentially coming up with two separate pricing streams for IAM Cloud-hosted vs Customer-hosted migrations
- Create a Cloud Winch PDF whitepaper
- Hopefully get some nice positive testimonials from early customers
- Gather feedback from customers and partners, see if there are any suggestions for improvement we can use to refine how it works, add some useful extra functionality.
Beyond what’s listed above, it is our goal to expand Cloud Winch from Home Drive -> OneDrive to also support Network Shares -> SharePoint/Teams. So I need to think about the way that impacts our marketing messaging and pricing as well.
But there you go. A New Product in a Week. An MVP for sure, and lots of exciting improvements planned for it over the next few weeks, but right now we have something can do exactly what it says it can do, and do it well.
Hope this exercise has been interesting to follow. I think I will create a more reader-friendly one-page summary in the next week or so just to cap off the challenge. But for now, we’re off to go and try to winch up some customers. Thanks for reading!