Archives of the TeradataForum

Message Posted: Fri, 18 Nov 2005 @ 16:33:48 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

<-- Anonymously Posted: Friday, November 18, 2005 11:06 -->

What we have are two separate issues.

The first one is, how can an organization DOCUMENT their enterprise data as well as the processes that act against it in a manner that is efficient, organized, portable, and platform independent?

The other issue is, which mechanisms can be used by an organization to IMPLEMENT those data architectures and business processes in a manner that is efficient, organized, portable, and platform independent?

I advocate what is best for the organization and the greater good, not what's best for a DBA or a Software Developer. Those two folks come and go as they migrate to greener pastures in their never ending pursuit of happiness and the mighty buck. When they leave all their wonderful efficient work stays buried in the guts of the database where it's hard to document, share, and perform basic configuration management tasks.

Take a look around your organization and see how well it rates around those two issues I framed (DOCUMENT & IMPLEMENT). You shall discover it has nothing to do with SPs or Macros as being efficient vehicles to take advantage of a particular platform. The higher the coupling between the implementation vehicles and the platform, the more difficult it will be to move upward or migrate to better solutions. The real return on the organization's investment is not measured on CPU seconds or best use of a particular machine, but on how well the organization captures, analyzes, documents, shares, and implements data and business processes. Efficient solutions are fine if you are a college student trying to impress fellow students and the professors, but when it comes to real business what matters are data and process documentation as well as their proper implementation in a manner that is simple and maintainable by the average developer. Embedding business rules in SPs/Macros that no one can clearly see, document, share, or put through basic configuration management tasks is not in line with those goals.

The objectives of a developer are different from the objectives of the folks charged with the proper management of the IT organization. From the developer's point of view, success is measured in how many lines of code were used and how fast the solution is, hence their love for SPs and Macros, but from the management point of view, success is measured on the proper data and process stewardship and the ways in which to carry those two (i.e., the efficient management, documentation, communication, and implementation of enterprise data and business processes).

In my previous engagement I was charged with helping a group document their data architecture dealing mostly with financial transactions. The group was uncooperative at first but after a few sessions they saw the value of properly documenting their database in a CASE tool. Suddenly their system became an abstract representation depicting their business rules with descriptions, domains, values, and definitions. They no longer had to answer the same question presented to them by different people that wanted to integrate with their database. They could now refer them to their enterprise model and pinpoint the data pieces and rules that applied to them. The same is also possible with processes if done correctly.

I guess it's all a matter of perspective. I like the 10 mile view and some like the 200 foot view. That's why I am not a proponent of using SP's and Macros for the implementation of anything that is related to the business and thus relegate them to the DBA staff to discharge their DB maintenance duties. If a better mouse trap is developed tomorrow, I want my organization to be in a position where the decision to make the move is not constrained by hundreds of whiz-bang efficient parallel solutions hidden all over the place in SPs and Macros. I already witnessed first hand one organization's inability to make the move when they outgrew their RDBMS because practically everything was coded in the name of efficiency through SPs and proprietary extensions to SQL and procedural language. Simply stated, the ROI on their initial decision made years ago to use SPs is paying very poorly today.

Anonym

	<Prev	Next>		<<First	<Prev	Next>	Last>>