Phased deployment and secure collaboration in Aperture Data Studio v1 versus v2
In Aperture Data Studio v1, there isn’t an effective way to compartmentalize objects such as datasets and workflows to allow phased development, testing, rollout and rollback in case of any issues. You also do not have granular control over what you choose to share with other users or define what each user can do. This might work for a simple, straightforward scenario, but in most cases, it may not suffice.
Challenges observed and limitations you might have with remaining in v1:
- All the work you do in Data Studio happens within a single instance or environment.
- Every user uploads their own copy of a set of data or set up their own data sources even though they may be exactly the same as that of every other user. There is no option to share the data.
- Workflows are either shared or not shared. When a workflow is shared, it is only for execution and not for editing or working collectively on the design, when the workflow is shared it is shared with everyone.
- Consumer, Designer and Developer, Administrator roles all have access to the Data Explorer, Workflow Designer, Monitoring and Execute Workflow capabilities. These roles and their permissions cannot be edited. There isn’t any option for creating a custom role with selected permissions.
- You can export one or more workflows so that it can be imported and used by another user without sharing the workflows with all users. However, the datasets used by each of the workflows will have to configured again for the new user.
Depending on your scenario or use cases, there are a few workarounds you are probably using to get by, for example:
- Deploy several instances of Aperture Data Studio, each on a different machine. This may not be the best use of resources, depending on how many phases or compartments you require.
- Create copies of the datasets and workflows you are working with within a single Aperture Data Studio instance.This may not be easy to maintain and is not the recommended best practice for software development.
- Use a common username for everyone. Again, not a secure and best practice as it makes audit and change management difficult.
With Aperture Data Studio v2 we’ve introduced several new concepts that promote best practices for phased deployment with better control and more capabilities to be able to manage and share objects in a secure way.
Environments allow you to create multiple compartments within a single Aperture Data Studio deployment.
Hardware, license, system settings and users are shared across environments. However, objects such as datasets or workflows are entirely segregated and not shared across the environments.
The superadmin (administrator user) has the rights to manage all environments and would need to explicitly grant other users the permission to access an environment as required.
Objects can be exported from one environment and brought into another, for example, in the case where you are ready to promote the objects from a test environment to a live environment.
Spaces allows you to segment Data Studio content. A default space is provided for each user. You can optionally create one or more new spaces and give other user(s) access to those spaces. Think of using spaces to organize content for different projects, use cases or teams.
Views is a powerful way to apply a set of operations or sequence of transformations to a single source table of data where the resulting data can then be shared purposefully, for example:
- You may want to create a View of your customer data with the Personally Identifiable Information (PII) obfuscated, allowing you to share customer information with other teams securely.
- You may want to create a View of your customer data quality issues segregated by regions, allowing you to share targeted content with other teams for their further action.
Reusable Functions are collections of logic that can be used in multiple places. What we are calling Functions in v2 include what we’ve previously referred to as Expressions, Business Constants, and Business Rules in v1.
Once a function is defined, you can select a subset of the nodes and choose to extract them into a reusable function. This ‘custom’ function can then be used everywhere in the Space, as if it was one of the built-in functions. If you want the function to be usable in other Spaces, you can opt to share it with all Spaces or export and import it to other environments and installations.
Publication and Versioning is a lightweight mechanism for distinguishing between ‘work in progress’ and ‘finalized’ versions of Workflows, Views, and Functions.
The intention with publishing is to allow users to iterate on a Workflow design in a controlled way, including introducing temporary breakages, without impacting day-to-day operational processes.
Export Packages are a collection of objects to be moved from one space and environment to another. The user interface will guide you in the creation of packages, by allowing you to specify a number of objects to include for example, Workflows, Views, or Dataset definitions, and it will automatically identify and highlight any dependencies that you may want to include.
Roles and permission-based Capabilities are more flexible in v2 as they are in v1. In v1, there are three fixed roles (Consumer, Designer and Developer, Administrator), in v2, you will be able to edit these default roles, and create new ones.
Each Role is associated with a list of capabilities, which define what actions users in each Role can perform, for example, Create User, Create and Edit Workflows & etc. Configuration for the roles and associated capabilities will be exposed via a Permission matrix, so administrators can turn on and off capabilities for each Role easily.
Consumer Access allow users access to reports as quickly and directly as possible from the homepage. Reports can consist of a combination of grids and charts. Users do not have to be overwhelmed with understanding or looking for the appropriate workflows to execute. When users view a report, the workflow executes automatically behind the scenes.
Object-Level Permissions allows you to restrict access to a specific set of users. For example, when you have a dataset sourced from an external system, the external system can be associated with sets of credentials (username/password), so different users within a space can connect to external systems with different logins.
For more detail information on these concepts, head over to our documentation site.
Improvements to security and collaboration are a key area of focus for Aperture Data Studio v2. What other enhancements would you like to see?