How do you balance business process changes against the challenges of changing software?

Question

In my admittedly young career I've found myself writing code to support quirky business rules and processes. Inevitably these changes were always in some massively difficult code base and caused many issues. My question has a couple of parts:

1. While software is a tool for businesses to make their lives easier, at what point do we as developers suggest a change in business process rather than in the software as the "magic bullet" to solve a particular problem.

2. How do we as developers evangelize a certain level of reverence for the software as well as the difficulty involved in making changes simply to support the quirks of the business?

I understand that these changes in business processes promote our industry, but in an analogy my father would understand: Which is easier, to melt down a hammer to forge a screwdriver to drive screws or to simply use nails since your hammer is already awesome...?

Answer 1

You can look at

Seven Habits of Highly Effective People

, as there is the sense that you need to develop a sphere of influence large enough to try to change business processes.

Your best bet is to show that you are very competent at your job, and work on developing relationships with people on the business side, so that you can feel comfortable sitting down outside of work to discuss the business process in question.

This is a slow process, but if you try to rush too fast the business will push back, and squash you like a bug. If you read

The Age of Heretics

for example, you will see examples of companies that were too successful in making changes, and the corporation destroyed them.

At the moment your best bet is to make changes, as you can, to have the software be more adaptable, so that if the process changes you can easily adapt to the new rules.

Answer 2

That's kind of like the role/strength of the CIO. If the IT side can convince the business side that it would be easier/cheaper/cost effective to change the business process than the code, than you have a point. Otherwise, the quirky business practice may be more valuable than you think. I also doubt that you are making it clear that if you spend time on the quirky problem, you won't deliver the needed features on time (good luck with that).

If technologists had their their way, the GUI and the mouse/pointer would never have made it out of the lab. For everyday users, they're here to stay.

Answer 3

I think there is value in questioning the cost effectiveness of building new solutions to adapt to existing business processes versus adapting business processes to adapt to existing solutions. However, in reality, I have not seen the business consider this angle.

With that in mind, I think the next best thing you can do is to anticipate specific changes that the business might request in the future and develop your solution such that it can adapt to those changes easily.

Answer 4

Unfortunately, this is entirely situation-dependent.

Even with a great deal of experience in business AND software, it is still a complex issue.

As far as your specific questions:

1. As soon as you see them. What is important is to couch your suggestion in constructive terms. Also using terms relevant to the business (ROI, NPV, etc). And finding ancillary benefits (). So if the software change really doesn't mitigate the business problem, the cost is high and fixing the business process has significant ancillary cost savings, you pose a completely different scenario than just saying "we can't do it because it costs too much".

2. The software is owned by the business - it isn't owed any more or less reverence than anything else the company owns of similar value.

Answer 5

Before you can do anything, you'd better step back and try to understand the business. If they're reacting to change by adapting their processes, that's a GOOD thing. It's when they leave things exactly the same for years that you can forget about them remaining a company. You need to make sure, however, that the change you're responding to won't negatively impact up- or down-stream business processes. Business units don't often do that checking. But, when it all goes to hell, you know who they're going to blame, right? By doing this, you can head those issues off and evangelize, "better ways." Not doing it is a prescription for eternal frustration.

Learn their business before you even think of codifying it.

As for the mechanics: What I always had my teams write was, "generic software." Some business unit might have needed a way to capture a form and produce a report. Okay, easy enough, right? Wrong. Always consider a request as something*200. Would you want to support 200 such applications, all doing almost the same thing? Not me. Too lazy.

I directed my teams to make a generic form system and use off-the-self or generic reporting mechanisms. And I stressed the use of XML/XSLT for as much as possible (not relying, for example, on Microsoft's easy-bake-oven technologies that seem to break with each new release). Then, when another business unit wanted, "something similar, but with changes," the core was already there - we only needed a new folder, modified XML/XSLT and we were done.

That always - ALWAYS - made those future changes easier to handle. "Need a new field? Change an XML file. Need to change the way a report is produced? Change XSLT. No program changes." Get it? NO program changes. Keep as much as you can OUT of the logic. Even business processes can be represented in XML/XSLT.

In reality, most of the applications you'll come across are the same Programming Wheels (a good algorithm book, by the way) that have been done forever. They'll just be done more poorly by people who didn't understand the business and understood their craft even less.

They're not going to build their business around you or your software, unless you're writing MS DOS for the first time. The second you suggest it, you'll be gone. And... you should be.

Answer 6

• When facing escalating business rules complexity in relation to the current form of the software, try considering Aspect-Oriented-Software-Development, in order to achieve better modularity and separation of concerns. This way, new or changing business rules, as they appear, may be integrated in your existent code base as plug-ins to only those modules that need them, not being necessary to rewrite large amounts of unrelated code.
• The idea is that after all, a lot of business rules come from specific legislation, and it's the responsibility of the business, transmitted to the software as well, to implement and adapt. I personally believe that the lack of will to follow specifications due to perceived difficulty is what lead most web browsers to lag more or less behind web standards - altering the rules was a temporary workaround that has lead in time to a far greater accumulated cost by supporting each browser's particular quirks. Try to implement new business rules as fast as they appear or they change - failing to do so leads to accumulative lacks of support for new functionality and ultimately render your software deprecated.

Answer 7

One of the most frustrating things any end customer (that is, a customer of your employer or customer) can hear is "the computer won't let me do that". Say, add items to an order after the shipping is calculated, or cancel something before the sales tax has been calculated, or whatever. The software should serve the business. Sure, that means the software has to change a lot, and sometimes it changes so much from where it was that you have to start over. As you grow in experience you will write software that is easier to change, given the unadjustable reality that business process change, laws change, tax codes change, customers change, and so on. Some day you may be a trusted business advisor to your clients. That is unusual early in your career. I'm in that stage now but I'm in my fourth decade of being paid to program. I rarely suggest the business accomodate the software. It takes a lot of judgement to know when that might be the right thing to suggest. And whatever reverence you might feel for your software, do your best to hide it from the folks who pay for it. They see it as a tool to support the real business they're in.