Friday, May 10, 2013

Why Business Analysts should understand ACID*

Good programmer should understand business domain. Really good programmer should understand business needs. Even mediocre Business Analyst must be interested in the technology at least at the same scale as being knowledgeable in business. The guy who handles you a 90-page specification saying: "Here is layout of our buttons - make them work" and disappears until Business Acceptance Testing stage - is just a very wrong person for the job.
Unless your project is a reinvention of a door bell, a lot of analysis is required after spec is done. Writing a specification of what a screen should do is a mere interpreter's job - translate language of business (either from customer's words or from general domain knowledge) to language which developers can comprehend. The real analysis should be applied to understand and predict how things will work when instead of humans (slow, inconsistent) or previous programs (outrageously old and poorly written) our new shiny application will take the load.
I struggled the most with this disconnect between BA's and developers while dealing with transactional data flows - be it database or service calls. A sequence of multiple interconnected actions requires a thorough inventory of all possible outcomes and analysis of subsequent scenarios. In 90% cases these decisions are outsourced to developers and if they don't know any better they make decisions which make sense only from the technical point of view.
The strategy of dealing with the outcome of the transactional process is a business decision, not technical. As a developer I always go for proper rollbacks or configurable re-attempts - but it could very well be what business doesn't need or even doesn't want (it may not even be possible - and you are fighting a half-day brain paralysis). This misunderstanding of business need will result either in an outright wrong logic (which is fixable) or in an over-engineering and significant waste (which will linger around for a long-long time).

So, please, please, Business People - don't roll your eyes when your techies will be asking for your preference between asynchronous callbacks and pub-sub patterns. They feel disturbance in a Force, but just having trouble expressing it in a humane way - be patient (and know your stuff).
Update: Starbucks concurs

*ACID - as from technology, not pharmacology.

© 2008-2013 Michael Goldobin. All rights reserved