Going Live with Metastorm: One Developer's Experiences

	Bookmark This Page Email This Page Format for Printing Submit an Article Read More Articles
	Related Tools & Articles Technical Concerns with BPM 5 Steps to Choosing The Right BPM Suite BPM Roles and Responsibilities
	Discussion Forum "I suggest you sit in on some web events to get educated quickly. I'm sure if you search on 'bpm' and 'software,' you will find plenty of hits. We are not using BPM in our organization for software development, but that's because..." Contribute to this Discussion

By Denouvre de Beer

I was recently involved in a software development process that used Metastorm as the preferred business process management (BPM) tool in order to achieve rapid development progress. The company, a medium sized investment firm in South Africa with about 300 employees, was looking at rewriting its new business processes. The development team of which I was a member had eight full-time people: two Metastorm developers, a .NET developer, two testers, a business analyst and two system analysts. Five were female (more on this point later). One of the female systems analyst was a developer as well, bringing both development and analytical expertise to the project.

In this article, I share what I learned during the project. I'll be upfront about one bias: I believe Metastorm is one of the easiest BPM tools you could work with. Its visual editor makes designing and development a quick and effortless task.

Recently the project went live, and in all aspects it went pretty well. Was it the tool that made going live such a breeze or was it team expertise? In my opinion, there were four major areas that contributed to the project's success: training, communication, an extensive development environment and solid intellectual capital.

Make Sure People are Trained

All the developers on the project had Metastorm training. (Only one developer had previous experience working with Metastorm.) The training consisted of a three-day crash course in Metastorm development. It was hands-on, where the developers were placed in a classroom and asked to practically design and implement processes. Hence, most of the team members were on the same level when it came to software knowledge.

The group grew exceptionally knowledgeable. As time progressed, the team started to develop and enhance processes quickly and efficiently. Some of the processes consisted of doing the same "item of work" for different requirements. These processes were then modified to integrate with libraries and generic processes for re-use and ease of maintenance.

A lot of the original "process code" developed for the project came from an external service provider. Some of the code had to be rewritten or redeveloped due to a lack of good Metastorm skills in South Africa. However, the team still had to leave code of "known problems" in the development process, due to time constraints and other delivery promises.

Good Communication Makes a Difference in BPM

Communication, an often-overlooked discipline in BPM initiatives, played a vital role in the success of this project. I believe that a lot of our success was due to the fact that most of the team members were female (including analysts, developers and testers). Having more female resources within the team made the project feel "chatty" and hence communicative. (By no means am I saying that if you want Metastorm to be implemented successfully, hire women; but I do want to point out that the lines of communication were enhanced due to the female presence on the project.)

When problems arose, they were quickly pointed out to management or the team leader and tackled almost immediately. Since communication is often dependent on the approach of the project manager within a project, we were fortunate to have "above-average communication" due to the PM's practices in this regard.

Dedicated and initiative-driven participants made this project a success. The analysts and developers on the team had previous experience in product development and testing. When issues regarding specific approaches arose, the team was quick to respond with potential solutions and ideas. Regular team meetings, (both specific and general) contributed to the communication successes. Nothing was left out; every single issue was hashed and rehashed until an acceptable outcome was achieved. Also, a business representative was present at all of our meetings to save time and handle decision-making from the business side.

Get Extensive Experience with the Operating Environment

I believe this project was tested more than usual. This was a direct benefit from having so many "environments," consisting of hardware and software setups that mimicked production and user interaction as best as we could. Due to costs, some environments didn't exactly match the production servers' hardware requirements, but all software requirements were the same.

Development: All coding and unit testing took place in this environment.

Quality assurance (QA): The testers and business units used this environment for testing the development done by the developers.

Pre-production: This environment mimicked production except for server quality. User training also occurred within this environment.

Production: This was where operational use of the product occurred.

How did having so many environments actually reduce production errors?

• The Metastorm administrator had to install the software on many different environments. Hence, she achieved a familiarity with the software quickly and easily. We resolved installation issues faster and gained a better understanding of the software security.
• Having different environments kept software development and user issues separate and didn't create confusion among the testers, business users or developers.
• The variety of environments helped us identify environmental issues very early in the development cycle. When a problem arose, it was quickly pointed out that maybe it could be as a result of a configuration issue. Moving into production was based on a task list where all the snags that were expected were documented for future reference.
• We were concerned about systems integration, which was complex. (Metastorm's tool lacks integration capabilities such as data type transformation and straight API calls; you'll find yourself going the Java/VBScript to get certain tasks done.) The fact that two database platforms were used for data manipulation made development challenging. The environments had to be synchronized, and if any one aspect of the implementation process was forgotten, it proved problematic. Having multiple environments forced the administrators (both database and Metastorm) to go back to the customized manual to check for flaws and configuration settings per environment.

The Role of Intellectual Capital in BPM Projects

Intellectual capital became extremely invaluable when the project started, since we were working with fairly new technology. People who are confident that they can learn almost anything and make a success of the effort are an absolute gem in business today – especially where there are a variety of technologies involved. Most of the people involved in this project were willing and able to be trained, which resulted in a good outcome.

The people who worked on this effort showed a number of positive traits:

• They had good communication skills.
• They were initiative-driven.
• They were diligent and showed foresight.
• They were progressive in their thinking.
• They showed above-average development skills (though not necessarily with the Metastorm tool).
• They had solid development backgrounds.

Of course, almost all developers consider themselves to be of good quality; not so, of course. A project of this magnitude exposed a few lazy, slap-dash developers who were quickly wrapped on the knuckles for producing untested and buggy work.

Results of the Implementation

The users were glad to see the final product even though it was delivered a few months after schedule (three months after the initial date). We achieved our goal: consolidating functionality and integrating access to other internal applications from the intranet. So now the workflow component was part of this centralized system as well.

On the part of the users, there was some resistance to the look and feel of the new BPM system, but the overall adoption of user routines was a success. Interestingly, due to the time delays, the company has experienced no cost or time savings. So shouldn't that make it a "flop"? Not at all. The design has been revamped to the business and IT disciplines of code re-use and modular design as well as product extensibility. The final product runs well under maximum user efficiency and scalability is not an issue.

Useful Links

Metastorm
http://www.metastorm.com/

About the Author: