<?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 for Generating Value Through Information Architecture</title>
	<atom:link href="http://archvalue.com/?feed=comments-rss2" rel="self" type="application/rss+xml" />
	<link>http://archvalue.com</link>
	<description>Architecting is NOT a verb</description>
	<lastBuildDate>Fri, 18 May 2012 12:51:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>Comment on You can&#8217;t deploy an Enterprise Architecture by David</title>
		<link>http://archvalue.com/you-cant-deploy-an-enterprise-architecture/#comment-398</link>
		<dc:creator>David</dc:creator>
		<pubDate>Fri, 18 May 2012 12:51:00 +0000</pubDate>
		<guid isPermaLink="false">http://archvalue.com/?p=254#comment-398</guid>
		<description>Now you see my point!  ALL Software Architecture is not deployable.  It&#039;s all on paper (figuratively) and the only thing you &#039;implement&#039; is the software that &lt;i&gt;conforms&lt;/i&gt; to the architecture.</description>
		<content:encoded><![CDATA[<p>Now you see my point!  ALL Software Architecture is not deployable.  It&#8217;s all on paper (figuratively) and the only thing you &#8216;implement&#8217; is the software that <i>conforms</i> to the architecture.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on You can&#8217;t deploy an Enterprise Architecture by Kyle Gabhart</title>
		<link>http://archvalue.com/you-cant-deploy-an-enterprise-architecture/#comment-397</link>
		<dc:creator>Kyle Gabhart</dc:creator>
		<pubDate>Fri, 18 May 2012 12:45:37 +0000</pubDate>
		<guid isPermaLink="false">http://archvalue.com/?p=254#comment-397</guid>
		<description>You are absolutely right Jacques.  All architecture work is abstraction.  But when you have multiple layers of abstraction, that&#039;s where things get interesting.  So many organizations don&#039;t recognize the fact that EA and SA can easily go off track because they are actually just the sum of the TA parts.  TA is all the way down at the 1-to-1 level of correlation with a physically implemented change in the enterprise.  This is significant.  I have seen so many really good EA and SA roadmaps get obliterated because the collection of TA pieces (each with its own individual stakeholder and stakeholder groups) were going off in whatever direction best suited that particular stakeholder group.  It&#039;s kind of like taking care of the environment.  When one person litters or dumps waste, or generates pollution in some form it is hard to see what all the fuss is about.  It&#039;s only in the aggregate when you appreciate the impact.  EA and SA only have impact to the extent that they are applied in such a way as to constrain and direct the various TA designs that ultimately get implemented.  Everything else is just pretty pictures and hand-waving.</description>
		<content:encoded><![CDATA[<p>You are absolutely right Jacques.  All architecture work is abstraction.  But when you have multiple layers of abstraction, that&#8217;s where things get interesting.  So many organizations don&#8217;t recognize the fact that EA and SA can easily go off track because they are actually just the sum of the TA parts.  TA is all the way down at the 1-to-1 level of correlation with a physically implemented change in the enterprise.  This is significant.  I have seen so many really good EA and SA roadmaps get obliterated because the collection of TA pieces (each with its own individual stakeholder and stakeholder groups) were going off in whatever direction best suited that particular stakeholder group.  It&#8217;s kind of like taking care of the environment.  When one person litters or dumps waste, or generates pollution in some form it is hard to see what all the fuss is about.  It&#8217;s only in the aggregate when you appreciate the impact.  EA and SA only have impact to the extent that they are applied in such a way as to constrain and direct the various TA designs that ultimately get implemented.  Everything else is just pretty pictures and hand-waving.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on You can&#8217;t deploy an Enterprise Architecture by Jacques Cayuela</title>
		<link>http://archvalue.com/you-cant-deploy-an-enterprise-architecture/#comment-396</link>
		<dc:creator>Jacques Cayuela</dc:creator>
		<pubDate>Fri, 18 May 2012 12:27:41 +0000</pubDate>
		<guid isPermaLink="false">http://archvalue.com/?p=254#comment-396</guid>
		<description>TA is also an abstraction.
What is deployed is not the architecture itself but physical components result of th architecture design and following work.

An Enterprise Architect defines logical components and services, and their relationships
As Nick says &quot;processes, information, ..&quot;

Example with marketing capability : 
If you consider a Maketing Business capability,  a logical component &quot;Marketing Business Function&quot; is defined. What will be deployed is a &quot;Marketing Organisation Unit&quot; with a team of marketing people that are actors with marketing skillset that play marketing roles.
So the  physical components are  not only  IT components (if there are, as already said).

At technology level, with a logical Component &quot;Web Server&quot;,
the corresponding physical component you deploy could be  &quot;Apache Web Server&quot;.

You can&#039;t deploy an architecture whatever the architecture : Enterprise,  Solution , technology,  ... you deploy a result of your architecture work (some artefacts are not deployed directly).</description>
		<content:encoded><![CDATA[<p>TA is also an abstraction.<br />
What is deployed is not the architecture itself but physical components result of th architecture design and following work.</p>
<p>An Enterprise Architect defines logical components and services, and their relationships<br />
As Nick says &#8220;processes, information, ..&#8221;</p>
<p>Example with marketing capability :<br />
If you consider a Maketing Business capability,  a logical component &#8220;Marketing Business Function&#8221; is defined. What will be deployed is a &#8220;Marketing Organisation Unit&#8221; with a team of marketing people that are actors with marketing skillset that play marketing roles.<br />
So the  physical components are  not only  IT components (if there are, as already said).</p>
<p>At technology level, with a logical Component &#8220;Web Server&#8221;,<br />
the corresponding physical component you deploy could be  &#8220;Apache Web Server&#8221;.</p>
<p>You can&#8217;t deploy an architecture whatever the architecture : Enterprise,  Solution , technology,  &#8230; you deploy a result of your architecture work (some artefacts are not deployed directly).</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on You can&#8217;t deploy an Enterprise Architecture by Satish Kumar</title>
		<link>http://archvalue.com/you-cant-deploy-an-enterprise-architecture/#comment-394</link>
		<dc:creator>Satish Kumar</dc:creator>
		<pubDate>Thu, 17 May 2012 20:33:00 +0000</pubDate>
		<guid isPermaLink="false">http://archvalue.com/?p=254#comment-394</guid>
		<description>I think the work implementation has different interpretations here. When you talk about interpretation it seems like you only talk about the actual software running on some hardware. The implementation of an EA are the documentation artifacts that then act as the drivers for a proper SA architecture. So you can say you implement an EA by documenting how your vision is being followed or can be followed by different SA&#039;s which in turn can be &quot;implemented&quot; in a TA.</description>
		<content:encoded><![CDATA[<p>I think the work implementation has different interpretations here. When you talk about interpretation it seems like you only talk about the actual software running on some hardware. The implementation of an EA are the documentation artifacts that then act as the drivers for a proper SA architecture. So you can say you implement an EA by documenting how your vision is being followed or can be followed by different SA&#8217;s which in turn can be &#8220;implemented&#8221; in a TA.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on You can&#8217;t deploy an Enterprise Architecture by Kyle Gabhart</title>
		<link>http://archvalue.com/you-cant-deploy-an-enterprise-architecture/#comment-386</link>
		<dc:creator>Kyle Gabhart</dc:creator>
		<pubDate>Wed, 16 May 2012 16:01:35 +0000</pubDate>
		<guid isPermaLink="false">http://archvalue.com/?p=254#comment-386</guid>
		<description>First off, architect&#039;s are paid very good money to split hairs.  It&#039;s what we do. :-)

Secondly, I think that you are missing the primary point here.  EA is an abstraction.  SA is an abstraction.  At the end of the day you only have TA implementations.  The reason this is relevant is two-fold:

1) Your current architecture is the result of the ad-hoc, multi-directional nature of your present set of TA implementations (see the illustration of TA instances that are not aligned with your strategic vision).  Correspondingly, your future architecture will also be a result of your TA implementations (see the related illustration of TA instances that are aligned with your vision).

2) Your ability to shape the direction of the enterprise rises and falls with the degree to which you effectively govern the individual TA implementations that comprise the enterprise landscape.  There is an essential portfolio alignment, coordination, and integration discipline that is needed in order to realize the vision of EA and SA.</description>
		<content:encoded><![CDATA[<p>First off, architect&#8217;s are paid very good money to split hairs.  It&#8217;s what we do. <img src='http://archvalue.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
<p>Secondly, I think that you are missing the primary point here.  EA is an abstraction.  SA is an abstraction.  At the end of the day you only have TA implementations.  The reason this is relevant is two-fold:</p>
<p>1) Your current architecture is the result of the ad-hoc, multi-directional nature of your present set of TA implementations (see the illustration of TA instances that are not aligned with your strategic vision).  Correspondingly, your future architecture will also be a result of your TA implementations (see the related illustration of TA instances that are aligned with your vision).</p>
<p>2) Your ability to shape the direction of the enterprise rises and falls with the degree to which you effectively govern the individual TA implementations that comprise the enterprise landscape.  There is an essential portfolio alignment, coordination, and integration discipline that is needed in order to realize the vision of EA and SA.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on You can&#8217;t deploy an Enterprise Architecture by David</title>
		<link>http://archvalue.com/you-cant-deploy-an-enterprise-architecture/#comment-384</link>
		<dc:creator>David</dc:creator>
		<pubDate>Wed, 16 May 2012 13:04:48 +0000</pubDate>
		<guid isPermaLink="false">http://archvalue.com/?p=254#comment-384</guid>
		<description>Seriously?  You wrote an entire article on splitting hairs?  Why is this worth even discussing when you say you believe in the value of EA?  EA is a framework or guideline to be used when building SA&#039;s or TA&#039;s, but when you deliver a TA&#039;s, aren&#039;t you therefore delivering (or implementing) part of your EA?

David</description>
		<content:encoded><![CDATA[<p>Seriously?  You wrote an entire article on splitting hairs?  Why is this worth even discussing when you say you believe in the value of EA?  EA is a framework or guideline to be used when building SA&#8217;s or TA&#8217;s, but when you deliver a TA&#8217;s, aren&#8217;t you therefore delivering (or implementing) part of your EA?</p>
<p>David</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on You can&#8217;t deploy an Enterprise Architecture by Kyle Gabhart</title>
		<link>http://archvalue.com/you-cant-deploy-an-enterprise-architecture/#comment-381</link>
		<dc:creator>Kyle Gabhart</dc:creator>
		<pubDate>Tue, 15 May 2012 23:34:47 +0000</pubDate>
		<guid isPermaLink="false">http://archvalue.com/?p=254#comment-381</guid>
		<description>You&#039;re preaching to the converted Nick.  I am 100% on board with the perspective of EA that you are articulating.  For the purposes of this post, I was addressing the IT slice of things, but by no means do I consider that to be the totality of architecture.  Business and Data Architecture are domains of EA that should fundamentally be owned and driven by the business.  Application and Technology domains are squarely on the side of IT.

In architecture classes that I teach, I routinely tell people that if you sent an Enterprise Architect and an IT Architect back in time 100 years then the EA would continue to do the same job and the IT Architect would be working on the assembly line to adjust bolts and washers since there would be no use for his or her skillset.</description>
		<content:encoded><![CDATA[<p>You&#8217;re preaching to the converted Nick.  I am 100% on board with the perspective of EA that you are articulating.  For the purposes of this post, I was addressing the IT slice of things, but by no means do I consider that to be the totality of architecture.  Business and Data Architecture are domains of EA that should fundamentally be owned and driven by the business.  Application and Technology domains are squarely on the side of IT.</p>
<p>In architecture classes that I teach, I routinely tell people that if you sent an Enterprise Architect and an IT Architect back in time 100 years then the EA would continue to do the same job and the IT Architect would be working on the assembly line to adjust bolts and washers since there would be no use for his or her skillset.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on You can&#8217;t deploy an Enterprise Architecture by Nick Malik</title>
		<link>http://archvalue.com/you-cant-deploy-an-enterprise-architecture/#comment-380</link>
		<dc:creator>Nick Malik</dc:creator>
		<pubDate>Tue, 15 May 2012 23:12:55 +0000</pubDate>
		<guid isPermaLink="false">http://archvalue.com/?p=254#comment-380</guid>
		<description>I also disagree that you cannot deploy an Enterprise Architecture.  However, unlike William, I think it has nothing to do with technology.

An enterprise architecture, when produced properly, includes many things.  It includes the relationships that business units have with one another, the processes that are shared among them, the assets that flow through the value chains, the information about those assets that also flows through the human and informational systems, the business processes and capabilities of an organization, and the business models that you are attempting to realize.

NONE of that requires IT at all.  You can implement ALL of it without a single computer.  I can make a case that the original Ford River Rouge complex demonstrated ALL of the aspects above.  That factory was completed in 1928.  The &quot;informational&quot; systems were paper forms.

Please reconsider your view of EA.</description>
		<content:encoded><![CDATA[<p>I also disagree that you cannot deploy an Enterprise Architecture.  However, unlike William, I think it has nothing to do with technology.</p>
<p>An enterprise architecture, when produced properly, includes many things.  It includes the relationships that business units have with one another, the processes that are shared among them, the assets that flow through the value chains, the information about those assets that also flows through the human and informational systems, the business processes and capabilities of an organization, and the business models that you are attempting to realize.</p>
<p>NONE of that requires IT at all.  You can implement ALL of it without a single computer.  I can make a case that the original Ford River Rouge complex demonstrated ALL of the aspects above.  That factory was completed in 1928.  The &#8220;informational&#8221; systems were paper forms.</p>
<p>Please reconsider your view of EA.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on You can&#8217;t deploy an Enterprise Architecture by Kyle Gabhart</title>
		<link>http://archvalue.com/you-cant-deploy-an-enterprise-architecture/#comment-379</link>
		<dc:creator>Kyle Gabhart</dc:creator>
		<pubDate>Tue, 15 May 2012 16:43:56 +0000</pubDate>
		<guid isPermaLink="false">http://archvalue.com/?p=254#comment-379</guid>
		<description>Don&#039;t get me wrong.  I believe that there is tremendous value in modeling Enterprise Architecture as well as Solution Architecture.  My point is that both EA and SA are abstract models that serve to guide your Technical Architecture activities so as to implement capabilities that align with your tactics and strategy.  Even if you have a model-driven approach (MDA / DSL) you still at the end of the delay are deploying TA-level assets that happen to align with your SA and EA vision.  You aren&#039;t really deploying an EA per-se.

Thanks for sharing William.  I look forward to more dialogue in the future.

-KG</description>
		<content:encoded><![CDATA[<p>Don&#8217;t get me wrong.  I believe that there is tremendous value in modeling Enterprise Architecture as well as Solution Architecture.  My point is that both EA and SA are abstract models that serve to guide your Technical Architecture activities so as to implement capabilities that align with your tactics and strategy.  Even if you have a model-driven approach (MDA / DSL) you still at the end of the delay are deploying TA-level assets that happen to align with your SA and EA vision.  You aren&#8217;t really deploying an EA per-se.</p>
<p>Thanks for sharing William.  I look forward to more dialogue in the future.</p>
<p>-KG</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on You can&#8217;t deploy an Enterprise Architecture by william</title>
		<link>http://archvalue.com/you-cant-deploy-an-enterprise-architecture/#comment-378</link>
		<dc:creator>william</dc:creator>
		<pubDate>Tue, 15 May 2012 16:04:28 +0000</pubDate>
		<guid isPermaLink="false">http://archvalue.com/?p=254#comment-378</guid>
		<description>I disagree with your statement. You should be able to deploy an EA ... in the future.
If not why doing it? If you imagine, that systems are generated and configutated automatically from business specification (remember OMG MDA or Microsoft DSL) then you statement is wrong.
You can also look at Software Product line to see that in some degree it is already possible.</description>
		<content:encoded><![CDATA[<p>I disagree with your statement. You should be able to deploy an EA &#8230; in the future.<br />
If not why doing it? If you imagine, that systems are generated and configutated automatically from business specification (remember OMG MDA or Microsoft DSL) then you statement is wrong.<br />
You can also look at Software Product line to see that in some degree it is already possible.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

