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.
Leon M:
😉
Leon M:
That’s better. Right, where are we?
Adam C:
Ok, so, in full transparency it did require some effort over the weekend and a tiny amount of Monday to complete this challenge. But hey, a week + a few hours is still pretty great going for a completely new production-ready migration tool.
By Friday we had a working prototype. But it was missing some important components, including the license implementation and testing.
In the end the license implementation was fairly easy, we lifted the same encryption algorithms we created for Cloud Drive Mapper which meant we didn’t have any logic issues or worry about any code security elements. However CDM doesn’t use the API to get the information and instead gets it back via a SOAP response from our auth service (for a number of legitimate reasons). But for Cloud Winch, it didn’t make sense to do that, it was much better instead for us to implement the relevant API endpoints. Although by Friday most of the endpoints on the API were implemented we had still not plugged it into the UI tool or put it through its paces.
Although there were a few tweaks needed, it took about 6 hours to implement it into the tool. At the beginning of this challenge, the client framework was really basic so we had no license/trial mechanisms in it what so ever.
The other thing we found on Friday was a bit of a floor with the trial logic in that we needed to restrict the number of users capable of using it. This is actually what took the most time to do (along with automatically adding an API service account for the licence key).
As we discussed on the video on Friday, we have now successfully got everything implemented. I took the role of tester and so was making sure that all the dots connected, relayed to the team changes that were needed and validated the software did exactly what it should. I am really proud to say it did, yes it did take half a day longer that the fact we achieved it at all is kind of amazing.
Take aways
I mentioned in a previous blog post how quickly we noticed the deficit of knowledge transfer within the team. The challenge would have been a lot easier if we’d spent more time ahead of the challenge making sure team members had a broader knowledge of our technology.
Although this is something I will be more conscious of moving forwards, I might also argue there are some legitimate reasons for not wanting new hires to spend a lot of time with our complex legacy technology when they can be spending more effort pushing our new technology platforms forwards.
However, on all new code and platforms I absolutely will arrange half a day a week for cross-team learning and code swapping to ensure our developers are more familiar with areas they might not deal with day-to-day.
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 🙂
One of the best things for me during this week is how much progress we made on the framework we used for the desktop application. We have turned what was just beyond a POC framework into a really powerful utility that we can use for almost everything. The more we developed the tasks, the more it pushed the framework and now I have almost two pages of notes which I will document on cool stuff I want to add to the framework which would help speed up development to provide better UI interactions.
The last a final point in this section is that I also enjoyed how easy it was to add a new application into our Lift & Shift product range, we completed the work to migrate files from on-premises in 9 hours effort which is pretty incredible. I calculated 45% of our effort this week was on the new framework, 35% was what I consider technical debt (mainly missing API endpoints) and the remainder on the tasks. This is really promising for the next project we want to undertake (Surpass).
The possibilities of the new framework are genuinely endless. It’s going to help us automate all kinds of tasks especially around the onboarding process.
While this challenge forced the evolution of the onboarding process for Cloud Winch to make it fully automated. The onboarding process shares most of its steps with our other products including Simple Sign-On, Lift&Shift, Surpass and IDx. So development on one product has just helped us take massive steps forward on the onboarding process of nearly our entire product catalogue. And we even have some pretty exciting ideas for how this new client could be used to make Cloud Drive Mapper deployments easier too.
Next to do
Well, I will break this into two sections because I cannot wait to explain what I want to do with the desktop framework.
The framework as I said came a long way during this little project but with very little time we can increase the usability, speed of development and how the users can use it to really accelerate future development – so here is an idea of our backlog for it:
Development Usability
- 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.
User Improvements
- 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
Important Updates
- 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)
Specific to Cloud Winch
- 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
In summary this has been a really enjoyable week, challenging but really insightful. It has been great to see what we were capable of and I am proud of the team achieving what we did.
Leon M:
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!
