In a previous article, I talked about techniques for helping a client transition from a procedural thought process into an object-oriented architecture for the client’s application development projects. Assuming that you’re able to walk clients through this process and prepare them for the inevitable changes to their business process and IT requirements, what are the next logical steps?

Depending on their particular situation, of which you must be intimately aware, you can recommend several paths for adoption. While your goal is to encourage the client to start thinking in terms of OO design principles at every departmental level, you’ll also need to introduce the concepts step-by-step so they’re easily understood. Here, I’ll offer the method I use with my own clients.

Business class adaptations
First, let’s define each of the groups we need to address as “business classes.” Each of these classes has its own weaknesses and strengths in the ability to accept the OO paradigm. To address each individual business class, we need to think in terms of how these “classes” are structured.

As a consultant, you should be aware of the impact your project will have on the day-to-day and month-to-month work patterns of these classes. Every project will differ in respect to class impact and you should make provisions within the project plan to take into account any time or cost associated with cross-class impact. Remember: It’s not only the IT department you must please. All groups impacted by your application will have a say in whether or not you’re brought back into to do additional work.

Next, I’ll address the issues involved in getting buy-in for an object-oriented development project from each of these business classes.

It’s important to involve operational management staff and instruct them as to the changing workflow patterns. The focus within this group should be on the following:

  • Workflow adaptation: This is the logical process for conducting business. For example, the operations staff may consist of a customer service center. If these users are accustomed to addressing customer calls by typing in a particular keystroke within their “green screen” application, a point-and-click interface to accomplish the same task will take some time getting used to.
  • Business rules adaptation: These are the rules applied against the logical process. If you’re able to reduce keystrokes within a “green screen” environment to one point-and-click operation, for instance, this will undoubtedly improve productivity but may confuse the operations staff. In essence, you’ve either eliminated or pushed to the background a once-familiar business rule.

Management within the operational units must be aware of the changes that may incur due to new workflow and process adoptions. Otherwise, the group may harbor resentment toward IT and adoption of the new application will get off to a rocky start. In 1998, I helped roll out a flagship Web application that was to act as the replacement for a client/server-based system. Over time, the Web application began accepting roughly 25 percent of all orders placed. However, the operations staff remains reluctant to use the new interface for the application because it differs greatly from the way they’re accustomed to viewing orders. We never thought this would be a problem, but we failed to take into account that the application was only a front end into the system and the “green screen” views of order processing would still be available. Since users were familiar with this environment, they showed no real interest in moving to the Web view.

With this group, you must focus on the ability of the financial department to support rapidly changing processes (and save future direct outlays) through investment in:

  • New licensing structure adaptation.Licensing for mainframe and midrange systems can drastically differ from client server and tiered architectures. New cost models may be introduced that can either negatively or positively impact financial return, which will directly impact the ROI on a new application development initiative.
  • New training requirement adaptation.Training requirements for existing staff can increase significantly depending on the level of technical adoption. Training is an integral process that can be amortized across many years. A client that hasn’t been exposed to new technology and has been in maintenance mode will see a sharp spike in the training requests coming from IT, which will impact yearly budgeting concerns.

Senior management
You should concentrate the focus within this group on the ability to rapidly impact new product and service development and communicate the cross-functional nature of object-oriented development to senior staff at the earliest possible time. Letting senior management know that additional funds are required or that additional resources are needed for successful adoption of enterprise-wide OOAD allows them time to discover the nature of OO and its successes and failings.

Productivity increases rarely arrive overnight. Senior management needs to be comfortable that your application and initiatives will result in higher revenue somewhere downstream. They’re not interested in technology for technology’s sake. You must work with them to show where and how your application will allow them to produce products and services faster and cheaper than is currently available in the market. If you can’t and you ignore this group, future work with this client may be harder to come by.

Information technology
The primary focus for this group needs to center around change acceptance. The primary focus, outside of actually developing a new application, should be on product and services development adaptation. IT has long been seen by some as an operational drain on resources and not the productivity-enhancing entity that it really is. To change this thought process, consultants should work closely with business users and move into a product development and support role rather than a maintenance and support role.

It’s also a good idea to approach the IT department with a comprehensive training plan. You need to be able to provide training resources, vendors, and mentors to ease the transition phase for developers and their management staff.

Adoption requires patience
Adoption of company-wide OO applications is a slow and tedious process. Just because you have developed a killer OO application for your clients doesn’t mean they’re truly an OO shop. Constant attention prior to your engagement and after completion is necessary in helping your client shift paradigms.

OO is rarely addressed outside of the IT world, but successful adoption requires an organization-wide effort. IT cannot and should not bear the sole burden for such an audacious effort.