|
Over the past year, AVAware’s development team has been developing a number of exciting new technologies that will dramatically change the way users are able to manage and deploy applications such as AVAproject, AVAcad and Fusion throughout their companies. The first of these technologies, and one on which many of the others will be based, is cloud-based user account management.
While the serial numbers that each user’s key contains also serve to identify them as “company users”, in order to provide permissions and data tracking on a user level, it is necessary to be able to identify individual users across the enterprise. Traditionally this is managed through network servers that are located in some central office and connected to using a VPN-type connection. Although this does get the job done, there are two major problems with this approach. First of all, users are forced to maintain a constant connection to the head office server. Without a constant VPN connection, users lose access to their data and in most cases their application as well. The second issue is obviously ‘fault tolerance’; not only does the user need a good connection on their end, but central server must be up and running with its own incoming connections in good working order. If any one of these components fails... employees get an unexpected holiday.
AVAware has taken a truly innovative approach to this task, by managing the user accounts – complete with permissions – in the cloud. Users can “log in” to AVAproject from anywhere that has an internet connection, and best of all – that connection does not have to be maintained constantly!
Let’s take it back a step...
User accounts are set up using a web interface that is accessible through the client portal on the AVAware website. A company’s system administrator sets up accounts for users, identifying them with their email addresses. The management system automatically deploys an email to each user and asks them to validate their account – the same way one would with services such as Google, Twitter or Facebook. Once ‘validated’, the user can log into the AVAware website using their individual credentials instead of using the one assigned to the company. The immediate benefit is that system admins may now restrict specific functions of the client portal for any given individual.
The same functionality that is offered to manage access to the website also extends to the application software. When a company has enabled ‘user logins’ (via the web management system), their users are asked to “log in” to AVAproject when they launch the software. Just as they would with the website, users identify themselves using their email address. (There is even a convenience feature that allows them to forego typing in the part after the ‘@’ every time they log in).
The application then validates their account by accessing the cloud server and downloads their individual “permission” set. At that point, the internet becomes unnecessary and everything continues to operate locally – just as always. At the discretion of the system administrator, users could even be allowed a number of logins without an internet connection – for those users that need to work on remote locations or on airplanes, etc. It truly offers companies all the management functionality of a network – while preserving the flexibility found in remote applications.
The user accounts have a number of other interesting features; the most notable is the ability for a company to designate logins as “optional”. This is a feature that is never found in traditional network environments; in fact the closest thing it can be compared to is a Google account on the web. Users accessing any of Google’s services (ie: search, maps, YouTube, etc.) can certainly make use of those services without ever “logging in” to any of them. However, they are given the opportunity to create and “login” with their “Google account” (top-right corner of browser windows). Should they elect to do so, the functionality of each of the services is greatly enhanced; search results, for example, are refined through the use of “signals” from your social graph while maps and YouTube allow you to keep lists of favorites, subscriptions and histories.
AVAware’s optional login works in much the same way. At the discretion of the system administrator, certain functions can be restricted to specific users –only when they login to identify themselves. The ability to update software, download catalogs or share data on the company network are examples of these types of functions.
When “optional” logins are selected, users will see a new toolbar (depicted to the left) that offers them the ability to login and logout of the system with their credentials as required.
The ability to identify and manage individual users – especially remote ones – opens the door to a number of exciting new features:
User Activity & Usage Tracking
A reporting system can be established that would allow company management to view logs of each time the software was accessed by any given individual. Such tracking could also include location information and a summary of the project files that were accessed during that session. It would be possible to produce highly precise and granular pivot tables that reflected software usage and time spent on any given project throughout its life cycle – regardless of the physical location of the users.
Software Access Control
As is often done with network-based software, a permission set can be established and linked to each individual user account. This would allow management to restrict certain software features and functions for specific users. For example, hardware estimators could be prevented from door/frame related changes and operations. Most likely, highly sensitive operations (ie: file exports, ERP integration) would be restricted to only those users that require access to them.
Project File Encryption & Access Control
A really exciting new possibility is in the area of project file security. Even in a traditional network environment, all the security measures that are in place become meaningless the moment the file leaves the protective confines of the server. By encrypting the project files themselves and encoding them with key/user information, it would be possible to create files that can’t be opening by anyone that is not specifically authorized to do so. For example, files can be locked to open only for select users, or those that know a set password. As a system default, all projects could be encoded such that they would only open in the presence of a company-owned AVAware key. That would prevent outside parties from accessing data contained within a project file even if they had their own copy of AVAproject available.
Automatic Project Change Tracking
In addition to basic user tracking information, the system could be setup to automatically track changes performed to a given project file as well as which user is responsible for making those changes. In fact, the system could track each time a user opens a file – or perhaps any time they export the data to another file format.
This list of possibilities goes on and on. There are many more use cases and potential applications that weren’t listed here, some of which will be launched throughout this coming year. It is the hope of the development team to introduce major new features with each coming software release.
The ability to create individual user accounts is available to all AVAware users immediately. The feature will be enabled “by default” in the client web portal in the next few months. In the interim, those wanting to get started immediately need only contact technical support to have the feature enabled.
|
