Friday, 18 April 2008

Applying agile software development to Dynamics AX development part I

Ever since I wrote my thesis at university, I've pondered the fine art of software development methodologies. During my last year at the University of Southern Denmark I "shopped around" and followed a myriad of software related courses, e.g. Agile software development, User-centered software development, and other iterative and waterfall based software development processes. These development methodologies all have ther merits and flaws, which will be well known to any software developer and the process of merging business processes and software development processes is notoriously difficult, though it is of the utmost importance in order to achieve the best results, business- and softwarewise.

The courses I followed at university were mainly concered with the whole development process(es) from early conceptualization to post-installation maintenance, including GUI-development and Business Intelligence reports. Therefore when I started developing (or should I say customizing -a point to which I will return later) Dynamics AX for customers, my craze - User-Centered Design - slowly fell to the background. Is customizing an ERP-programme, such as Dynamics AX, merely a question of replicating exsisting business processes, with some optimization, and merging them into a new ERP-application or is the development of an ERP-solution an almost god given chance to take a critical bird's eye view of the whole organization and try to optimize business processes all the way r0und? The latter would seem the obvious answer but this again begs another question, viz.: can business processes be optimized isolated from the software development process, when the software has a central place in today's organizations? No. Of course it cannot.

All to rarely is there any substantial software development theory included in the business development plan for the implementation of a ERP-system. Traditional user-experience studies / examinations are left behind, because the UI is developed for us, as part of the standard application in the Dynamics-series, and it is 'just' (I know I'm a bit hard here - but I'm trying to get my point through) a question of rearranging data-presentation, based on the customer's prior ERP-system or an external system. All too often does the customer say something like 'that's not the way it was in the other system' when confronted with an newer version of, lets say Dynamics AX.

So the big question is: how do we - as software developers and business consultants - merge the two worlds and come-up with a process which will lead to sound business optimization and software development integrity?

No comments: