<?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: Master Metadata Management</title>
	<atom:link href="http://blogs.gartner.com/michael_blechar/2009/10/31/master-metadata-management/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.gartner.com/michael_blechar/2009/10/31/master-metadata-management/</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: Mike Blechar</title>
		<link>http://blogs.gartner.com/michael_blechar/2009/10/31/master-metadata-management/comment-page-1/#comment-67</link>
		<dc:creator>Mike Blechar</dc:creator>
		<pubDate>Thu, 26 Nov 2009 17:54:13 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gartner.com/michael_blechar/2009/10/31/master-metadata-management/#comment-67</guid>
		<description>We are not in disagreement about the value of metadata management and metadata repositories. However, where we differ is in the scope of use. Historically, two out of every three organizations who attempted to do the scope of metadata management you advise ended up killing the metadata management efforts in the first two years. Of the other third, I would argue that (like your organizations) 98% use their main enterprise repository for only subsets of the total metadata due to the issues involved in broad &quot;all-inclusive&quot; use scenarios.

I&#039;ve written alot of research in the past 16 years at Gartner based on my personal experience in implementing and supporting &quot;uber repositories&quot; at 5 Fortune 1000 companies with management support ranging from limited to wholly committed. But in the end, it comes back to balancing return on investment and risk with cost. While different organizations may draw the line in slightly different places, in the end metadata management (like all other disciplines, including data management) cannot accomodate all enterprise assets. Therefore, it is necessary to decide what is &quot;master metadata&quot; and which is not, and how inter-related the management and reporting of the master metadata ought to be.

For example, I cannot comment on whether your organization made a good or bad decision to have non-mainframe systems be &quot;oustide of the metadata managed in the repository&quot;. But, my expectation would be that some of the mainframe - and some of the distributed - metadata ought to be documented in an integrated way in an enterprise repository and some not. I cannot comment on whether the cost of the problems caused by not documenting the non-mainframe applications you mentioned exceeds the cost of maintaining better information in the repository to cut some of those costs. This is where those responsible for metadata management need to provide the business case to management - but again, a statement that &quot;all mainframe-related metadata&quot; belongs in the repository (to exclude the distributed stuff for now) is not a statement I would support. A more intelligent look at the costs and risks involved for different mainframe metadata ought to be made to come up with a proper metadata management plan. That plan would need to look at whether some of the metadata (and which types) ought to be in a single integrated enterprise repository and which in other more focused repositories or left in the metadata stores of the technologies in which they are defined.

So, my &quot;good for them&quot; statement has more to do with making the most appropriate business decision.....We make these decisions every day of our personal lives in terms of the cost and types d closthes we wear and when to repair our homes and cars and to what degree we spend money on them. So, it should be no surprise metadata management (like all other business functions) ought to not be based on &quot;perfection at a premium cost&quot;, but managed by making sound, responsible business decisions on where to spend the time, effort and cost on metadata management in a selective way.</description>
		<content:encoded><![CDATA[<p>We are not in disagreement about the value of metadata management and metadata repositories. However, where we differ is in the scope of use. Historically, two out of every three organizations who attempted to do the scope of metadata management you advise ended up killing the metadata management efforts in the first two years. Of the other third, I would argue that (like your organizations) 98% use their main enterprise repository for only subsets of the total metadata due to the issues involved in broad &#8220;all-inclusive&#8221; use scenarios.</p>
<p>I&#8217;ve written alot of research in the past 16 years at Gartner based on my personal experience in implementing and supporting &#8220;uber repositories&#8221; at 5 Fortune 1000 companies with management support ranging from limited to wholly committed. But in the end, it comes back to balancing return on investment and risk with cost. While different organizations may draw the line in slightly different places, in the end metadata management (like all other disciplines, including data management) cannot accomodate all enterprise assets. Therefore, it is necessary to decide what is &#8220;master metadata&#8221; and which is not, and how inter-related the management and reporting of the master metadata ought to be.</p>
<p>For example, I cannot comment on whether your organization made a good or bad decision to have non-mainframe systems be &#8220;oustide of the metadata managed in the repository&#8221;. But, my expectation would be that some of the mainframe &#8211; and some of the distributed &#8211; metadata ought to be documented in an integrated way in an enterprise repository and some not. I cannot comment on whether the cost of the problems caused by not documenting the non-mainframe applications you mentioned exceeds the cost of maintaining better information in the repository to cut some of those costs. This is where those responsible for metadata management need to provide the business case to management &#8211; but again, a statement that &#8220;all mainframe-related metadata&#8221; belongs in the repository (to exclude the distributed stuff for now) is not a statement I would support. A more intelligent look at the costs and risks involved for different mainframe metadata ought to be made to come up with a proper metadata management plan. That plan would need to look at whether some of the metadata (and which types) ought to be in a single integrated enterprise repository and which in other more focused repositories or left in the metadata stores of the technologies in which they are defined.</p>
<p>So, my &#8220;good for them&#8221; statement has more to do with making the most appropriate business decision&#8230;..We make these decisions every day of our personal lives in terms of the cost and types d closthes we wear and when to repair our homes and cars and to what degree we spend money on them. So, it should be no surprise metadata management (like all other business functions) ought to not be based on &#8220;perfection at a premium cost&#8221;, but managed by making sound, responsible business decisions on where to spend the time, effort and cost on metadata management in a selective way.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Luciano Quadraccia</title>
		<link>http://blogs.gartner.com/michael_blechar/2009/10/31/master-metadata-management/comment-page-1/#comment-65</link>
		<dc:creator>Luciano Quadraccia</dc:creator>
		<pubDate>Wed, 25 Nov 2009 21:44:42 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gartner.com/michael_blechar/2009/10/31/master-metadata-management/#comment-65</guid>
		<description>Oh, one more point - let me reiterate from my first comment:

&quot;as our systems started expanding outside the mainframe they did not continue to use the “uber repository” for their metadata.  As a result these systems have a variety of problems that do not exist at all with the mainframe systems&quot;

So, the new systems that do not use the uber repository have certain problems, the old-style systems that do use the repository do not, and you say &quot;good for them&quot;  ???</description>
		<content:encoded><![CDATA[<p>Oh, one more point &#8211; let me reiterate from my first comment:</p>
<p>&#8220;as our systems started expanding outside the mainframe they did not continue to use the “uber repository” for their metadata.  As a result these systems have a variety of problems that do not exist at all with the mainframe systems&#8221;</p>
<p>So, the new systems that do not use the uber repository have certain problems, the old-style systems that do use the repository do not, and you say &#8220;good for them&#8221;  ???</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Luciano Quadraccia</title>
		<link>http://blogs.gartner.com/michael_blechar/2009/10/31/master-metadata-management/comment-page-1/#comment-64</link>
		<dc:creator>Luciano Quadraccia</dc:creator>
		<pubDate>Wed, 25 Nov 2009 17:02:23 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gartner.com/michael_blechar/2009/10/31/master-metadata-management/#comment-64</guid>
		<description>re : The first and more fundamental question needs to be “which metadata needs to be managed, and with what degree of rigor”. 

yes, agree, but the answer is that all metadata that is needed to build a system must be recorded and managed.  Because that metadata represents the specifications of the system. 

All such metadata is best placed into the same tool - so that the relationships can be made explicit in formal data structures.

If developers now build the system based on the metadata then there is no question about whether the metadata is right.  The metadata reflects the system. Particularly if tools are used to automate construction of (parts of) the system.

Why on earth would one choose to scatter such metadata? The only reason I can think of is where the repositories are not capable.

So, instead we should be encouraging vendors to build capable repositories.

And, because such metadata must be created during the application development phase, it must be subjected to the same version control and configuration management processes as source code.  Generally, metadata repositories have much weaker version control facilities than regular Version Control Systems, eg they are weak in branching and merging, whereas Version Control Systems usually only deal with files, ie cannot deal with metadata.</description>
		<content:encoded><![CDATA[<p>re : The first and more fundamental question needs to be “which metadata needs to be managed, and with what degree of rigor”. </p>
<p>yes, agree, but the answer is that all metadata that is needed to build a system must be recorded and managed.  Because that metadata represents the specifications of the system. </p>
<p>All such metadata is best placed into the same tool &#8211; so that the relationships can be made explicit in formal data structures.</p>
<p>If developers now build the system based on the metadata then there is no question about whether the metadata is right.  The metadata reflects the system. Particularly if tools are used to automate construction of (parts of) the system.</p>
<p>Why on earth would one choose to scatter such metadata? The only reason I can think of is where the repositories are not capable.</p>
<p>So, instead we should be encouraging vendors to build capable repositories.</p>
<p>And, because such metadata must be created during the application development phase, it must be subjected to the same version control and configuration management processes as source code.  Generally, metadata repositories have much weaker version control facilities than regular Version Control Systems, eg they are weak in branching and merging, whereas Version Control Systems usually only deal with files, ie cannot deal with metadata.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: uberVU - social comments</title>
		<link>http://blogs.gartner.com/michael_blechar/2009/10/31/master-metadata-management/comment-page-1/#comment-63</link>
		<dc:creator>uberVU - social comments</dc:creator>
		<pubDate>Sun, 01 Nov 2009 20:48:21 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gartner.com/michael_blechar/2009/10/31/master-metadata-management/#comment-63</guid>
		<description>&lt;strong&gt;Social comments and analytics for this post...&lt;/strong&gt;

This post was mentioned on Twitter by Barbra5510: Master Metadata Management: Different business opportunities and threats ought to factor heavily into the decis.. http://bit.ly/1YrsLU...</description>
		<content:encoded><![CDATA[<p><strong>Social comments and analytics for this post&#8230;</strong></p>
<p>This post was mentioned on Twitter by Barbra5510: Master Metadata Management: Different business opportunities and threats ought to factor heavily into the decis.. <a href="http://bit.ly/1YrsLU.." rel="nofollow">http://bit.ly/1YrsLU..</a>.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

