<?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: Squaring the MDM circle</title>
	<atom:link href="http://andyonsoftware.com/2008/04/squaring-the-mdm-circle/feed/" rel="self" type="application/rss+xml" />
	<link>http://andyonsoftware.com/2008/04/squaring-the-mdm-circle/</link>
	<description>Andy Hayler, founder of Kalido and The Information Difference, gives his views on the enterprise software market. Issues covered include data warehousing, master data management, business intelligence and data quality.</description>
	<lastBuildDate>Fri, 12 Aug 2011 09:22:13 +0200</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Ad</title>
		<link>http://andyonsoftware.com/2008/04/squaring-the-mdm-circle/comment-page-1/#comment-73506</link>
		<dc:creator>Ad</dc:creator>
		<pubDate>Thu, 10 Apr 2008 13:54:44 +0000</pubDate>
		<guid isPermaLink="false">http://andyonsoftware.com/2008/04/squaring-the-mdm-circle/#comment-73506</guid>
		<description>This is a real â€˜chicken and eggâ€™ problem in any somewhat larger organization. Business governance is often shared across and within several functional and/or geographical business units. Each of these units has its own needs, agenda en funds. IT and especially Corporate IT and more in special people with a vague (in the eyes of the business) function as Enterprise Architect are at least partly but more often largely disconnected of the business world (or vice versa). So yes, indeed you should try to develop some â€˜grand designâ€™, but probably the main requirement for such a grand design is the ability to deal with change and (evolutionary) development of requirements. Deliver and deliver fast in line with actual requirements is key to build confidence in your good intentions. Your attitude should be looking for â€œthe yes reasonsâ€ and ways to cooperate and not looking for â€œthe no reasonsâ€ to wait , delay or do it really different.</description>
		<content:encoded><![CDATA[<p>This is a real â€˜chicken and eggâ€™ problem in any somewhat larger organization. Business governance is often shared across and within several functional and/or geographical business units. Each of these units has its own needs, agenda en funds. IT and especially Corporate IT and more in special people with a vague (in the eyes of the business) function as Enterprise Architect are at least partly but more often largely disconnected of the business world (or vice versa). So yes, indeed you should try to develop some â€˜grand designâ€™, but probably the main requirement for such a grand design is the ability to deal with change and (evolutionary) development of requirements. Deliver and deliver fast in line with actual requirements is key to build confidence in your good intentions. Your attitude should be looking for â€œthe yes reasonsâ€ and ways to cooperate and not looking for â€œthe no reasonsâ€ to wait , delay or do it really different.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

