Defining your terms makes a world of difference when a project manager is modeling a business process, says Debra Berard, program manager for business excellence, Lean/Six Sigma at Seagate Technology LLC.

The bugaboo that also haunts data integration projects — you say “bill,” I say “invoice” — is something project managers need to solve in business process modeling for application development.

A recent example  Berard offered was the design of Seagate’s failure analysis common tracking system (FACTS) application, which is used to find the root cause of failures in product design or manufacturing so they can quickly be corrected.

In a competitive business like disk drive manufacture the quicker a failure can be remedied, the quicker a new product gets to market.

To develop the FACTS application required WebEx meetings and conference calls with stakeholders from all the Seagate facilities involved including manufacturing sites in Thailand, China, Malaysia, and Singapore, as well as design centers in Oklahoma City, Minneapolis, and Singapore.

During these meetings, the project manager captured the processes that existed in the various locations using a business process modeling and analysis tool, the newly released Metastorm ProVision 6.1  enterprise modeling product.

The first thing the analyis revealed was the while Seagate’s goal was to have one failure analysis process, there were approximately 25 to 30 different processes in the company.

But after further review, that wasn’t as bad as it first looked.

“Come to find out, we did have a lot of processes,” Berard said. “but what was revealed was that they were really doing the same process, but calling the activities different names.”

So the issue was resolved in the conference calls by getting all the stakeholders around the world to agree to call the failure analysis activites by the same set of names, she said.

Once that was done a common model for FACTS was created, which then became the requirements document for the $5 million application development project.

Now, everybody involved in failure analysis at Seagate uses the same terminology as well as the same Web-based FACTS application.

Last week we got flooded with requests to extend the deadline for our Products of the Year Awards submissions. Normally we’d have taken a “no soup for you” stance on this, but when the requests topped the dozen mark we figured we should grant an extension.

Now you’ve got until February 15 to fill out the nomination form. It will push back the announcement of winners until March, but we believe this will be the most comprehensive set of awards handed out in the SOA space and we wanted to make sure absolutely everyone gets a chance to submit.

For those of you who don’t know, we have eight categories:

1. Service design and modeling (including BPM)
2. Service assembly and integration (ESB, orchestration)
3. Service performance (testing, QA)
4. SOA runtime management
5. Data services/integration (including BI)
6. SOA security
7. SOA governance (including registry/repository)
8. Composite application assembly (portal, Ajax, RIA)

Products need to have been released between Dec. 1, 2006 and Nov. 30, 2007. You can check the nomination form for more details, though we highly recommend you explain how the product enables SOA and adheres to the principles of service orientation in your entry.

A wise person once said that when you set out to do something, a good place to start is at the beginning.

Service-oriented architecture is no different. Often would be practitioners of SOA start in the middle, trying to integrate two different applications. In many cases that serves a tactical purpose, but that doesn’t address how to build a truly loosely coupled service. When you attempt to tackle that higher degree of difficulty, it all starts with modeling. You’d be looking at a haphazard design process and slew of problems in its wake if you failed to do a proper job of modeling your intended service.

With that in mind, we’ve added a modeling lesson to our Service Orientation for Architects School. It offers a Webcast with noted SOA guru Thomas Erl, covering SOA design considerations and best practices. Erl ties design principles to the core principles of service orientation and delves into the relationships between various design elements.

Victor Harrison of Computer Sciences Corp. sat down for a podcast, giving five insider tips for SOA modeling. The final leg of the lesson is a report detailing what constitutes the SOA lifecycle and what architectural challenges arise as a result of this new development lifecycle. Do NOT miss this report. It features advice from numerous leading analysts in the SOA space and lays out the lifecycle considerations that need to be understood at the start of any SOA project. It qualifies as an essential resource.