EMC Developer Network (EDN) Editor’s note:

This month introduces the Service Station column, a series of articles about providing professional services around EMC software products. Featured guest columnists express their thoughts about a wide range of topics relating to designing, developing, and delivering solutions.

I spent time with Jeff Rosler (of Flatirons Solutions) during the recent EMC Software Developer Conference talking about the need for discussions that are not necessarily product specific, but instead about the process of producing successful projects. It’s less about “How do I do this?”, and more about “What should I be doing?” This first article is based on the EMC Documentum platform, but it quickly becomes obvious that the issues are common to most development projects, and touch everyone involved. -- Alan Z.

Delivering EMC Solutions to your Customers

This article sprung into being after Alan Z. asked me to help kick off the Service Station column for the EMC Developer Network. The Service Station will take a look at developing EMC based solutions from the perspective of a professional services organization. In practice, it turns out that most of what a services organization worries about in developing solutions is the same for any other organization.

The focus of the column will be around the creation and delivery of those solutions. That’s important whether your customer is internal or external. For example, rather then giving you an example of how to kick-off a workflow, the column will investigate ways to deliver the overall solution functionality to a customer through methodology, tools, and process.

As I was contemplating what to write about that would fulfill both Alan’s expectations and meet with the theme of the Service Station, personal life intruded.

Changes in the weather

I was in Texas with my family during Christmas vacation and was preparing to drive 1,200 miles home to Denver, when I heard the weather report about a blizzard being forecast over part of the route. This was to be the second blizzard in about a week for much of the same area including Colorado, New Mexico, and Texas. I thought that perhaps the roads would be quickly cleared and started out on the drive home. What an incurable optimist I was!

I drove during the first day, and listened as the weather reports worsened. As night fell, signs indicated that all roads were closed due to the storm, so I stopped in a small town in the Texas panhandle and got the last room available in a little run-down motel. Two days later, I decided to continue on and hope that some of the closed roads would have re-opened. Eventually I was able to make it home, only to find that the storm had dumped another 2 feet of snow on my mountain driveway. I finally made it back into the house and spent a few hours the following day shoveling my driveway. My 2007 New Year’s resolution now includes buying a snow blower.

Life lessons applied

I see metaphors in daily life that remind me of the issues we face in developing content management solutions. I’m sure some psychiatrist out there might have a thought or two on that; however, it led me to consider how my experience trying to get home related to experiences we’ve all had on our software projects.

We’ve all seen software projects that start on an optimistic note about what could be accomplished in a given timeframe and generally quickly deviate from that expectation. Engineering estimates that are too optimistic, unforeseen technical issues and changing requirements are but a few of the things that can de-rail project plans. This was similar to my personal experience with the blizzard and assumptions about the power of the storm, and about what that meant for road closures.

Some heavyweight software development methodologies would suggest that possible problems can be planned for and appropriate measures taken to forestall any unseen circumstances at the beginning of a project. While appropriate planning can help to manage issues, it can never guarantee that unforeseen problems can be managed in a particular timeframe.

Let's consider some of the general issues with project delivery.

Communicating Requirements

What about requirements analysis? How do you really figure out what a customer needs and then communicate how those requirements are going to be fulfilled using a set of EMC Documentum products? Some customers may understand the products that a solution is based on very well, while others do not. Even when particular customers understand the products and have a good vision for their needed solution, it may not be shared with all of the actual users. Some customers may clearly state that they want some functionality, but when they later see it in the context of the overall solution, they decide they need a different requirement.

Managing changes to requirements

As changes to a solution are discussed, it can be very difficult to visualize what those changes mean to users from their perspective. Simple changes can have complex ramifications. A user may agree with a GUI change in Documentum WebTop only to misunderstand how use cases are strung together across one or more workflows.

Managing technical uncertainty

There are a plethora of products that are being created and updated all of the time. The Documentum 5.3 SP4 service pack was just released and D6 is on the horizon. How can you ensure that products that you plan to use as part of your solution will function in the manner you envisioned their being used? How can you handle unforeseen technical issues with your use of these products?

Ensuring Quality and Customer Acceptance

How can you ensure that the solution does what the customer and users expect? How do you ensure that changes to the solution do not break other parts of the solution? When you’re building the wrong thing (and come on, admit it, we’ll all done that a time or two), how do you find out early in the development cycle that the product you built isn’t what the customer wants? Find it out early and you can change course and salvage the project. Find it out late and the project fails.

Addressing the issues

At Flatirons Solutions we’re addressing these issues by building more Agile-based techniques into our design and development methodology. This includes integrating product configurations as well as software customizations into a single solution.

Some of the ways that we’ve dealt with these include:

• Performing business analysis to understand the vision and business needs that a solution needs to meet
• Creating an Information Architecture to analyze and create an architecture based on customer data and information
• Creating a Solution Architecture to describe products and interactions
• Iterative deployment to quickly deliver working code and through that delivery effectively communicate solutions to customers
• Test Driven Development to make sure that custom code passes all user defined tests, reducing risk of the need for large changes later on and enabling re-factoring by providing a means to perform low level regression testing
• Continuous Build and Test to allow developers to see problems at check-in time rather then later during development
• Integration Testing that shows that not only code, but product configuration (e.g. custom types, lifecycles, workflows, etc.) are working as expected

Through this column, the upcoming EDN discussion forums, and other postings, I would like to discuss and show how you can better deliver solutions to your customers whoever they may be through the use of these techniques and open source tools.

About the author

Jeff Rosler is a Senior Architect with Flatirons Solutions and has over 22 years of experience in software development and 6 years of experience developing solutions for EMC Documentum products.

About the Service Station

The Service Station column looks at developing EMC based solutions from the perspective of professional services organizations. If you (and your company or department) provide such services and are interested in being a guest columnist, please send your contact information, a brief bio and topic outline to EDN_Submission AT EMC.com.

Click here for an index of all "Service Station" columns.

You can discuss "Service Station" articles on the EDN Forums by clicking here.