Category: Softwares

People aren‘t always happy about new systems or major upgrades. This can pose a threat to the successful completion of a project.

It‘s not uncommon for people to disagree with the decision to implement a new system – especially at the beginning. This should be expected and the reasons noted. However, initial reactions to a new system is less of a concern than a sustained negative reaction.

Your goal as an Architect is to be aware of and measure the threat of acceptance problems and work towards mitigating those threats. To do this you have to be cognizant of them and consider the reasons for them. Some of the more common reasons are:

1. People may have concerns about the need for a new system (and subsequent retirement of an old system). This can also include fear of loosing functionality or loosing influence or power when roles change.
2. People fear new (unproven) technology.
3. People have cost/budget concerns
4. People simply do not like change.

Each of these reasons requires different possible solutions. Some of which you can address and others you can’t. You have to recognize the difference and deal quickly with those that you can. Start early, having discussions with your end users about the new system and its real and perceived benefits and disadvantages. The most effective long term solution is to use the design of the system itself to address the concerns. Other effective solutions include training, scheduled system demonstrations (early in the project lifecycle) and sharing knowledge of what users will get with a new system.

A “Project Champion” can help avoid user acceptance problems. Ideally this should be a person that represents the user group or stakeholders. They sometimes have to be convinced themselves. If there is none then push for one from the very beginning. Once you’ve recruited a Project Champion, give them your assistance in every way you can.

Today’s solution is tomorrows problem

No one can predict the future. If you accept this as a universal truth, than the question becomes how far ahead is the future? One decade? Two years? Twenty minutes? If you can‘t predict the future than you can‘t predict anything beyond right now. This very moment and the ones that preceded it are all you are know until the next moment occurs. This is the reason we have car accidents – if you knew you were going to have an accident on Thursday you would probably stay home.

Yet we see software architects try to design systems that will be, for lack of a better term, “future proof” all the time. It‘s simply not possible to future proof an architecture. No matter what architectural decision you make now, that choice will become obsolete eventually. The cool programming language you used will eventually become the COBOL of tomorrow. Today‘s distributed framework will become tomorrows DCOM. In short, today‘s solution will always be tomorrow‘s problem.

If you accept this fact, that the choices you make today will most certainly be wrong in the future, than it relieves you of the burden of trying to future proof your architectures. If any choice you make today will be a bad choice in the future than don‘t worry about what the future will hold, choose the best solution that meets your needs today.

One of the problems architects have today is analysis paralysis and a big contribution to that problem is trying to guess the best technology for the future. Choosing a good technology for right now is hard enough, choosing one that will be relevant in the future is futile. Look at what your business needs now. Look at what the technology market offers now. Choose the best solution that meets your needs now because anything else will not only be wrong choice tomorrow, but the wrong choice today.