You’ve been contracted to develop an application that uses the latest and greatest technologies that the IT world has to offer. However, the client’s technical landscape looks like it hasn’t been updated since Ronald Reagan was in office.

Moving from a step-wise approach to software development to an object-oriented (OO) approach can be very difficult for some developers. As a consultant, you may meet with fierce resistance from the existing development and maintenance staff to new ideas.

But there’s no question that OO development structures a program into manageable and logical components. So how can you convince managers and developers within an IT staff that OO, specifically in the Java or COM camp, is the best route to take in terms of new application development? Here are some key insights on working with clients who are new to OO architectures.

Read more on the topic

Identifying key players
Let’s assume you’ve reached the conclusion that J2EE, for example, is the path best suited for a particular client’s future application development initiatives. To the client, this means more than just paying you for your consulting services. There will be additional costs that will be incurred long after your engagement ends.

So, first and foremost, you need to make sure all parties that will be affected by your new enterprise solution are aware of the impact the initiative will have on their respective departments or positions. These key stakeholders will need to bear the brunt of the changes that will be present in the new architecture:

  • The money people: These people control funding, expenses, budgets, and so on. They need to be made aware of the cost of investing in the new technology. Tell them about the vendors you will be using and their licensing and pricing models. Chances are, they’re going to be surprised to learn that these models may be significantly different from what they are used to. Significant investments in resources and training may also be necessary.
  • Operations: Every client you deal with will have some sort of operations staff that supports, processes, and handles client orders. Whether this is a manufacturing or financial services client, you’ll need to make sure this group is aware of the process changes that will arise. Keep in mind that users who are accustomed to rapid keying of known green-screen functions will find a point-and-click environment a drastic change in their day-to-day workflow.
  • Senior managers (corporate, business units): Senior management will need to buy in to the object world. In fact, I’ve found that the least resistance to OO ideas comes from senior management staff. The idea of rapidly deploying products and services really gets them going.
  • IT management and staff: While everyone else may buy in to your ideas and architecture, the IT department needs the most attention simply because they are the people who will need to support the application and continue to build versions into the future. They will also be the ones who are asked to embark on a career-changing path that is shrouded in uncertainty and apprehension.

Developing a convincing argument
I’ve defined those departments and individuals who will need attention during this process of adopting a new architecture. What techniques can you use to convince each department or individual that the new architecture will benefit them directly through productivity gains, cost savings, and increased customer exposure? Here are a few techniques I have used:

  • Identify a widespread complaint. As an example, I worked with a client who constantly fought integration issues with suppliers and clients alike. Using a previous integration project that took two weeks to complete, I arranged for an enterprise applications integration (EAI) vendor to demonstrate the same integration project that only took two hours.
  • Provide a prototype. The tried-and-true prototype can go miles in convincing many people. Again, build upon a known and constant business issue and work with vendors to demonstrate the solution to that problem within your proposed environment.
  • Validate your conclusions and results. It’s important to confirm your recommendations with industry research and, if possible, with examples of other companies that have successfully implemented the architecture. An even greater impact is a tour of local companies that have done exactly what you have proposed for your client. This validation can help put people at ease and help them in adopting the new thought process.
  • Offer mentoring and support. This tactic is used primarily on the IT staff to guide them though their training and development tasks. When possible, a mentor resides on site after you’ve completed your engagement and offers the development team help and direction on best practices in the new architecture.

These simple techniques are by no means all-inclusive, but they can help guide consultants through the task of introducing an OO architecture into a procedural environment.

What do you think?

Does OO programming beat the procedural or step-wise approach? Have you helped a client transition from one to the other? What were the results? Post a comment below or send us a note.