Monday, May 28, 2007
Are Business Applications Boring?
I was thinking about a posting from James Tarbell on Why Architects may be better than Engineers when I think he is not acknowledging the correlation of architecture and business applications vs horizontal applications and engineering. Generally speaking, folks in Silicon Valley aren't really focused on business applications and yet they seem to do a better job of attracting top talent than say folks in Hartford CT which begs the question are business applications boring?
Business applications include billing, tracking equipment, people and projects under the guise of governance, custom interactive reports, sales forecasting, claims administration, etc. In business applications, one is generally modeling "rules of thumb" rather than intellectually challenging "puzzles" of the type seen in university courses in computer science.
Most folks in charge of business applications have difficulty expressing the rules of thumb. The software developer's job is to help them define and clarify such rules. Business knowledge is often implicitly understood, and it can be difficult for the domain experts to express that knowledge explicitly. This is one of the big challenges of business applications. Unlike university puzzles, the givens to the problems are generally not clear. There is often no easy way to tell if the machine is producing the intended results without having the end user try it for a while.
Sometimes software developers have sufficient expertise and influence to suggest changes in business processes to make them more logical or efficient. Presenting ideas to a business domain expert requires skilful sales technique. Otherwise, you risk coming across as arrogant or pushy. In the business world being liked is often more important than being right, but techies often see the reverse, creating a culture clash of sorts.
Usually a business has many nitty-gritty rules and exceptions to rules that require spending significant time and effort to adapt the framework. Copy-and-paste programming often seems easier than trying to make the ultimate generic Thing. Smaller scale abstractions, or micro-frameworks, can be more easily replaced without widespread impact. Todd Biske, Nick Malik and others have commented on SOA and why reuse doesn't ever seem to materialize in any meaningful way but haven't necessarily talked about how people need to change to make SOA successful. People, then process, then tools - in that order.
Good solutions to tough change management problems are difficult to discover. It is hard to find stable abstractions when the people who dictate requirements come and go in the organization or act seemingly capriciously. Applying abstractions from math and geometry is much easier because God does not change the rules. However, the Gods of Business flip all over the deck. Business culture is shaped by sales, and selling is generally an "intuitive" discipline. Thus, explicitness is often not expected and not honed by management. I am of the belief that this is the number one impediment to Business/IT alignment and therefore those who pursue alignment will always be banging their head into a brick wall.
Business applications build up "cruft" over time. Business rules tend to keep collecting and collecting until the behavior of the system becomes unpredictable. Nobody wants to risk cleaning it because they are afraid something might break. Or, there may be a business rule in there that solves a problem that the current staff did not know existed. The knowledge of why specific code exists might be lost. Users expect the behavior to be there, and are surprised if it disappears. A programmer might remove something that looked like a bug, to later find out that it actually served an important but undocumented purpose.
Failure to keep the system clean is typical of poor programming practices. The benefits of keeping things clean are numerous, among them are easier programming, less code, more flexible system, and cheaper faster development. However, often there is no financial incentive for a given developer to keep things clean. They are judged from quarter-to-quarter rather than year-to-year and spend more time managing perception than in managing either architectures or code. It may help the company, but the company will often not recognize the effort.
So, you should ask yourself, what should folks do when they become bored with business applications? Unless they work for an Indian outsourcing firm where rotation is built into the culture and actually having real-world experience isn't required nor expected of the client then rotation becomes problematic. Rest and rotation would be nice. The problem is that HR wants gajillion years experience in the target occupation or specialty. That makes it difficult to rotate domains for Americans...
| | View blog reactionsBusiness applications include billing, tracking equipment, people and projects under the guise of governance, custom interactive reports, sales forecasting, claims administration, etc. In business applications, one is generally modeling "rules of thumb" rather than intellectually challenging "puzzles" of the type seen in university courses in computer science.
Most folks in charge of business applications have difficulty expressing the rules of thumb. The software developer's job is to help them define and clarify such rules. Business knowledge is often implicitly understood, and it can be difficult for the domain experts to express that knowledge explicitly. This is one of the big challenges of business applications. Unlike university puzzles, the givens to the problems are generally not clear. There is often no easy way to tell if the machine is producing the intended results without having the end user try it for a while.
Sometimes software developers have sufficient expertise and influence to suggest changes in business processes to make them more logical or efficient. Presenting ideas to a business domain expert requires skilful sales technique. Otherwise, you risk coming across as arrogant or pushy. In the business world being liked is often more important than being right, but techies often see the reverse, creating a culture clash of sorts.
- NOTE: I would love for James Tarbell to comment is it more important to be liked or right in an upcoming blog entry without taking the hybrid answer
Usually a business has many nitty-gritty rules and exceptions to rules that require spending significant time and effort to adapt the framework. Copy-and-paste programming often seems easier than trying to make the ultimate generic Thing. Smaller scale abstractions, or micro-frameworks, can be more easily replaced without widespread impact. Todd Biske, Nick Malik and others have commented on SOA and why reuse doesn't ever seem to materialize in any meaningful way but haven't necessarily talked about how people need to change to make SOA successful. People, then process, then tools - in that order.
Good solutions to tough change management problems are difficult to discover. It is hard to find stable abstractions when the people who dictate requirements come and go in the organization or act seemingly capriciously. Applying abstractions from math and geometry is much easier because God does not change the rules. However, the Gods of Business flip all over the deck. Business culture is shaped by sales, and selling is generally an "intuitive" discipline. Thus, explicitness is often not expected and not honed by management. I am of the belief that this is the number one impediment to Business/IT alignment and therefore those who pursue alignment will always be banging their head into a brick wall.
Business applications build up "cruft" over time. Business rules tend to keep collecting and collecting until the behavior of the system becomes unpredictable. Nobody wants to risk cleaning it because they are afraid something might break. Or, there may be a business rule in there that solves a problem that the current staff did not know existed. The knowledge of why specific code exists might be lost. Users expect the behavior to be there, and are surprised if it disappears. A programmer might remove something that looked like a bug, to later find out that it actually served an important but undocumented purpose.
Failure to keep the system clean is typical of poor programming practices. The benefits of keeping things clean are numerous, among them are easier programming, less code, more flexible system, and cheaper faster development. However, often there is no financial incentive for a given developer to keep things clean. They are judged from quarter-to-quarter rather than year-to-year and spend more time managing perception than in managing either architectures or code. It may help the company, but the company will often not recognize the effort.
- NOTE: I give James Tarbell the permission to exercise his right to remain silent on the above comment without guilt. I do wonder if he sees poor programming practices as something that should be of higher priority within large enterprises?
So, you should ask yourself, what should folks do when they become bored with business applications? Unless they work for an Indian outsourcing firm where rotation is built into the culture and actually having real-world experience isn't required nor expected of the client then rotation becomes problematic. Rest and rotation would be nice. The problem is that HR wants gajillion years experience in the target occupation or specialty. That makes it difficult to rotate domains for Americans...
