Skip to Main Content

Reimagining SailPoint UI

Changing the web face of a SAAS product can be an arduous process. In SailPoint’s case, we had to remove our legacy tech debt, define the new UX vision, and build a foundation that glues the UX vision to the UI implementation. Today, the last of the IdentityNow AngularJS code has been migrated to Angular 7. We’ve created a design guide to articulate the UX vision and built a new UI component library, codenamed Armada, based on that vision. This upgrade brings a fresh user experience and has helped to usher in a bevy of new features in IdentityNow like the end-user Dashboard, the Dynamic Discovery Engine, and our new Password Reset Experience.

A page from the demonstration application for Armada.

Since the summer of 2017, the IdentityNow UI team has been working on the shared UI library in tandem with the Angular migration and new feature work. When Armada was first started, IdentityNow was the only consumer. Now there are three SailPoint projects using it: IdentityNow, IdentityAI, and File Access Manager.

UX designers will tell you, good UI does not always equal good UX. Armada helps to bring a clean and consistent experience to SailPoint, steered by the Armada Design Guide.

A page from the Armada Design Guide.

The Design Guide is an internal design system providing both the vision and the standards for Armada’s implementation. Things like our color palette, typography, spacing, interaction standards, along with a whole host of atomic components. The design guide provides an aspirational vision for what a SailPoint UI can be, while Armada is a concrete implementation of that vision in Angular.

Armada is engineering-lead from the bottom up. That means engineers, not product managers, decide what should go into Armada and what should be left out. It’s up to individual UI engineers working together to make the best technical decisions and to reflect on whether a component is ready to be elevated into Armada for re-use across the company. To help organize this process we host bi-weekly meetings with UI engineers from other projects to discuss what is being worked on and coordinate our efforts.

Armada Core Principles

There are several core principles that we’ve defined for Armada. These help guide us when conflicts arise, whether they are regarding technical implementations or determining if the code even belongs in Armada.

  1. Available; not mandated
  2. Generalized modules
  3. Documented and demonstrated
  4. Automated testing
  5. Shared destiny

These principals were created by the Engineering team and have tangible effects – they aren’t some pie in the sky statement about how we feel about Armada.

Available; not mandated

Armada as a project is available for projects to use and is not mandated or a requirement for other projects.

The goal is to enhance, not to shackle. An awesome side effect of Armada was the adoption of it by other internal projects, even on teams that have no interaction with Armada in their normal day-to-day work. They made the decision on their own that Armada made their job easier.

Generalized modules

Armada’s goal is to produce generalized modules that are to be re-used by other projects. The modules should be flexible to as many different scenarios as possible.

Angular lends itself well to extending basic component implementations to support more specific situations in the various projects. We build with the plan to be extensible to future features and cross-cutting concerns such as accessibility, right to left languages, and browser compatibility.

Documented and demonstrated

All Armada modules have TypeDoc documentation for public APIs along with a live demonstration of the unreleased to facilitate effective communication between engineers, UX designers, and product managers.

Part of advocating for a UI library is making it easy for others to find what’s in it and how to use the tools in it. An example of this in action is the TypeDoc generated JSON that is piped into the live demo app. This helps to reduce the amount of time developers spend writing documentation because we reuse the docs that are already available in the demo app.

Automated testing

Armada relies entirely on automated testing with zero manual tests. All tests are run on every single pull request automatically by the Pull Request Builder, and all tests must always be passing. The master branch is expected to be production ready at all times.

We have very high testing standards for Armada. Any extra time spent in fixing flaky protractor tests or writing those extra unit tests saves us from the bugs we might have later on. Armada’s thorough testing gives us confidence that we aren’t breaking the consuming projects. I also sleep better at night.

Shared destiny

Armada’s destiny is shared between multiple projects. Together all UI engineers involved own the destiny of Armada’s future direction.

This means that Armada operates like an internal open source project. Teams from projects contribute what they think is useful, but it’s a shared responsibility to support it. One example was when the File Access Manager UI team built a table component they needed and then migrated it into Armada. The IdentityNow engineers have plans to incorporate it into the Dynamic Discovery Engine and in a new Certifications experience. Go team!

Up Next

This post introduces you to Armada. We have other Armada blogs planned that will take a deeper technical dive into some of our favorite topics. We hope you’ll stay tuned for the next voyage with Armada!


Discussion