Project Managing an Event Processing Application

Over the past few weeks I’ve been an “Acting Project Manager” alongside a talented TIBCO team who designed and implemented a telco services gateway using TIBCO event processing software. Of course, the importance of the Project Manager role decreases in direct relationship to the experience of the team – so my role here was somewhat redundant due to the experienced implementation team. The project required Rapid Application Development exploiting a “standard set” of TIBCO technologies:

• TIBCO BusinessWorks to host the service entry and exit points
• TIBCO BusinessEvents for the main processing rules covering routing, validation, service throttles, KPIs, logging etc
• TIBCO EMS as the main external event (/message) transmission mechanism
• TIBCO RV for internal communications within the distributed application, e.g. for log handling
• TIBCO HAWK for application monitoring
• TIBCO Administrator for managing the deployment and updates to the application.

Some observations on the Project Management aspects were:

1. Good design counts: there were several specification changes (including to the specification of the incoming events) that were to some extent mitigated by the tooling flexibility, and some by the use of good design patterns.
2. Project Management is sometimes Anti-Agile: some of the (event) specification changes we deferred to later in the application development process in order to provide controlled, manageable, validated releases. The PM’s main role is obviously to protect the development team and delivery schedule from scope creep, although inevitably some scope changes were requirements boundary cases…
3. Test-driven development: early effort was expended in an appropriate test framework and test cases, used to exercise the event processing application with particular event types and patterns. This paid dividends in allowing defects to be identified, and resolved, early.
4. Communication and control artifacts: the High Level and Detailed Designs were defined in docs and in prototype BW processes and BE rules; we first used MindManager for internal reporting of issues, and then progressed to an existing Bugzilla instance for co-operation on issue management. Although we had an MS Project plan, we deferred to Excel for internal and customer reporting. Code and docs were controlled using SVN.
5. Knowledgable customer contacts (and good customer relations) make the PM’s job so much easier…

Some specific project challenges relating to the “event processing” aspects:

– Event definitions are key. If the event model is changing lots as development is occuring then this can be problematic. One traditional and effective solution is to use your own internal abstract event model and map to / extend this as required.
– Testing timed sequences of events could be a challenge. This project was event processing, not complex event processing (there were a few abstract KPI events created, but for the most part the application was stateless). Obviously, live system events are ideal for testing.
– Application performance (throughput, latency) need to be monitored and managed thoughout (although not an issue for this particular application, so far).

So – not much Project Management is specific to the “event processing” aspect. But that is good news and to be expected when insulated by a good development team and good tools!