What's In a Name?

IT access and governance projects in recent years have tended to be technical in their nature.  This is not a particularly surprising, or indeed negative comment.  Many access related initiatives have been driven around provisioning (automating the C(reate) R(ead) U(pdate) D(elete) process for joiners and leavers) or focussing on S(ingle) S(ign) O(n) initiatives to help reduce password mis-management.

The procurement of such solutions normally involves a product component and the obligatory services component.  The product selection has generally been done using scoring matrices, technical comparisons, bench marking and functionality matching.  The services part is generally done on an agreed set of deliverables, man days, costings and project frameworks.  All fine and dandy.  In a technical land, a spade is a spade as the saying goes.  Can your product talk over LDAP?  Does it have an SPML API?  Can I connect to a database using JDBC?  Can it be load balanced?  Are passwords encrypted using a hash?  Etc etc.  All very black and white questions and answers once you overcome the sales patter!

However as the hype cycle increases (or dies down depending on your view point) an increasing number of solutions now require more focus on the business drivers and components of access governance.  Here we refer to items such as G(overnance), R(isk) and C(ompliance), Identity Compliance, Audit Controls and so on.  The business part of an organisation (any non-IT silo which actually makes money for the shareholders instead of spending it) is now driving the access governance initiatives.  They have the budget and the accountability to design projects that require a mixture of new technology and services to allow either compliance, process adoption or improved accountability for things like access control, access requests or access sign off.

With this comes several new consultancy and delivery challenges.  Not only the technology but also for a basic issue like naming standards!  Business personnel take a different view on technology.  Technical terms are used in a different context.  They mean different things.  Take a role as an example.  In standard I(dentity) & A(ccess) Management speak, this would be a grouping of entitlements.  But what about Business Roles?  Applications roles?  Enterprise Roles?   HR Roles?  Auxiliary Roles?  Exception Roles..... and on and on.  Each could arguably have a distinct definition of their own, but equally could be used interchangeably by both the business and IT departments.  What about attestation?  Is that different to certification?  And is certification different to workflow approval?  It must be it's the same people involved right?  Possibly not!  

Auditors, business managers and IT implementers will use the different terms interchangeably whilst referring to different objectives using the same terms.  Confused?!

A major component of any governance project is obviously the tools and services chosen, but time must also be spent on the basics, such as consistent naming.  This will allow better monitoring, transparency and ultimately better delivery of governance related objectives.