Business Analysts: Liberating Clients from the Tyranny of Inefficient and Costly Processes

A hundred years ago, an average engineer was a multidisciplinary expert capable of reciting French poets like Rimbaud (1854 - 1891) and Baudelaire (1821 - 1867) and able to engage in eloquent ad hoc disputes on the subject of artists like van Dyck vs. Rembrandt. Twenty years ago, an average software engineer would mistake Rimbaud for Rambo, van Dyck for Van Damme, and Baudelaire as the type of business only open in Nevada. However, this software engineer would be able to code in any existing programming language from C/C++ to assembler and FORTRAN. This engineer would be able to not only write and tune stored procedures in any databases from DB2 to Informix, but also engage in articulate debate on a subject of Microsoft vs. Borland C compilers (with preferences strongly on Borland). He would be under the impression that it is part of his job to debug code, and would look very strangely at you if you even mentioned quality assurance or quality control. He would also assume that in order to produce a good system, an engineer must understand business process as well (if not better) than the business expert himself. With his large ego, the software engineer of yesterday would look down at everybody who could not explain the difference between malloc() and calloc() functions.

These engineering dinosaurs are now extinct, but most of us should not complain. Out of the death of these giants many professions were born: Database programmers, language programmers, DBA, system administrators, quality assurance (QA) specialists and business analysts ("King is dead, long live the King"). Most of these IT specializations easily received official recognition with the exception of quality assurance and business analysis. After some struggle, QA was accepted in the IT family and now is firmly entrenched, well defined, and considered a noble profession. This is not the case with us business analysts. So wherein lies the rub?

Question 1: Do Business Analysts Have a Place Under the Sun?
Well, the answer depends on whether you, or more importantly your manager (CTO, CIO, etc.), are believers in the agile methodology. The name for this approach to project management -"agile" - presumes a close and direct collaboration between developers and business users. This methodology assumes informal requirements, basically making the job of the business analyst irrelevant and obsolete. Fortunately for me (just call me incurable optimist), I do not believe in agile. I have many reasons why I don't believe it but the most important one is that I simply never did see it working for the average IT department that deals with complicated business processes. In fact, I do not believe that anybody is using agile without contaminating it first with many tiny compromises. These compromises may allow people to maintain the proud name of the "agile shop," but they defy the letter and the spirit of the process. To rephrase a well-known aphorism about truth: The pure and simple agile process is rarely simple and never pure. So yes, we do have place under the sun.

Question 2: What is Your Name, Stranger?
If you think that we like the names business analyst, system analyst, or functional analyst, then you are very much mistaken. They may be our nom de guerre ("war names")-and we are reasonably content to receive well-deserved pay under one of those names--but they do not describe who we are, what we do, or how we would like to introduce ourselves. We are not simple translators from one language (business) to another (technical). Our task is significantly more complicated, challenging and rewarding:
• Our main job is to define and oversee implementation of system functions and capabilities that are flexible, reliable and cost effective.
• We must learn and understand requirements in contents of the client's business in general. This may sound obvious, but try to do it when yesterday you were immersed in the world of Mergers and Acquisitions and today you are now expected to "wow" with your knowledge of pharmaceutical companies.
• We have to be diplomats, interrogators, and great generals all at the same time: Diplomats, because the relationship with the client is vital for our success; Interrogators, because the client never provides all essential information voluntarily; and great generals, because we have to plan and execute our quest for knowledge with accuracy and precision.
• We must earn the respect of other developers. If we do not, either every word and/or decision of ours will be challenged by an unfriendly and disrespectful bunch, or we simply will be ignored. Both scenarios are deadly for your ego and your job security.
• We have to be great tacticians. After all, the date for a new software release is usually announced before anybody has even a vague idea what it is that actually needs to be built. We are always walking the thin red line between pleasing management and satisfying the client.
• Being good tactician does not mean we can forgo strategy. We always need to be cognizant of the enterprise roadmap of the company, never confined by the timetable of a single release or the business vertical of the moment.
We are creators. We are designers of the solution. You can call us business architects.

"De Oppresso Liber"
"De Oppresso Liber" is the motto of Green Berets, and in the U.S. Army it means "to liberate the oppressed." It may not be self-evident, but in my mind we business architects should adopt it as our own. First, we are supposed to perform that dictum exactly: Liberate our clients from the tyranny of inefficient and costly processes. Second, just read the following quote from the U.S. Army Special Forces website: "You need to be mentally superior and creative, highly trained and physically tough. Alone and part of a team, you'll work in diverse conditions, act as a diplomat, get the job done in hostile situations and, at times, establish residence in a foreign country for months." If by "hostile situations" we understand unbearable pressure exercised by management, contempt (sometimes) by developers, the high demands of quality control team, and substitute the client's location for "foreign country" (where we are supposed to train the indigenous population to see the light of IntraLinks, perform intelligence gathering and escape and evade tough and unfriendly questions), then you will see how much we have in common with the Green Berets.

In conclusion, despite the many problems, frustrations and disappointments associated with being a business analyst, in the right circumstances business architecture is one of the most interesting and gratifying professions. (That is, assuming you know how to create the right circumstances).