Data-centric approaches to EPM integration fail to deliver timely and reliable information to the disparate systems that are integrated. This is because the practice of project management, and its associated information, is inherently a process-centric exercise. Where many types of information can be integrated in a data-centric approach without ill effects, using this approach with EPM data actually causes more serious issues than existed without integration at all.

There are many reasons for integrating systems with each other. Data consistency and master data management are oft cited business reasons for approaching a data integration project. There is also the need of supporting business processes and having a way to enforce business rules across disparate applications. The problem arises however that many integration models and technologies really only provide a data centric integration capability and the transactional systems being integrated don’t have any way of supporting or enforcing the business logic of the other side of the integration. This last part leads to its own issues of data integrity management.

Further compounding the issue is that project data itself has a life cycle over the span of a project where data ownership can change and even have periods of inaccuracy during status updates. Project management systems, even though transactional in nature, don’t have the transaction boundary sophistication of many ERP applications on the market today. When a project manager updates a single activity as part of an overall project status update, that data is live long before the project manager gets done with status updates or project rescheduling. In stark contrast to this, most ERP systems will lock or provide last known values for entire blocks of budget or cost structures during an update process thus protecting the in flux information from inappropriate usage.

The need therefore clearly exists to use a process-centric model for achieving integration of project management information. Only when the flow of information in an integration solution is controlled by business process and defined states of information within the project can one rely on the correctness and completeness of the integrated information.

In this manner, the project management system can be integrated with multiple systems safely and with clear definitions of data ownership defined based on the overall state of a project. Given that there are usually many projects in different phases such as planning, budgeting, execution, etc- the ability to control each project’s information discreetly is paramount to data hygiene and accurate reporting capabilities.

Once the decision is made that supporting the business processes for project management across systems is one of the key reasons for integrating, using a process-centric model not only makes sense, but drives the ability to achieve a dynamic enterprise project environment. In this dynamic EPM environment, information flows and is available as a result of performing the project, from conception to completion. Whether the integration spans two systems or ten, the ownership of the information is defined by the project life cycle state and the flow is orchestrated by the act of working the process.

The benefits are multi-fold. Not only are data consistency and master data managed within this approach, but the imposing of process on the integration model allows business rules to be expressed independently of the the capability of the systems being integrated. Such rules may be defined to control the treatment of the information or to control the processing itself. This truly creates a Dynamic EPM environment where information is acted upon based on its current status, ownership and conformance with internal standards.

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.