<?xml version="1.0" encoding="UTF-8"?>
<!--Generated by Squarespace V5 Site Server v5.13.159 (http://www.squarespace.com) on Thu, 23 May 2013 18:24:24 GMT--><?xml-stylesheet type="text/css" href="/universal/styles/feed.css"?><rss version="2.0"><channel><title>Enterprise Architecture Blog - Comments</title><link>http://chiefarchitect.squarespace.com/ea/</link><description></description><copyright></copyright><language>en-US</language><generator>Squarespace V5 Site Server v5.13.159 (http://www.squarespace.com)</generator><item><title>Joshua Millsapps comments on Cutter Report - How to Measure Success: Use EA to Define Architecture</title><author>Joshua Millsapps</author><pubDate>Wed, 22 Aug 2012 18:58:55 +0000</pubDate><link>http://chiefarchitect.squarespace.com/ea/2011/4/1/cutter-report-how-to-measure-success-use-ea-to-define-archit.html#comments</link><guid isPermaLink="false">126280:1130339:comment/18890161</guid><description><![CDATA[<p>I have done some writing around what it takes to get to a successful program with regard to real business value from EA at http://mbaoutcome.blogspot.com/2012/08/enterprise-architecture-and-road-to.html<br/>Essentially, with the idea that EA is supposed to provide you with real intelligence from which you can run your business. I&#39;d love to get your thoughts.</p>]]></description></item><item><title>Alan Inglis comments on The hype cycle vs legacy&amp;hellip;</title><author>Alan Inglis</author><pubDate>Sun, 27 Nov 2011 19:58:22 +0000</pubDate><link>http://chiefarchitect.squarespace.com/ea/2011/5/27/the-hype-cycle-vs-legacyhellip.html#comments</link><guid isPermaLink="false">126280:1130339:comment/16009179</guid><description><![CDATA[<p>Product - it depends on the overall ambition and complexity of the product.  An ERP, for example, has a huge ambition and is highly complex.  Successful implementation is about business transformation.  The interesting thing here is that the scale and complexity is so high that the time to implementation is sometimes longer than the time between major upgrades.  This means that unless organizations implement old versions then the market will never reach maturity.</p>]]></description></item><item><title>Rohit Sharma comments on The hype cycle vs legacy&amp;hellip;</title><author>Rohit Sharma</author><pubDate>Tue, 25 Oct 2011 11:23:29 +0000</pubDate><link>http://chiefarchitect.squarespace.com/ea/2011/5/27/the-hype-cycle-vs-legacyhellip.html#comments</link><guid isPermaLink="false">126280:1130339:comment/15460915</guid><description><![CDATA[<p>I am slightly struggling to understand how this can be applied to &quot;Product&quot; (or systems instead of technologies. This works for technologies but does this apply equally for systems? (COTS or otherwise)</p>]]></description></item><item><title>Robin Kit comments on The over-reaction architecture governance anti-pattern</title><author>Robin Kit</author><pubDate>Fri, 26 Aug 2011 07:55:11 +0000</pubDate><link>http://chiefarchitect.squarespace.com/ea/2010/6/29/the-over-reaction-architecture-governance-anti-pattern.html#comments</link><guid isPermaLink="false">126280:1130339:comment/14889227</guid><description><![CDATA[<p>A good real estate development starts with the right architect. An architect is concerned not only with the concept but also the planning as well as designing of a building or any real estate development.</p><p><a href="http://www.mountfordpigott.com/" rel="nofollow"><b>Mountford Pigott</b></a></p>]]></description></item><item><title>Jigar comments on Enterprise Architecture Tools</title><author>Jigar</author><pubDate>Fri, 19 Aug 2011 17:06:09 +0000</pubDate><link>http://chiefarchitect.squarespace.com/ea/2007/4/27/enterprise-architecture-tools.html#comments</link><guid isPermaLink="false">126280:1130339:comment/14846462</guid><description><![CDATA[<p>There are couple of tools out there which support end to end EA and strong business architecture, have a look at www.alfabet.com. Also have a look at this website which shows the functionality width of different tools http://www.enterprise-architecture.info/EA_Tools.htm</p>]]></description></item><item><title>Paul Helmering comments on The hype cycle vs legacy&amp;hellip;</title><author>Paul Helmering</author><pubDate>Mon, 01 Aug 2011 21:59:11 +0000</pubDate><link>http://chiefarchitect.squarespace.com/ea/2011/5/27/the-hype-cycle-vs-legacyhellip.html#comments</link><guid isPermaLink="false">126280:1130339:comment/14367448</guid><description><![CDATA[<p>I like the topic and means of analysis.  I believe the point identified in the top diagram &quot;This is where you should start over&quot; is too far to the right.  Legacy direction and future roadmaps should be planned prior to that point - the planning and slow migration to the new programs should actually start when &quot;Reality Dawns&quot; or even before (according to risk profile, strategy, and budget of the organization).  This slow approach avoids the huge price tags, but requires some pretty good planning.</p>]]></description></item><item><title>Ajay S Solanki comments on The hype cycle vs legacy&amp;hellip;</title><author>Ajay S Solanki</author><pubDate>Wed, 20 Jul 2011 13:18:15 +0000</pubDate><link>http://chiefarchitect.squarespace.com/ea/2011/5/27/the-hype-cycle-vs-legacyhellip.html#comments</link><guid isPermaLink="false">126280:1130339:comment/13901559</guid><description><![CDATA[<p>I have seen the problem stated in your article with so many company. Inherent organic growth of business and IT doesnt ADOPT to the new growth. The cost of having the cosmetic face lift to the existing IT may be small but it cannot really support the growing business needs. The Adoption Cycle is realy the Key. Good One But Customers Still want to save the dollars</p>]]></description></item><item><title>Stephen Turner comments on The hype cycle vs legacy&amp;hellip;</title><author>Stephen Turner</author><pubDate>Sun, 29 May 2011 10:07:45 +0000</pubDate><link>http://chiefarchitect.squarespace.com/ea/2011/5/27/the-hype-cycle-vs-legacyhellip.html#comments</link><guid isPermaLink="false">126280:1130339:comment/13015170</guid><description><![CDATA[<p>Take the point where you should start over as the beginning of a new hype curve. The hype won&#39;t be as large the second time round as you don&#39;t really have new technology and it&#39;s the same audience that was disappointed last time. But as you have more understanding of the problems there will be lot less disappointment. </p><p>You gain more understanding by doing things over, and end up a lot higher on the chart. On top of that you&#39;ve lost some legacy problems, had a second round of hype which the marketing guys love and have a better product.</p>]]></description></item><item><title>Dan comments on The over-reaction architecture governance anti-pattern</title><author>Dan</author><pubDate>Mon, 02 May 2011 14:49:18 +0000</pubDate><link>http://chiefarchitect.squarespace.com/ea/2010/6/29/the-over-reaction-architecture-governance-anti-pattern.html#comments</link><guid isPermaLink="false">126280:1130339:comment/12785285</guid><description><![CDATA[<p>Yes, &quot;architect&quot; is not a synonym of &quot;creator.&quot;  Architecture is domain dependent--&quot;building architect,&quot; &quot;city architect,&quot; &quot;transportation architect.&quot;  Nor is Architect is the same as &quot;planner&quot; or &quot;engineer.&quot;  Neither is an Architect a hands-on doer.  All these roles seem to surround something that almost cannot be described with precision but surely exists since buildings, bridges, and transportation systems &quot;behave&quot; in characteristic ways that one can identify as a &quot;style.&quot;  Architecture decisions occur at a nexus of alternatives that determine not only the way functionality can be used but cost, safety, and opportunity to use innovative methods and materials.  The exact same business functionality can be &quot;created&quot; in radically different ways due to key differences in key constraints and principles followed.  Then the actual outcome of design and implementation may be &quot;functionally equivalent&quot; to the business depending on environmental factors -- &quot;fitness for use.&quot;  The Architects vision must therefore span both business and technical consideration.  As Zachman points out, this is as it has been for thousands of years in various domains.  But each domain has materials and methods and styles and patterns that must be discovered and mastered.  In Enterprise Architecture we are at the beginning of that learning curve.  Yes, it has been going on in the business world implicitly for many decades, maybe centuries.  But the role of technology is just now being understood.</p>]]></description></item><item><title>heather comments on The over-reaction architecture governance anti-pattern</title><author>heather</author><pubDate>Sun, 15 Aug 2010 01:42:07 +0000</pubDate><link>http://chiefarchitect.squarespace.com/ea/2010/6/29/the-over-reaction-architecture-governance-anti-pattern.html#comments</link><guid isPermaLink="false">126280:1130339:comment/9377399</guid><description><![CDATA[<p>Why do you use the title &#39;architect&#39;?  I dont see any architect here.  I only see computer programmers and business communications.   Architecture has been a profession for a very long time.  It seems like you could come up with a new word for what you do?  I understand the statements like &quot;the architect of an idea or business model, or such&quot;  but, that is metaphor: &#39;architect is creator&#39; .   Using the term architect as a job title is simply incorrect unless you have a degree in architecture and pass the exams after the required years of internship.</p>]]></description></item></channel></rss>