Wednesday, October 11, 2006

SOA and PMBOK - Stop the Madness!

It occurs to the Ninja that most of the old style middle management types who have grown up with projects constantly failing, falling behind or out of control, do not grasp the fundamental shift in thinking that SOA demands. In the minds of these IT relics, SOA is just another sales job to the business to get them to fund the project in which the relics find themselves. Once the project is funded, the architecture is seen as a burden and an overhead and the relics fall back to the traditional Software Development Life Cycle and the well worn path laid out by PMBOK. After all, most projects are just a string of sequential steps roughly resembling: Requirements, Design, Develop, Test, Deploy. Or should I say: Requirements, Design, Develop, FAIL. Or some combination of FAIL and pick your phase.

This is pure madness. If the majority of IT projects fail using the antiquated approach suggested by PMBOK, and they do, why do we continue to jump behind the relics who flog this approach and claim that this time it will be better? We will be agile and we will get sign off this time or we will use an automated test tool. Surely that will prevent the failures of the past. Surely you are one of the relics if this is your belief. Wake up and smell the roses Relic. THE OLD WAY DOES NOT WORK. You proved it, now change!

The fundamental shift in thinking for an SOA based project is that there is no 'throwing the requirements over the fence' attitude. The Business Analysts, representing both the operational and the overall business architecture perspective, are involved in not only the requirements phase of a project but they play a major role in every phase. They are no longer just showing up to write some magical Requirements document and then showing up during Acceptance testing to sign a paper authorizing the garbage that was developed to be slammed into production. They must recognize that change to the business will occur during any/all phases including the development or design phases and they are responsible for recognizing and changing the project scope to react to these changes. These changes are constant and so their involvement is constant. Unless of course, nothing ever changes.

If you think(believe) that Business Analysts need only play bit parts during the initial and final stages of your project lifecycle, look in the mirror. You are probably a Relic. The sooner YOU change or leave, the better for us all.

The SOA Integration Ninja

0 Comments:

Post a Comment

<< Home