I have seen many software companies fail to arrive at a consensus answer to this seemingly innocuous question. The highest propensity is to gravitate towards the business for which software is being written. If that happens to be helping fixed income traders price derivative embedded bonds, the “domain” gets defined as “fixed income”. And once defined, everyone wants to become “domain experts”. If this line of thinking were true then everyone associated with automobile engineering would start harboring aspirations of becoming a Formula One race driver. Thankfully that doesn’t happen.
It is sad that many senior leaders in the software industry cannot break the problem up in order to solve it (wasn’t that the first thing they taught at engineering?). “Domain” means different things to different people. Continuing with the same example, “fixed income” might very well be the domain of the business analyst working to build the pricing application (it probably also is a good part of the testing team’s domain – the guys who will surrogate the customer to test the application). But spare a thought for the developer who is writing this application in C#. Is his domain not “C#” and/or possibly “dot Net”?
Reckless definition of the domain then spreads like cancer throughout whatever decisions it perpetrates – most importantly learning and development. Training courses get organized where the “Fixed Income” domain is taught. The business analyst attending the course knows more than the curriculum because her job mandated that she read half of Fabozzi’s text book to even make it to the role. That’s fine – at least there is no distraction for the business analyst. Developers on the other hand may find these new concepts intriguing and start reading up about Indexed Bonds and try their hands in bootstrapping yield curves in excel (yes, excel – because that’s about as much “systems” the instructor knew”. The ace C# developer has been set on the path to become a sub-standard business analyst.
So now go ahead and answer the question I asked. Okay – now is a good time to answer the first one – “what’s your domain skill you said?”
Technorati Tags: software skills, domain knowledge, training software engineers, business analysis