EPF Composer and the problem of scalability in process modeling
August 9th, 2007 by Kamal AhluwaliaIn my experience process authoring for software development processes is a highly collaborative activity. It is unnatural to expect a solo effort to come up with a process that could be successfully consumed by a wide team of practioners. The process infrastructure also needs to scale well. Reusing existing process components not only reduces significant overhead but also makes the task of coming up with customized processes agile. Any tool that attempts to support process modeling needs to address these two objectives. Based on the evidence I have noticed, the EPF Composer (and RMC from IBM) fails in this regard.
From the information available, it appears to me that there are significant problems being faced by the Open UP team as they try to come up with a process model. The fundamental issue stems from the fact the EPF Composer is designed as a single-user client tool over-relying on SCM to check-in/check-out complicated process plugins. In my opinion it is unrealistic to manage processes in this manner. You basically end up choosing one of two undesirable options. The first option is to break up a process into multiple constituent plugins that are managed separately in an SCM. The second option is to put everything under one library that is checked in. Here is an on-going EPF-dev discussion thread on this topic. This is a thread questioning the rationale for having a overblown library with every sort of plugin in it.
Most enterprise teams will probably face similar problems when using Rational Method Composer (RMC). If the OpenUP team is having difficulties dealing with the limitations of the tool when trying to add a single (DSDM) plugin to the base OpenUP methodology, imagine the magnitude of problem in an enterprise environment when a blended methodology process architecture consists of a number of methods, regulatory and compliancy standards. Moreover, in that environment there will be a large number of subject matter experts who would likely want to collaborate as they contribute to various aspects of the processes. With the difficulties I am seeing with the usage of EPF Composer within the EPF team one can imagine the problems being intensified with scale.
Providing a server side support for process management is critical for a scalable process architecture and collaborative development of processes. This was a fundamental business objective for the Osellus engineering team that came up with a robust database-backed enterprise architecture for IRIS Process Author. Since every process asset resides in a database, it is easy for IRIS Process Author users to discover, tailor and export processes as needed. All this is done without resorting to complicated check-in/check-out rules associated with handling processes managed as files.
Finally, some would say that it is ironic that the very team that is promoting the “eclipse way” is actually building products that seemingly takes one down the path of single client development rather than team-based development or worse still providing only limited visibility into source process content.
Last 5 posts by Kamal Ahluwalia
- Is my process true to my methodology of choice? - January 7th, 2008
- EPF – Failing grade on collaboration - January 2nd, 2008
- Governance Webinar Recording - December 7th, 2007
- Webinar - Effective Software Development Governance - November 28th, 2007
- IRIS Process Central is here... - November 19th, 2007
August 9th, 2007 at 4:12 pm
The process engineers are forced to adopt the EPF Composer approach rather than the EPF Composer supporting the way process engineers prefer to work.
August 16th, 2007 at 1:55 pm
Managing separate plugins in SCM would only work if they do not have a depending relationship with other plugins. Assume you have 2 process designers working on separate plugins simultaneously; Plugin A is depending on Plugin B. The designer working on Plugin B can only make modification base on the original information from Plugin A. When modified Plugin A is check in, the process designer for Plugin B has to re-import the entire Plugin A back into his working method library and perform a merge to overwrite any content associate with Plugin A update. Such changes are extremely undesirable as the EPF did not provide any report on the change within Plugin A and the potential impact on the Plugin B. It is almost impossible for the designer to know if the depending process is still valid. In a typical plugin project folder, designer has to perform diff on the changes plugin.xmi in order to verify in the structure or descriptor element has been removed or changed. It is even more difficult to check the potential method content changes as you will have to compare each individual content element xmi and verify the changes within description fields. When there are multiple designers trying to work with multiple depending plugins at the same time, the impact for content changes could be potential unmanageable.
August 16th, 2007 at 5:53 pm
Any process architecture assumes many dependencies between constituent packages. EPF composer relies on plugins to package method content and processes. Based on the challenges associated with plugin dependencies I dont see how this tool can meet even the basic requirements of any enterprise organization.
August 30th, 2007 at 10:31 am
[…] the past I have pointed out the issues with scalability and lack of enactment (both in context of EPF and IBM’s RMC stemming from that fact that both […]
October 1st, 2007 at 4:44 pm
[…] This is simply unbelievable. First of all, that still does not solve the problem of scalability (see why). Secondly, SCM is a code repository specially built for handling code and not process assets. […]