Friday, January 13, 2006
Enterprise Architecture and Changing the Burden of Proof
Yesterday, I had an interesting conversation with an architect that used to work at the Fortune 100 enterprise across the street from us. He observed that one problem enterprise architects consistently face is that they have to convince folks of the obvious.
Within many enterprises, a good idea can get shot down simply because the person bringing the idea to the table either doesn't have enough time to evangelize it or simply has thrown in the towel. The enterprise should never eschew good ideas because of this practice and therefore should as part of its enterprise architecture efforts take the necessary steps to shift the burden of proof.
It's important to differentiate the burden of proof from establishing it in the first place. One's "adversary" does not have the burden of proof simply because their otherwise senseless preconceptions are socially approved. One should assume that what is commonly accepted is the starting point for all debate. If the starting point isn't logical then trying to defend an illogical position with logic won't work too well and therefore one should take a different approach.
Some may approach this problem space with an argument that shows just how far-fetched someone's belief is. By pointing out that the other person has not established their own burden of proof sometimes work but still doesn't mean you have meet your own burden of proof and therefore still have failed.
Others have made the mistake of thinking that the burden of proof actually has anything to do with logic. For example, within an enterprise one may think that large enterprises aren't using open source in production environments and even contributing to it simply because they aren't reading about it in Infoworld or the industry analysts aren't covering this important research. If the vast majority of the folks in the enterprise believe that analysts are telling the entire story then that doesn't change the claim that their lack of coverage is any less absurd. If one were to use strictly logic, then it wouldn't matter whether one's claim is the status quo nor whose claim is more popular.
The burden of proof rests upon those who seek change. After all, one man's enlightenment is another's ignorance (Don't go off attempting to quantify this). If one makes a statement, one needs to be prepared to explain and justify the statement. Unless the meaning of and context for the statement are absolutely clear, there cannot be a "burden of proof" on others attempting to understand the statement. Questioning a statement does not imply disagreement; only lack of understanding can be inferred. It is not the responsibility of the questioner to prove the initial statement is incorrect, it is the responsibility of the initiator to show how, when, and why his statement would be correct.
Sometimes proof comes in the form of Rationalization but hopefully many wise enterprise architects understand that Rationalization is a trap!. Within the enterprise, folks on an almost daily basis are rationalizing why they should keep legacy systems, outsource or spend lots of money on closed source proprietary software when the same thing can be acquired cheaply from the open source community.
Several weeks ago, I got into an interesting conversation with a peer who also happens to be a computer science professor at a prominent university. My personal position is that he is not teaching computer science but in all reality is teaching a history course. Likewise I believe that there is no such thing as computer science and it is a fraud. Logically speaking, for something to be a science it should have measurable metrics. Likewise, it should also have a consistent body of knowledge.
If you are of the project management mindset, you may have noticed that they have a Project Management Body of Knowledge which satisfies the first aspect of being a science. Of course many folks will also not acknowledge that while many project managers may be within an IT organization that in all reality they are not IT professionals.
Imagine an industry conference held by Infoworld where there is a panel being moderated by Jon Udell on the topic of how software should be developed and it featured Richard Stallman, Kent Beck, Bill Gates and a member of CMMI. Not only would they not agree on best way to develop software, they would within minutes disprove all currently existing software engineering bodies of knowledge. The real question is how would burden of proof work here...
| | View blog reactionsWithin many enterprises, a good idea can get shot down simply because the person bringing the idea to the table either doesn't have enough time to evangelize it or simply has thrown in the towel. The enterprise should never eschew good ideas because of this practice and therefore should as part of its enterprise architecture efforts take the necessary steps to shift the burden of proof.
It's important to differentiate the burden of proof from establishing it in the first place. One's "adversary" does not have the burden of proof simply because their otherwise senseless preconceptions are socially approved. One should assume that what is commonly accepted is the starting point for all debate. If the starting point isn't logical then trying to defend an illogical position with logic won't work too well and therefore one should take a different approach.
Some may approach this problem space with an argument that shows just how far-fetched someone's belief is. By pointing out that the other person has not established their own burden of proof sometimes work but still doesn't mean you have meet your own burden of proof and therefore still have failed.
Others have made the mistake of thinking that the burden of proof actually has anything to do with logic. For example, within an enterprise one may think that large enterprises aren't using open source in production environments and even contributing to it simply because they aren't reading about it in Infoworld or the industry analysts aren't covering this important research. If the vast majority of the folks in the enterprise believe that analysts are telling the entire story then that doesn't change the claim that their lack of coverage is any less absurd. If one were to use strictly logic, then it wouldn't matter whether one's claim is the status quo nor whose claim is more popular.
The burden of proof rests upon those who seek change. After all, one man's enlightenment is another's ignorance (Don't go off attempting to quantify this). If one makes a statement, one needs to be prepared to explain and justify the statement. Unless the meaning of and context for the statement are absolutely clear, there cannot be a "burden of proof" on others attempting to understand the statement. Questioning a statement does not imply disagreement; only lack of understanding can be inferred. It is not the responsibility of the questioner to prove the initial statement is incorrect, it is the responsibility of the initiator to show how, when, and why his statement would be correct.
Sometimes proof comes in the form of Rationalization but hopefully many wise enterprise architects understand that Rationalization is a trap!. Within the enterprise, folks on an almost daily basis are rationalizing why they should keep legacy systems, outsource or spend lots of money on closed source proprietary software when the same thing can be acquired cheaply from the open source community.
Several weeks ago, I got into an interesting conversation with a peer who also happens to be a computer science professor at a prominent university. My personal position is that he is not teaching computer science but in all reality is teaching a history course. Likewise I believe that there is no such thing as computer science and it is a fraud. Logically speaking, for something to be a science it should have measurable metrics. Likewise, it should also have a consistent body of knowledge.
If you are of the project management mindset, you may have noticed that they have a Project Management Body of Knowledge which satisfies the first aspect of being a science. Of course many folks will also not acknowledge that while many project managers may be within an IT organization that in all reality they are not IT professionals.
Imagine an industry conference held by Infoworld where there is a panel being moderated by Jon Udell on the topic of how software should be developed and it featured Richard Stallman, Kent Beck, Bill Gates and a member of CMMI. Not only would they not agree on best way to develop software, they would within minutes disprove all currently existing software engineering bodies of knowledge. The real question is how would burden of proof work here...
