One of the things that all of us lack to some extent or other is real world experience in something or other. The main reason for this is that the real world this year is not the same as the real world last year or the year before.
There is only one entity that can be all things to all, and to my knowledge that entity doesn't participate directly in IT projects. Therefore, a pragmatic approach to this requirement for the rest of us can be to use the real world experience of others. Which is why history is so valuable lest we continue to make the same mistakes again and again.
In the IT world our history is encapsulated in successful organisations like OpenSource, Oracle, IBM, Microsoft, etc , alongside standards bodies and the standards these organisations contribute towards like ANSII, Prince, ITIL, OMG, UML (See Standards_organizations).
These are the result of many 'real world experiences' being shared to make a common unified real world for all to share and work in, also known as teamwork!
These then lead to validated software and documentation packages that can be used as business (functional - Sales, Finance, Production, Distribution, PerformancePoint Server, etc) and technical (Non Functional - RDBMS's, Object Orientation, The Web, Operating Systems etc) needs solution implementors.
However, we can throw all this away if we do not follow the best practices that are revealed by such historic teamwork.
Therefore, to put a check on deviation from standards we can implement testing. However, as we know it takes as much as three times as long to fix things as to do them properly in the first place. Also, the testing can get a bit tainted by politics.
Therefore, thanks go to MS for their 'MS SQL Server real world experience' gap filler :-
SQL Server Best Practices
Get the real-world guidelines, expert tips, and rock-solid guidance to take your SQL Server implementation to the next level. These SQL Server best practices draw on the extensive experience and expertise from respected developers and engineers at Microsoft, who walk you through the specifics on solving particularly difficult issues.
Ref: http://technet.microsoft.com/en-us/sqlserver/bb331794.aspx
Friday, August 24, 2007
Wednesday, August 22, 2007
Systems do as their 'Logic', or lack of it, dictates
In business there should be little room for illogical systems, otherwise how can these systems be trusted and how can there be continued progress of an organisation as it grows.
Sometimes lack of logical systems can come from speed of expansion of the responsibilities of the people who are supposed to implement the business logic, within the said systems.
At other times the use of illogical methods can be the outcome of old system survival tactics in a developing business environment.
At other times ....
However it occurs, it should not be allowed to contaminate an organisations strategy of survival and expansion, otherwise it can become difficult to interface with the wider business world in a synergistic fashion.
There are tools available to help weed out illogical thinking systems and to ensure that rules implemented within systems are implemented in a fair and unambiguous way, for all customers that interface with a given service supplier.
I came across a company that produces one of these tools as a result of some research I was doing into storing logic in databases as opposed to coding it. Thanks to a reference from one of Joe Celko' articles, Joe Celko offers his sage (if offbeat) advice,
I found a link to the following:-
For Business Analysts: LogicGem Video 1
A demonstration of how to use LogicGem to create a set of business rules and provide business analysts with the confidence that the business rule set is complete. Ref: http://www.catalyst.com/videos/logicgem/index.html
Take a look if you want to do things properly but don't have the time. Also have a look if you don't know what I am harping on about. Things may, ?, become clearer as you watch the video.
Sometimes lack of logical systems can come from speed of expansion of the responsibilities of the people who are supposed to implement the business logic, within the said systems.
At other times the use of illogical methods can be the outcome of old system survival tactics in a developing business environment.
At other times ....
However it occurs, it should not be allowed to contaminate an organisations strategy of survival and expansion, otherwise it can become difficult to interface with the wider business world in a synergistic fashion.
There are tools available to help weed out illogical thinking systems and to ensure that rules implemented within systems are implemented in a fair and unambiguous way, for all customers that interface with a given service supplier.
I came across a company that produces one of these tools as a result of some research I was doing into storing logic in databases as opposed to coding it. Thanks to a reference from one of Joe Celko' articles, Joe Celko offers his sage (if offbeat) advice,
I found a link to the following:-
For Business Analysts: LogicGem Video 1
A demonstration of how to use LogicGem to create a set of business rules and provide business analysts with the confidence that the business rule set is complete. Ref: http://www.catalyst.com/videos/logicgem/index.html
Take a look if you want to do things properly but don't have the time. Also have a look if you don't know what I am harping on about. Things may, ?, become clearer as you watch the video.