Environmental Constraints, Business Requirements, and Implementation Details
Environmental constraints often play a big part in an application's architecture. Although we like to pretend the slate is wide open with possibilities for implementing users requests, it would be naïve to ignore the technical, political, and user environment constraints always present on any decent size project.
If you cannot communicate those constraints effectively you are doing the users a disservice. It is usually the harder road to take, which is not uncommon, doing the right thing always takes much more of an effort. The excuses to do the wrong thing we hear quite often are that "we do not say no to the user", or "the user is always right", or "it is a business requirement".
If I am not careful, the perception I often end up with of the architect, analyst, developer, or project manager that always gives into user requests that violate environmental constraints is that they are lazy, or just "Yes" men or women. Usual it is just plain old lack of experience.
To tell the difference between a Business Requirement and an Implementation Detail requires experience. Often times experience can only be gained through proof of concepts, especially in today's world of ever changing technologies.
A recent example was a request we had for ad-hoc reports to be implemented on an architecture we were putting together. The user requirements were completely lacking for the reports, so the conclusion the analyst team reached was they will deliver ad-hoc reports. They sold it to upper management as a business requirement. The technical solution would be easy to implement using SSRS Report Modeler and Report Builder.
The problem with what they sold was that the environment constraints they will be delivering into will make the mission practically impossible to deliver. An easy solution if you ignore your environment. I can stay in the water for days in 4 feet of water, that is a different story in 12 ft of water.
Political, security, and technical constraints will drag the initiative under. We warned them several times that they should not go down the ad-hoc reporting path, but to no avail. We told them just to do it the hard way and meet with the users and gather the business requirements for the reports. The answer was no, this is now a business requirement.
The one major downfall of the analyst team was they refused to accept that the reports were the business requirement, not the ad-hoc reports. Using the ad-hoc tools is an implementation detail, and an implementation detail should never be considered a business requirement.
The system I am referring to has one of the smallest sets of reporting business requirements I have come across in a very long time, and it will end up being one of the most complex and confusing implementations I have ever seen. How do I know? It is that experience thing I mentioned earlier. It is not that I am smarter than anyone else, it is just that I have seen it tried before and fail to happen in this environment several times.
If you cannot communicate those constraints effectively you are doing the users a disservice. It is usually the harder road to take, which is not uncommon, doing the right thing always takes much more of an effort. The excuses to do the wrong thing we hear quite often are that "we do not say no to the user", or "the user is always right", or "it is a business requirement".
If I am not careful, the perception I often end up with of the architect, analyst, developer, or project manager that always gives into user requests that violate environmental constraints is that they are lazy, or just "Yes" men or women. Usual it is just plain old lack of experience.
To tell the difference between a Business Requirement and an Implementation Detail requires experience. Often times experience can only be gained through proof of concepts, especially in today's world of ever changing technologies.
A recent example was a request we had for ad-hoc reports to be implemented on an architecture we were putting together. The user requirements were completely lacking for the reports, so the conclusion the analyst team reached was they will deliver ad-hoc reports. They sold it to upper management as a business requirement. The technical solution would be easy to implement using SSRS Report Modeler and Report Builder.
The problem with what they sold was that the environment constraints they will be delivering into will make the mission practically impossible to deliver. An easy solution if you ignore your environment. I can stay in the water for days in 4 feet of water, that is a different story in 12 ft of water.
Political, security, and technical constraints will drag the initiative under. We warned them several times that they should not go down the ad-hoc reporting path, but to no avail. We told them just to do it the hard way and meet with the users and gather the business requirements for the reports. The answer was no, this is now a business requirement.
The one major downfall of the analyst team was they refused to accept that the reports were the business requirement, not the ad-hoc reports. Using the ad-hoc tools is an implementation detail, and an implementation detail should never be considered a business requirement.
The system I am referring to has one of the smallest sets of reporting business requirements I have come across in a very long time, and it will end up being one of the most complex and confusing implementations I have ever seen. How do I know? It is that experience thing I mentioned earlier. It is not that I am smarter than anyone else, it is just that I have seen it tried before and fail to happen in this environment several times.
posted by tadanderson at 10:41 AM
0 Comments:
Post a Comment
<< Home