Job Descriptions That Betray Employer Misconceptions

A job advertisement I saw recently really seems to epitomise some common and serious misunderstandings that many corporations have about the value and role of business rule authors. How many of my concerns do you share?

The following advertisement recently from a source I shall not divulge (text exactly as source, except slightly amended for anonymity). Pay particular attention to the coloured text (particularly how the orange business rule requirements are mixed with purple IT tasks):

BUSINESS RULES ARCHITECT / CONFIGURATION ENGINEER

Performs business architecture and business rules definition and translation into systems configurations. Collaborates with Business Architects to develop business rules for new applications, address application questions and issues. Ensures that system configuration is created and maintained in a manner that supports divisional objectives, and in coordination with other system vendors products. Analysts safeguard the quality and integrity of all systems data and functionality by adhering to a quality assurance (QA) discipline for on-going systems operations; ensures that a continuous testing loop is built for testing, error reporting, correction, and re-testing until expected results are achieved. Responsibilites Include:

Drive the definition of the Configuration Analyst role and discipline within Retirement Services Systems in support of IT Strategy

Drive the analysis and creation of business rule definition and implementation for large project activity

Align systems configuration with business strategy through consultation with Planning and Strategy team and IT Management team.

Collaborate with Test staff in planning for Interface testing

Responsible for the accurate and timely development of business rules and supporting configuration data for the new system.

Perform hands-on configuration work

Develops configuration modifications for new business requirements

Interacts with internal customers and other Configuration Support Unit associates as needed to confirm configuration data and complete follow-up actions.

The specification goes on to list several IT platforms, vendor products and infrastructure technology requirements. There is no mention of business knowledge.

I was struck immediately by the fact that this approach to recruiting business rule authors is not only typical, but also highly revealing of a common flaw: the implicit assumption that business rules is predominantly a technical domain or a side line to technical architecture.

I am not suggesting that projects would not benefit from a person satisfying the specification above. On the contrary, such an individual would be an invaluable technical architect on many projects. But the sentences of the role description that I have coloured for emphasis seem to suggest that this individual is the sole business rule architect on the project. The inference seems to be “writing business rules and performing business rule architecture is a technical job” or worse, an aside to the main technical job of configuration engineering. This is not the case.

My experience tells me:

An effective business rule author should have business experience.
His or her business knowledge engineering skills should be at the centre of any job specification.
Ideally the business rule author and technical architect should be distinct roles for each has a different focus and it is highly unlikely that one individual could satisfy both.
The fact that many recruiters believe business rule authoring is exclusively a technical skill is undermining business rule projects and impeding the transition of companies beyond rule maturity level RMM 3