Insights: the Aveksa Blog

Today, all of us Aveksa are pleased to announce a new product offering, Access Fulfillment Express™ (which we affectionately refer to as AFX). We’ve designed and built this product to address what we see as a clear need within our customer base, and in the Identity Management industry in general – a way to eliminate the cost, complexity, and frustration typically associated with provisioning implementations.   Talking to customers, analysts, and other influencers, we’ve seen this frustration, and believe that the fundamental problem is that typical provisioning systems intermingle business logic and integration logic, and rely on a coding-centric implementation approach.

The result is that implementations take on the negative characteristics of point-to-point integration projects, where business policies (such as who should have access to what) are implemented at the same architectural layer, and with the same language, as integration mechanics (such as the mapping of a message to a set of application API calls).  We believe differently — that the business logic belongs at the access governance layer – it’s the only place with full identity context, with the ability to define rules and processes that are applicable to business users, and is independent of the technology and mechanics of target systems. And, that such systems should avoid the need for custom coding, and instead provide a configuration-centric solution.

Consider, for instance, the creation of a rule that controls the approval process for a user’s request for application access.  This rule should be able to take into consideration attributes of the requested entitlement (such as its sensitivity), attributes of the requesting person (department, role),  and full identity context (what other entitlements does this person have, and will this new one violate any SoD policies?).  This rule should not be in any way connected to how the system integrates with the target application (which after all can and likely will change over time), and should definitely not be hard-coded in a programming language (thus requiring a software engineering cycle to make even minor adjustments).

The integration layer of AFX is based on a loosely-coupled, open approach – using a well-establish communication architecture, the Enterprise Service Bus (ESB).  By leveraging an open source ESB, and by publishing both the message format and source code for the adapters used with AFX, enterprises can embrace AFX with full confidence in the solution’s extensibility and flexibility, without fear of investing in a proprietary, closed architecture.

In short, we believe that the combination of cleanly separating business logic from integration logic, and leveraging an open integration platform, will provide enterprises with the reduced costs and improved efficiency that they’ve been asking for. We’ll be writing more about AFX over the coming months, and look forward to discussing it with you.