For consultants, one of the most important KPIs is reporting billable/project hours. Back when many of us at Predica today worked at Microsoft Services, we had to use a tool called Change Point. This application was not very user-friendly, and reporting rules made it worse.
Predica has a similar profile to Microsoft Services – we deliver technology consulting, and many business rules are the same, including tracking billable hours. At Predica, we knew that it could be done simpler – that is how LeanTS was born. It is the easiest time tracking application I‘ve ever used. Greg, our CEO, wrote a nice business article about how important time really is to a company and how LeanTS can make better use of it.
I would like to give you a technical overview of our tool, and it’s history – how it evolved from the on-premise application to Azure App, to end as a Multi-Tenant Cloud system.
As I mentioned, our experience taught us about time-tracking application bad practices. Here at Predica, we had simple and clear requirements:
- Time tracking should be simple and quick.
- Time tracking should be enabled without an internet connection.
- Ideally, time tracking should be integrated with a personal calendar.
We decided to use the personal user calendar as a way of entering data. Using Outlook you can even do this offline. Now you can manage and plan your work using a single application.
Here’s how it works:
- The user enters information about what he did during the day.
- It’s read from their corporate calendar and saved in the database by sync engine. For example, we validate if item title is right.
- Data is aggregated and analyzed in the database.
- The user can see how much time he reported in each project or category.
It’s hard to believe, but a long time ago we used Google Apps. Then our LeanTS was simple. We had a virtual machine with console application and database. For reports, we used a simple Excel with a pivot table.
Take a look at the diagram below.
LeanTS moves to Microsoft Cloud
Our goal is to focus on Microsoft technologies so we migrated from Google Apps to Office 365. We rebuilt LeanTS and migrate to Azure. This is the version we use at Predica.
As our company grew, we needed to change reporting and flexibility. We added analytics database to the architecture to quickly generate standard reports and aggregate data.
For calendar sync, we used EWS Managed API. There was no other option at that time, and a lot of complications with the configuration are the result of using this API. For example, we must set permission for each mailbox that is read by the sync component.
Along the way, we added some features that required write access to calendars. If we find an entry that doesn’t match the rules, we mark it with the proper category.
From a deployment and maintenance perspective, this architecture is still a typical Enterprise Application. You need to configure the specific account, set up security and calendar access, set up all the infrastructure, etc. This is, of course, only part of our environment landscape. I plan to write more about our systems so stay tuned!
LeanTS goes SaaS
We believe our approach to time reporting is unique and adds value for other organizations. That’s why we created a Software as a Service (SaaS) version.
SaaS is a model of delivering software to customers. A great example is Office 365. Microsoft charges a monthly fee for each user and gives them access to their software and services. You can ask for 100, 1,000 or 100,000 mailboxes for your employees. It’s up to the provider to scale and manage the service. This allows for greater flexibility for the organization.
We had to redesign the whole architecture of LeanTS to make it a product and make deployment and onboarding as easy as possible.
The first step in changing the solution was designing new architecture. We had to plan for multitenancy and data separation.
New architecture components
- Exchange Online – a source of calendar entries that we sync to a database.
- Project Online – a source of project information (ETA, active/inactive).
- Power BI – data visualization component. One can connect data in LeanTS using Power BI service.
- Web application – a portal for application configuration, eg. creating projects, etc. Alternatively, you can use Project Online.
- Web Job – our sync engine that gets information from Exchange Online and Project online. Uses Web API component to write and read data from DB.
- Web API – the heart of LeanTS. Exposes all APIs required for application to run.
- Databases – Azure SQL databases store all information. Every customer has a separate database under the hood.
Originally we had only one database. When designing Multi-Tenancy you must ensure that each customer can access only his data. You can achieve this in a few ways:
- Separate database
- Shared Database, Separate Schemas
- Shared Database, Shared Schema
We opted for the Separate Databases approach to ensure the greatest level of separation. The customer can also get read-only permission directly to his DB. For now, we allow it, but we will decide in future if we require a proxy API.
To simplify the sync and configuration process, we had to rewrite the whole backend. As I mentioned, we used EWS Managed API, but Microsoft provided us with Microsoft Graph.
You can use Microsoft Graph to build apps for organizations and consumers that connect to a wealth of resources, relationships, and intelligence, all through a single endpoint.
Graph solved many problems compared to EWS Managed API:
- Easier configuration of permissions (we don’t have to assign permissions per mailbox).
- We have access to more information, and there’s one endpoint for accessing all cloud services (can be useful in the future).
- Easier and quicker customer onboarding (due to simpler application configuration).
- One place for editing permission by administrator (in Azure dashboard).
When creating multi-tenant apps, other parties need to trust your application. For example, when you install/trust LeanTS to read data from your calendars.
Azure AD’s consent framework makes it easy to develop multi-tenant web and native client applications that need to access web APIs secured by an Azure AD tenant, different from the one where the client application is registered. These web APIs include the Microsoft Graph API (to access Azure Active Directory, Intune, and services in Office 365) and other Microsoft services APIs, in addition to your own web APIs. The framework is based on a user or an administrator giving consent to an application that asks to be registered in their directory, which may involve accessing directory data.
For example, if a web client application needs to read calendar information about the user from Office 365, that user will be required to consent to the client application. After consent is given, the client application will be able to call the Microsoft Graph API on behalf of the user and use the calendar information as needed. The Microsoft Graph API provides access to data in Office 365 (like calendars and messages from Exchange, sites and lists from SharePoint, documents from OneDrive, notebooks from OneNote, tasks from Planner, workbooks from Excel, etc.), as well as users and groups from Azure AD and other data objects from more Microsoft cloud services.
This allowed us get rid of a service account and complicated permission setup. Now you have a simple window with permission settings for the whole application. You can also easily change the setup.
I believe this gives you a nice high-level architecture overview of the most important application at Predica. Our journey taught us a lot about Azure and application optimization. From a technical perspective, if you are making Azure or Office 365 applications look to Microsoft Graph and Consent Framework.
If you want to know more about LeanTS or any other component in our environment just leave a comment below or contact me directly.