Every interdepartmental “Enterprise” application in your company is likely integrated in some fashion with just about every other “Enterprise” application in your company. Enterprise Project Management Applications however, are often left out of the overall enterprise integration architecture and only point to point integrations are attempted- usually with less than spectacular results. The end result is that EPM applications have largely been left out in the cold and core adoption of this “Enterprise” function does not occur. This leaves EPM information and processes an island to themselves.

Even with many “Integrated Project Management” solutions, the integrations are EAI style in nature and not process execution sensitive. What use is having the project and financial systems in sync at 10PM every Friday or on some published data change event if the project data is not status ready? In fact, this kind of behavior does more harm than good as inaccurate information is propagated across the IT landscape and introduces erroneous reporting. This erodes confidence in EPM and EPM processes and any ability for EPM to become a truly enterprise level inter-departmental competency.

There are a number of reasons those solutions good enough for ERP, CRM, SFA and the like failed for EPM. The first and most important reason is that EPM is a process centric view of projects and project information while most other enterprise functions provide a data centric model. It is no wonder that a capability set built around managing static structures would fail when asked to manage dynamic processes.

The second reason is that most enterprise applications, perhaps because they are data centric, only rely on light integration points and small amounts of “keying” and meta-data to relate like information across systems. EPM however, is essentially a nexus of static structures whose intersections are governed by EPM dynamic processes. Simply put, EPM requires dynamic, workflow driven data access and data flow across many enterprise applications.

Another contributor to the mess of legacy EPM integrations is that the “system of record” for EPM data has a granularity at the field level, and the “system of record” for many fields migrate from application to application depending on the current process state of any given project. Try managing that with an EAI and you’ll end up talking gibberish to the nice folks in the white jumpsuits. (They will take good care of you, but I still don’t recommend it.)

Lastly, EPM has the misfortune of being an adolescent. Project Management has for years languished as a highly specialized discipline that is poorly understood outside of PMO and other PM disciplined departments. Recently however, Project Management technologies have finally leaped off the desktop onto server and web based tools allowing for wider participation and audiences. This jump was accompanied by government accountability mandates essentially dictating enterprise project management best practices be adopted en mass. The corporate world also seems to have awakened to the very real business benefits derived from practicing enterprise project management as a core competency.

The good news is that unlike a human adolescent, all this attention is maturing the EPM vendor market rapidly while spurning rapid innovation by new and established EPM ISVs concurrently. The bad news is that this brings EPM up to where ERP was ten years ago.

This configuration creates an opportunity to solve for the failure modes described earlier. Technology and tools now exist to rescue EPM from its island of obscurity and we can do it rapidly (as in– not over years, over the next few weeks). You have probably guessed by now what I’m going to say next.

SOA.

Dash! There are almost no SOA EPM products on the market. There are a few that have Web Services and XML APIs but these rarely provide complete coverage of the business objects and processes required to truly enable EPM to be Enterprise.
There is a ray of hope however. EPM applications can be Service Enabled and become consumable as Data Access Services using Web Services or REST. Advanced EPM applications will even provide event notification capabilities that can be extended into the SOA to further enhance dynamic processing of EPM process activities.

Once service enabled, EPM information and processes can be extended across applications, users and workflows using standards based technologies.

Business Process Management (BPM), or building, executing and managing business process has already become a standards based commodity SOA technology. BPM coupled with workflow driven composite applications completely solve the process v. data issue that failed EAI and other legacy integration technologies.

The loosely coupled nature of SOA solutions allows for data access across many systems without the introduction of physical data dependencies across systems (information addiction codependence).

BPM and Workflow services that consume business rules can deliver process controlled “system of record” data integrity logic at the field level. A best practices solution will consume and fire business rules on a canonical information model rather than a data structure tied to particular applications and application versions.

Composite Applications or mash-ups, delivered through enterprise portals and corporate intranets allow EPM process and human interaction points to be tailored and extended across the landscape of project participants.

Shameless Plug: SOALogix makes a product that does this.

This entry was posted on Monday, September 24th, 2007 at 5:09 pm and is filed under EPM, SOA. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.