Finding the Right IAM/IdM Business Systems Analyst (BA / BSA)

Q4 2013 Update:
It’s been a long while since this post was updated. I originally posted it back, …er…well a long time ago. (Early 2007?) Why the flashback? Well, much has happened — and not happened since then. What hasn’t happened? Any major reason to change the article. Yep, if anything, it’s even more relevant today.

Recently, I’ve been working with several clients to hire in business analysts (BA), also known as business systems analysts (BSA). In building the requirements and job requisitions, the focus has been too generic. The major disconnect many businesses still continue to have is that a good BA is a good BA. On a base level that’s true, but what isn’t true is that a good BA = a good Identity Access Management (IAM / IdM) BA. HUGE difference. In fact, the skills comprising a good Identity BA are cumulative and additive.

Since I’ve returned to active consulting in recent months, I find myself sending this article out to new and existing clients. It seemed like a great time to refresh it a bit and re-post it here. There are very few changes, most notably standardization on the acronym “BA” instead of “BSA”. The industry uses both terms heavily, but our more recent clients are using “BA” for “business analyst”. So “BA” it is.

Be sure to read through to the end and add your own comments and observations about hiring and managing Identity BAs. Now, I return you to the article below…

 

Hello Everyone:

A topic that comes up quite often — and rightly so — is the role of Business Systems Analyst (BSA or BA) within an Identity Access Management (IAM) Program. What is the right mix of skills? How much of the hiring decision should be weighted toward business acumen, light development (XML, web forms, etc.), and requirements management? How necessary are they? Can our IAM software vendor fill that role?

In short, the answer depends on your IAM Program, scope, organizational composition. Before I post a sample job description, some background is in order. First, an Identity BA is not like the traditional BA. A traditional BA works more closely with the various lines of business to determine which each business needs, what it is currently doing, what it wants to be doing in the future, and other factors as required by the stakeholders.

With all relevant information collected, the BA then collates the information, separating actual requirements from wish list, and subjective preferences. A process of collating, editing, synthesizing the core elements continues until business requirements, and functional requirements have been collected, refined, and organized. Once requirements are categorized, prioritized, agreed, and published, the BA hands the list off to the development or program team for development and implementation. (In the interest of time, I am glossing over many pieces of the process.)

Where the traditional BA model breaks in the Identity World, is that now the developers themselves are stakeholders, often with dramatically needs from one another. Application teams have their own requirements for integrating their applications within an Identity Access Management system or for consuming its services. Each individual application (which can number into the hundreds or even thousands for very large organizations,) requires its own analysis and requirements gathering project. The Identity BA must address all requirements, of all audiences.

In short, the Identity BA adds the dimension of detailed developer (and general Identity Management) knowledge to the level that he or she can do some light development work, especially in the area of Business Process Management (BPM). What is vital, is that the Identity BA can:

• Collect all information
• Extract actual requirements from subjective wish lists and “nice to haves”
• Get stakeholder acceptance on just about everything
• Synthesize Business Requirements from the whole
• Derive Functional Requirements from Business Requirements
• Document workflows and process in a visual model
• Document future state (“to be”) workflows in a visual model
• Derive User Acceptance Tests (UAT) from the Functional Tests
• Translate future state workflows into executable business process.
• And much more…

Sounds like a tough role to fill? It is. Compound the difficulty by the fact that really large Identity Programs may need several. To help ease the process, I am including a sample Identity BA job description. The usual disclaimers apply – it is not comprehensive for all possible situations, and your mileage will vary. However, when used effectively as a guideline, the list can greatly facilitate the hiring, placement, and effectiveness of this very crucial resource.

SAMPLE Identity BA Job Description

The goal for this position is to hire a person that is well-versed in both
business and functional requirements gathering. This is an exciting and
dynamic opportunity to work with key business units, developers, vendors,
and security analysts and help shape the future of our Identity and Access
Management (IAM) Program.

Duties Include

Collect application security requirements from internal developers
and external providers

Frequent meetings with stakeholders and IAM Program Team members

Collect business requirements from key business stakeholders

Validate all requirements, and separate key business requirements
from application wish lists

Translate business requirements into functional requirements

Translate functional requirements into Use Cases (UAT)

Maintain project requirements database

Maintain project UAT database

Create visual models of current "as-is" workflows (individual business
processes)

Create visual models of future state "to be" workflows

Assist in the translation of visual diagrams to XML as needed

Assist in the verification of IAM Product Change Orders

Minimum Requirements

3+ years as a BSA with at least one large (5000+ user) organization

Excellent written, verbal, chat, and email communications

Strong familiarity with IT Architecture concepts

Expert-level diagramming (Visio / Dia / UML)

Good familiarity with Project Management Methodology

Strong familiarity with Relational Database (RDMS) systems. (Not a
DBA, but comfortable with data structures.)

Good working knowledge of Internet security concepts and web
application architecture

Ability to meet deadlines in continually changing environment
Excellent prioritization

Strong self-starter that can work independently as needed

Overall understanding of high-level Identity Management concepts
(user ID"s, what provisioning is, etc.)

Basic understanding of compliance and audit requirements

Desired Skills (Optional)

Ability to read, create, and modify UML diagrams

Experience with XML message creation (SOAP, XML-RPC, etc.)

Creating and maintaining Business Process via BPM tools

HTML-based forms

Requisite Pro or similar requirements management tools