<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Down With the Uber-Repository, Long Live Metadata Marts!</title>
	<atom:link href="http://blogs.gartner.com/michael_blechar/2009/04/08/down-with-the-uber-repository-long-live-metadata-marts/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.gartner.com/michael_blechar/2009/04/08/down-with-the-uber-repository-long-live-metadata-marts/</link>
	<description>A Member of the Gartner Blog Network</description>
	<lastBuildDate>Fri, 11 Nov 2011 10:04:17 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Master Metadata Management</title>
		<link>http://blogs.gartner.com/michael_blechar/2009/04/08/down-with-the-uber-repository-long-live-metadata-marts/comment-page-1/#comment-61</link>
		<dc:creator>Master Metadata Management</dc:creator>
		<pubDate>Sat, 31 Oct 2009 20:39:30 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gartner.com/michael_blechar/2009/04/08/down-with-the-uber-repository-long-live-metadata-marts/#comment-61</guid>
		<description>[...] received a response to my blog entitled “Down With the Uber-Repository, Long Live Metadata!” criticizing my recommendation to not try to consolidate all your metadata into one [...]</description>
		<content:encoded><![CDATA[<p>[...] received a response to my blog entitled “Down With the Uber-Repository, Long Live Metadata!” criticizing my recommendation to not try to consolidate all your metadata into one [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Luciano Quadraccia</title>
		<link>http://blogs.gartner.com/michael_blechar/2009/04/08/down-with-the-uber-repository-long-live-metadata-marts/comment-page-1/#comment-59</link>
		<dc:creator>Luciano Quadraccia</dc:creator>
		<pubDate>Wed, 21 Oct 2009 23:43:40 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gartner.com/michael_blechar/2009/04/08/down-with-the-uber-repository-long-live-metadata-marts/#comment-59</guid>
		<description>I vigorously disagree.  

re: &quot;one huge “uber-repository” failed miserably&quot; 

that is not true for us at all.  We have been extremely successful.   Since the late 80&#039;s we have placed considerable metadata and all change management for our mainframe systems in a single repository. 

However, in the last decade, as our systems started expanding outside the mainframe they did not continue to use the &quot;uber repository&quot; for their metadata.  As a result these systems have a variety of problems that do not exist at all with the mainframe systems.

The reason why these systems do not use the repository is that the repository team has been starved of funds and the opportunity to extend the repository to hold the new structures, utilities and interfaces required by the new technologies.

And the reason why this is happend is because of the poor understanding of what can be achieved with metadata, particularly when it is centralised.

Articles like this perpetuate this misunderstanding, and encourage our management to starve repository enhancement projects to the point where we no longer have people even thinking about this issue.  

Thank You
Luciano</description>
		<content:encoded><![CDATA[<p>I vigorously disagree.  </p>
<p>re: &#8220;one huge “uber-repository” failed miserably&#8221; </p>
<p>that is not true for us at all.  We have been extremely successful.   Since the late 80&#8242;s we have placed considerable metadata and all change management for our mainframe systems in a single repository. </p>
<p>However, in the last decade, as our systems started expanding outside the mainframe they did not continue to use the &#8220;uber repository&#8221; for their metadata.  As a result these systems have a variety of problems that do not exist at all with the mainframe systems.</p>
<p>The reason why these systems do not use the repository is that the repository team has been starved of funds and the opportunity to extend the repository to hold the new structures, utilities and interfaces required by the new technologies.</p>
<p>And the reason why this is happend is because of the poor understanding of what can be achieved with metadata, particularly when it is centralised.</p>
<p>Articles like this perpetuate this misunderstanding, and encourage our management to starve repository enhancement projects to the point where we no longer have people even thinking about this issue.  </p>
<p>Thank You<br />
Luciano</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Blechar</title>
		<link>http://blogs.gartner.com/michael_blechar/2009/04/08/down-with-the-uber-repository-long-live-metadata-marts/comment-page-1/#comment-15</link>
		<dc:creator>Michael Blechar</dc:creator>
		<pubDate>Sun, 26 Apr 2009 13:40:03 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gartner.com/michael_blechar/2009/04/08/down-with-the-uber-repository-long-live-metadata-marts/#comment-15</guid>
		<description>Yes, increased attention to metadata management raises governance issues - frequently invovling sensitive politically and cultural biases within the organization - which can both slow down the metadata management initiative or jeapordize it. Therefore selecting the &quot;right&quot; metadata to manage frequently must take a pragmatic approach to what can be done successfully given the specific organizational constraints for goveranance.

I address Jeff&#039;s excellent comments in my recernt post of Data Dictionaries....</description>
		<content:encoded><![CDATA[<p>Yes, increased attention to metadata management raises governance issues &#8211; frequently invovling sensitive politically and cultural biases within the organization &#8211; which can both slow down the metadata management initiative or jeapordize it. Therefore selecting the &#8220;right&#8221; metadata to manage frequently must take a pragmatic approach to what can be done successfully given the specific organizational constraints for goveranance.</p>
<p>I address Jeff&#8217;s excellent comments in my recernt post of Data Dictionaries&#8230;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Pryslak</title>
		<link>http://blogs.gartner.com/michael_blechar/2009/04/08/down-with-the-uber-repository-long-live-metadata-marts/comment-page-1/#comment-10</link>
		<dc:creator>Jeff Pryslak</dc:creator>
		<pubDate>Tue, 14 Apr 2009 17:23:35 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gartner.com/michael_blechar/2009/04/08/down-with-the-uber-repository-long-live-metadata-marts/#comment-10</guid>
		<description>Metadata Collection...  
for every time i hear that phrase, i can think of two times where customers are thinking that it is an additional project beyond creating a system.  While this might be true in some cases, the one you point out here, data analyst capturing information on the data architecture, is something that is built into most data architecture tools now.  
If an IT department goes through the steps of properly architecting the use of their data, the end result is a rich set of metadata that spans the Physical Data, Conceptual Data, Business Process Data, Application Data, etc...  The metadata captured in this architecture process should be linked to a Data Dictionary or Business Glossary.  The really useful metadata here comes from reivewing how the data is used in every one of these architecture diagrams and any additional comments gathered along the way to justify why a set of data is used, and for what result.

In the end, data about the information in a business is where metadata always starts, and typically stays, due to the effort beyond that sphere.

i need to read the SOA/BP paper, that is an area that a few of my customers have delved unsuccessfully in the past few years.  Not meeting re-use goals, undefined processes, missing schema source information, in ability to shift existing processes with business changes... this list goes on and on, and metadata about the information is always the first place they turn.

Look forward to an article on how &#039;Marts Meet&#039; or the &#039;Mart Broker&#039; for getting federated answers.</description>
		<content:encoded><![CDATA[<p>Metadata Collection&#8230;<br />
for every time i hear that phrase, i can think of two times where customers are thinking that it is an additional project beyond creating a system.  While this might be true in some cases, the one you point out here, data analyst capturing information on the data architecture, is something that is built into most data architecture tools now.<br />
If an IT department goes through the steps of properly architecting the use of their data, the end result is a rich set of metadata that spans the Physical Data, Conceptual Data, Business Process Data, Application Data, etc&#8230;  The metadata captured in this architecture process should be linked to a Data Dictionary or Business Glossary.  The really useful metadata here comes from reivewing how the data is used in every one of these architecture diagrams and any additional comments gathered along the way to justify why a set of data is used, and for what result.</p>
<p>In the end, data about the information in a business is where metadata always starts, and typically stays, due to the effort beyond that sphere.</p>
<p>i need to read the SOA/BP paper, that is an area that a few of my customers have delved unsuccessfully in the past few years.  Not meeting re-use goals, undefined processes, missing schema source information, in ability to shift existing processes with business changes&#8230; this list goes on and on, and metadata about the information is always the first place they turn.</p>
<p>Look forward to an article on how &#8216;Marts Meet&#8217; or the &#8216;Mart Broker&#8217; for getting federated answers.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

