<?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: The value of architecture artifacts</title>
	<atom:link href="http://www.federalarchitect.com/2008/08/29/the-value-of-architecture-artifacts/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.federalarchitect.com/2008/08/29/the-value-of-architecture-artifacts/</link>
	<description>News &#38; Advice for the Federal Enterprise, System, and Solutions Architecture Community</description>
	<pubDate>Tue, 07 Sep 2010 00:20:42 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: cliffbdf</title>
		<link>http://www.federalarchitect.com/2008/08/29/the-value-of-architecture-artifacts/comment-page-1/#comment-10</link>
		<dc:creator>cliffbdf</dc:creator>
		<pubDate>Wed, 25 Feb 2009 01:05:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.federalarchitect.com/2008/08/29/the-value-of-architecture-artifacts/#comment-10</guid>
		<description>kpburk3's discussion of quality attributes is right on. As I point out in my book Value-Driven IT, most of the difficult issues in architecture have to do with non-functional requirements. Yet, so much effort goes into functional architecture. This is why one hears so often about data synchronization problems between systems, scalability problems, and so on.</description>
		<content:encoded><![CDATA[<p>kpburk3&#8217;s discussion of quality attributes is right on. As I point out in my book Value-Driven IT, most of the difficult issues in architecture have to do with non-functional requirements. Yet, so much effort goes into functional architecture. This is why one hears so often about data synchronization problems between systems, scalability problems, and so on.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Carnival of Enterprise Architecture #12 - October 1, 2008 &#124; Project Management Resources, Templates, Books, Tools, News :: PMToolbox</title>
		<link>http://www.federalarchitect.com/2008/08/29/the-value-of-architecture-artifacts/comment-page-1/#comment-7</link>
		<dc:creator>Carnival of Enterprise Architecture #12 - October 1, 2008 &#124; Project Management Resources, Templates, Books, Tools, News :: PMToolbox</dc:creator>
		<pubDate>Sun, 05 Oct 2008 08:15:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.federalarchitect.com/2008/08/29/the-value-of-architecture-artifacts/#comment-7</guid>
		<description>[...] N&#173;. Shah pr&#173;es&#173;en&#173;ts&#173; The v&#173;alue of&#173; architecture artif&#173;acts&#173; post&#173;ed at&#173; T&#173;he&#173; Fe&#173;de&#173;ral&#173; [...]</description>
		<content:encoded><![CDATA[<p>[...] N&#173;. Shah pr&#173;es&#173;en&#173;ts&#173; The v&#173;alue of&#173; architecture artif&#173;acts&#173; post&#173;ed at&#173; T&#173;he&#173; Fe&#173;de&#173;ral&#173; [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kpburk3</title>
		<link>http://www.federalarchitect.com/2008/08/29/the-value-of-architecture-artifacts/comment-page-1/#comment-4</link>
		<dc:creator>kpburk3</dc:creator>
		<pubDate>Fri, 29 Aug 2008 18:53:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.federalarchitect.com/2008/08/29/the-value-of-architecture-artifacts/#comment-4</guid>
		<description>At the practitioner level (actually building a system), my experience has been that architecture products add little value.  If fact they can be quite a tax in a DoD program environment if one is changed with maintaining them.   However, from a programmatic perspective, architecture artifacts can, if done appropriately be of very high value in communicating with oversight officials (and that brings funding).  They can also bridge interrelated programs toward interoperability.  For example when I was in Army Medical IT business in 1999-2001, the Medical and Logistics DODAF architecture products provided substantial means of aligning both programs and technical architecture.  These views provided a lexicon for several communities of practice to communicate, collaborate and develop plans.

Mark Maier’s work “The Art of Systems Architecting “ is the best I have seen, I actually ref to it every six months or so

One of the key concepts I remember from hearing Dr. Maier speak was that Architecture is not about “views” or “perspectives” as many EA proponents advocate.  *** It is an identification and measurement of Quality Attributes. ***  What are the Quality Attributes of the system or enterprise under consideration, and how can we measure them?  Architecture efforts must be able to address these questions. 

http://www.amazon.com/Art-Systems-Architecting-Second/dp/0849304407</description>
		<content:encoded><![CDATA[<p>At the practitioner level (actually building a system), my experience has been that architecture products add little value.  If fact they can be quite a tax in a DoD program environment if one is changed with maintaining them.   However, from a programmatic perspective, architecture artifacts can, if done appropriately be of very high value in communicating with oversight officials (and that brings funding).  They can also bridge interrelated programs toward interoperability.  For example when I was in Army Medical IT business in 1999-2001, the Medical and Logistics DODAF architecture products provided substantial means of aligning both programs and technical architecture.  These views provided a lexicon for several communities of practice to communicate, collaborate and develop plans.</p>
<p>Mark Maier’s work “The Art of Systems Architecting “ is the best I have seen, I actually ref to it every six months or so</p>
<p>One of the key concepts I remember from hearing Dr. Maier speak was that Architecture is not about “views” or “perspectives” as many EA proponents advocate.  *** It is an identification and measurement of Quality Attributes. ***  What are the Quality Attributes of the system or enterprise under consideration, and how can we measure them?  Architecture efforts must be able to address these questions. </p>
<p><a href="http://www.amazon.com/Art-Systems-Architecting-Second/dp/0849304407" rel="nofollow">http://www.amazon.com/Art-Systems-Architecting-Second/dp/0849304407</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris.Gunderson</title>
		<link>http://www.federalarchitect.com/2008/08/29/the-value-of-architecture-artifacts/comment-page-1/#comment-3</link>
		<dc:creator>Chris.Gunderson</dc:creator>
		<pubDate>Fri, 29 Aug 2008 18:50:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.federalarchitect.com/2008/08/29/the-value-of-architecture-artifacts/#comment-3</guid>
		<description>Architectural artifacts may or may not be useful to a particular engineer building a particular information system.  However, when it comes to either draconian compliance enforcement, or more enlightened validation of value added, prognostic artifacts are irrelevant.  What matters is how the delivered structure is actually constructed and how it performs.  So... we need DIAGNOSTIC architectural artifacts that are created as a by product of our test and evaluation and validation and verification processes. Given the application abstractions that are trivially available in modern network architectures, generating these diagnostic artifacts should be pretty easy.  However, at least in the DoD, the architectural artifacts required to demonstrate compliance and value are not coupled to actual run time activity.</description>
		<content:encoded><![CDATA[<p>Architectural artifacts may or may not be useful to a particular engineer building a particular information system.  However, when it comes to either draconian compliance enforcement, or more enlightened validation of value added, prognostic artifacts are irrelevant.  What matters is how the delivered structure is actually constructed and how it performs.  So&#8230; we need DIAGNOSTIC architectural artifacts that are created as a by product of our test and evaluation and validation and verification processes. Given the application abstractions that are trivially available in modern network architectures, generating these diagnostic artifacts should be pretty easy.  However, at least in the DoD, the architectural artifacts required to demonstrate compliance and value are not coupled to actual run time activity.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: starai</title>
		<link>http://www.federalarchitect.com/2008/08/29/the-value-of-architecture-artifacts/comment-page-1/#comment-2</link>
		<dc:creator>starai</dc:creator>
		<pubDate>Fri, 29 Aug 2008 13:39:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.federalarchitect.com/2008/08/29/the-value-of-architecture-artifacts/#comment-2</guid>
		<description>I agree that some artifacts are very valuable.....at least for a while.   We should look at our inventory and assess current value.   But I'd like to address how artificats are created with little value.  This often happens when the motivation is checking the box.  Also concider the oversight the assesses value.  Does it exist?</description>
		<content:encoded><![CDATA[<p>I agree that some artifacts are very valuable&#8230;..at least for a while.   We should look at our inventory and assess current value.   But I&#8217;d like to address how artificats are created with little value.  This often happens when the motivation is checking the box.  Also concider the oversight the assesses value.  Does it exist?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
