<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Arkhi</title>
	<atom:link href="http://blog.arkhi.com.br/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.arkhi.com.br</link>
	<description>Arquitetura Corporativa</description>
	<lastBuildDate>Fri, 18 May 2012 17:26:39 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
		<item>
		<title>Domínios da Arquitetura Corporativa</title>
		<link>http://blog.arkhi.com.br/2009/11/29/dominios-da-arquitetura-corporativa/</link>
		<comments>http://blog.arkhi.com.br/2009/11/29/dominios-da-arquitetura-corporativa/#comments</comments>
		<pubDate>Mon, 30 Nov 2009 01:21:51 +0000</pubDate>
		<dc:creator>Eros Viggiano</dc:creator>
				<category><![CDATA[arquitetura corporativa]]></category>
		<category><![CDATA[arquitetura de negócio]]></category>
		<category><![CDATA[arquitetura de software]]></category>
		<category><![CDATA[gestão em aquisição de software]]></category>
		<category><![CDATA[arquitetura tecnológica]]></category>

		<guid isPermaLink="false">http://blog.arkhi.com.br/?p=665</guid>
		<description><![CDATA[A arquitetura de software pode ser entendida como um domínio da arquitetura corporativa. Inclusive, é dentro de tal contexto que o mais eficaz valor da arquitetura de software é realizado: o alinhamento com o negócio. Antes de prosseguirmos, convém definir &#8220;arquitetura corporativa&#8221;. “A arquitetura corporativa define a coleção de capacidades de negócio, processos, serviços de [...]]]></description>
			<content:encoded><![CDATA[<p>A arquitetura de software pode ser entendida como um domínio da arquitetura corporativa. Inclusive, é dentro de tal contexto que o mais eficaz valor da arquitetura de software é realizado: o alinhamento com o negócio. Antes de prosseguirmos, convém definir &#8220;arquitetura corporativa&#8221;.</p>
<p><em>“A arquitetura corporativa define a coleção de capacidades de negócio, processos, serviços de negócio, serviços tecnológicos e infraestrutura  de TI para realizar tais capacidades.”</em> &#8211; TOGAF</p>
<p>TOGAF (The Open Group Architecture Framework) é um dos corpos de conhecimento em arquitetura corporativa. A saber, alguns outros:</p>
<ul>
<li>Zachman: o primeiro framework de arquitetura corporativa</li>
<li>EABOK: iniciativa do governo norte americano</li>
<li>DoDAF : framework do Departamento de Defesa Norte Americano</li>
<li>MODAF: framework do Departamento de Defesa do Reino Unido</li>
</ul>
<p>A arquitetura corporativa se preocupa com as capacidades da organização, enquanto que a arquitetura de software é apenas um dos aspectos para desenvolver tais capacidades. Abaixo relacionamos o senso comum sobre os domínios da arquitetura corporativa.</p>
<p style="text-align: center;"><img class="size-full wp-image-666 aligncenter" title="Típicos Domínios da Arquitetura Corporativa" src="http://blog.arkhi.com.br/wp-content/uploads/2009/11/dominios.png" alt="Típicos Domínios da Arquitetura Corporativa" width="547" height="304" /></p>
<p>Arquitetura de negócio é composta por:</p>
<ul>
<li>estratégia, governança e organização de um negócio;</li>
<li>informação sobre os processos-chaves de negócio;</li>
<li>relacionamento entre todos estes conceitos.</li>
</ul>
<p>Arquitetura de dados é composta por:</p>
<ul>
<li>estrutura lógica e física de ativos de dados da organização;</li>
<li>recursos de gestão de dados.</li>
</ul>
<p>Arquitetura de aplicação descreve o grupo lógico das capacidades para gerenciar objetos de dados necessários para processar os dados e o negócio.</p>
<p>E, finalmente, a arquitetura tecnológica:</p>
<ul>
<li>envolve capacidades lógicas de software e hardware requeridas para suportar a implantação de serviços de negócio, dados e aplicação;</li>
<li>inclui infraestrutura de TI, middleware, redes, comunicação e padrões (standards).</li>
</ul>
<p>A arquitetura de software, ao mesmo tempo que se preocupa fortemente com a arquitetura de sistemas de informação (aplicações e dados), se relaciona diretamente com a arquitetura de negócios e arquitetura tecnológica.  O relacionamento com a arquitetura de negócio provê um alinhamento natural com o contexto organizacional, as estratégias corporativas e os processos de negócio. Além disto, a estreita ligação com a arquitetura tecnológica garante que a fundação de TI estará apta a suportar aplicações com necessidades de negócio perfeitamente endereçadas.</p>
<p>A arquitetura de software, dentro de uma abordagem corporativa, certamente terá maiores chances de transformar o software em valor real para a companhia.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.arkhi.com.br/2009/11/29/dominios-da-arquitetura-corporativa/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>BPM e SOA Orientado por Capacidades de Negócio</title>
		<link>http://blog.arkhi.com.br/2009/11/18/bpm-e-soa-orientado-por-capacidades-de-negocio/</link>
		<comments>http://blog.arkhi.com.br/2009/11/18/bpm-e-soa-orientado-por-capacidades-de-negocio/#comments</comments>
		<pubDate>Wed, 18 Nov 2009 21:33:34 +0000</pubDate>
		<dc:creator>Marco Mendes</dc:creator>
				<category><![CDATA[arquitetura de negócio]]></category>

		<guid isPermaLink="false">http://blog.arkhi.com.br/?p=650</guid>
		<description><![CDATA[A prática de BPM é normalmente definida como a &#8220;modelagem, simulação, automação, monitoração e gerenciamento dos processos de negócios essenciais de uma organização&#8221;.  Esta definição guarda um conceito importante, que é a necessidade de conhecermos o que são os processos essenciais. Uma técnica importante para descobrir quais são os processos essenciais é o uso de [...]]]></description>
			<content:encoded><![CDATA[<p>A prática de BPM é normalmente definida como a &#8220;modelagem, simulação, automação, monitoração e gerenciamento dos processos de negócios essenciais de uma organização&#8221;.  Esta definição guarda um conceito importante, que é a necessidade de conhecermos o que são os processos <em>essenciais</em>.</p>
<p>Uma técnica importante para descobrir quais são os processos essenciais é o uso de <em>capacidades de negócio</em>. Uma capacidade de negócio representa uma abstração de negócio que represente a natureza de uma organização e quer normalmente requer alavancagem. Alguns exemplos para tornar concreto o nosso raciocínio poderiam incluir:</p>
<ul>
<li>A capacidade de se<em>rviços padronizadas</em> em uma franquia de sanduíches, como por exemplo o MacDonalds ou o Giraffas.</li>
<li>A capacidade de i<em>ntegração de informações </em>em uma rede logística, que necessita coordenar milhares de fornecedores, como por exemplo a rede do Pão de Açucar.</li>
<li>A capacidade de <em>planejamento do controle de produção</em> em uma linha de montagem de automóveis, com alta padronização de processos e alta integração destes processos de manufatura.</li>
<li>A capacidade de <em>agilidade na entrega de pedidos</em> na unidade de negócio de delivery de uma grande pizzaria.</li>
</ul>
<p><strong>Capacidades de Negócio &#8211; A bússola BPM</strong></p>
<div class="wp-caption aligncenter" style="width: 570px"><img class="  " title="Bussola BPM" src="http://upload.wikimedia.org/wikipedia/commons/thumb/5/53/Model_Si_Nan_of_Han_Dynasty.jpg/800px-Model_Si_Nan_of_Han_Dynasty.jpg" alt="Bússola BPM" width="560" height="374" /><p class="wp-caption-text">Oriente seus processos de negócio pelas capacidades de negócio que melhor definem a natureza da sua organização ou unidade de negócio</p></div>
<p>As capacidades de negócio definem atributos sobre um sistema empresarial e permitem expressar a natureza do negócio desta organização. Capacidades complementam a visão clássica de BPM. Enquanto o BPM responde &#8220;COMO&#8221;, as capacidades de negócio dizem &#8220;O QUE&#8221; e nos auxiliam nos motivadores de negócio &#8211; &#8220;POR QUE&#8221;.</p>
<p>Uma vez que tenhamos descoberto as capacidades de negócio, podemos focar no mapa de processos. Todo e qualquer processo que não esteja aderente a uma capacidade de negócio será descartado. Apenas os processos de negócio aderentes às capacidades de negócio serão alvo do nosso esforço BPM. Esta iniciativa pragmática permite focar e saber que o nosso esforço será eficaz.</p>
<p>Para os praticantes de SOA, as capacidades de negócio criam um caminho confiável e assertivo para as integrações sistêmicas e automações de processos de negócio.</p>
<p>Para os interessados, um artigo introdutório a respeito está disponível aqui no <a title="Capacidades de Negócio como Habilitador SOA" href=".microsoft.com/en-us/architecture/aa699435.aspx" target="_blank">Microsoft Architecture Journal</a>. Para os realmente interessados, um artigo sobre o modelo de engajamento de TI às capacidades de negócio de uma organização baseado no excelente trabalho de <a title="Entrevista com Jeanne Ross" href="http://mitsloan.mit.edu/faculty/spotlight/ross.php" target="_blank">Jeanne Ross</a> está disponível <a title="Enterprise Architecture as IT Strategy" href="http://www.schoolcio.com/showarticle/870" target="_blank">aqui</a>.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.arkhi.com.br/2009/11/18/bpm-e-soa-orientado-por-capacidades-de-negocio/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Os condutores arquiteturais para a adoção do SOA Orientado por Eventos &#8211; EDA e CEP</title>
		<link>http://blog.marcomendes.com/2009/11/03/os-condutores-arquiteturais-para-a-adocao-do-soa-orientada-por-eventos-eda-e-cep/</link>
		<comments>http://blog.marcomendes.com/2009/11/03/os-condutores-arquiteturais-para-a-adocao-do-soa-orientada-por-eventos-eda-e-cep/#comments</comments>
		<pubDate>Tue, 03 Nov 2009 17:51:19 +0000</pubDate>
		<dc:creator>Marco Mendes</dc:creator>
				<category><![CDATA[Sem categoria]]></category>
		<category><![CDATA[arquitetura]]></category>
		<category><![CDATA[SOA]]></category>

		<guid isPermaLink="false">http://blog.marcomendes.com/2009/11/03/os-condutores-arquiteturais-para-a-adocao-do-soa-orientada-por-eventos-eda-e-cep/</guid>
		<description><![CDATA[A abordagem tradicional para SOA está baseada nas premissas da modelagem, simulação, automação, monitoração e gerência de processos de negócio, i.e, o ciclo de vida de BPM (Gerenciamento de Processos de Negócio). Existem diversos cenários, entretanto, onde esta premissa não se torna válida.
Caso a nossa empresa ou o problema em questão apresente a lista de [...]]]></description>
			<content:encoded><![CDATA[A abordagem tradicional para SOA está baseada nas premissas da modelagem, simulação, automação, monitoração e gerência de processos de negócio, i.e, o ciclo de vida de BPM (Gerenciamento de Processos de Negócio). Existem diversos cenários, entretanto, onde esta premissa não se torna válida.
Caso a nossa empresa ou o problema em questão apresente a lista de [...]]]></content:encoded>
			<wfw:commentRss>http://blog.marcomendes.com/2009/11/03/os-condutores-arquiteturais-para-a-adocao-do-soa-orientada-por-eventos-eda-e-cep/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Os Princípios do Manifesto SOA</title>
		<link>http://blog.marcomendes.com/2009/10/25/os-principios-do-manifesto-soa/</link>
		<comments>http://blog.marcomendes.com/2009/10/25/os-principios-do-manifesto-soa/#comments</comments>
		<pubDate>Sun, 25 Oct 2009 21:51:27 +0000</pubDate>
		<dc:creator>Marco Mendes</dc:creator>
				<category><![CDATA[Sem categoria]]></category>
		<category><![CDATA[Outros]]></category>
		<category><![CDATA[SOA]]></category>

		<guid isPermaLink="false">http://blog.marcomendes.com/2009/10/25/os-principios-do-manifesto-soa/</guid>
		<description><![CDATA[

Os Princípios do Manifesto SOA



Nós seguimos estes princípios:

Respeitar a estrutura social e de poder  de uma organização.

Reconhecer que SOA requer mudança em vários níveis
O escopo da adoção de SOA pode variar.  Devemos manter os seus esforços gerenciáveis e dentro  de limites significativos
Produtos e ferramentas sozinhos não lhe  fornecerão SOA ou aplicarão [...]]]></description>
			<content:encoded><![CDATA[

Os Princípios do Manifesto SOA



Nós seguimos estes princípios:

Respeitar a estrutura social e de poder  de uma organização.

Reconhecer que SOA requer mudança em vários níveis
O escopo da adoção de SOA pode variar.  Devemos manter os seus esforços gerenciáveis e dentro  de limites significativos
Produtos e ferramentas sozinhos não lhe  fornecerão SOA ou aplicarão [...]]]></content:encoded>
			<wfw:commentRss>http://blog.marcomendes.com/2009/10/25/os-principios-do-manifesto-soa/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>O Manifesto SOA</title>
		<link>http://blog.marcomendes.com/2009/10/25/o-manifesto-soa/</link>
		<comments>http://blog.marcomendes.com/2009/10/25/o-manifesto-soa/#comments</comments>
		<pubDate>Sun, 25 Oct 2009 21:03:35 +0000</pubDate>
		<dc:creator>Marco Mendes</dc:creator>
				<category><![CDATA[Sem categoria]]></category>
		<category><![CDATA[Outros]]></category>
		<category><![CDATA[SOA]]></category>

		<guid isPermaLink="false">http://blog.marcomendes.com/2009/10/25/o-manifesto-soa/</guid>
		<description><![CDATA[

 O Manifesto SOA
A orientação por serviços é um paradigma que orienta o que você faz. A arquitetura orientada por serviços (SOA) é um tipo de arquitetura que resulta da aplicação da orientação por serviços. Nós aplicamos a orientação por serviços para ajudar organizações a entregar valor de negócio de forma sustentável, com agilidade aumentada [...]]]></description>
			<content:encoded><![CDATA[

 O Manifesto SOA
A orientação por serviços é um paradigma que orienta o que você faz. A arquitetura orientada por serviços (SOA) é um tipo de arquitetura que resulta da aplicação da orientação por serviços. Nós aplicamos a orientação por serviços para ajudar organizações a entregar valor de negócio de forma sustentável, com agilidade aumentada [...]]]></content:encoded>
			<wfw:commentRss>http://blog.marcomendes.com/2009/10/25/o-manifesto-soa/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>O complexo caminho da simplicidade do EJB 3.1 e o Java EE 6.0</title>
		<link>http://blog.marcomendes.com/2009/10/23/o-complexo-caminho-da-simplicidade-do-ejb-31-e-o-java-ee-60/</link>
		<comments>http://blog.marcomendes.com/2009/10/23/o-complexo-caminho-da-simplicidade-do-ejb-31-e-o-java-ee-60/#comments</comments>
		<pubDate>Fri, 23 Oct 2009 03:18:44 +0000</pubDate>
		<dc:creator>Marco Mendes</dc:creator>
				<category><![CDATA[Sem categoria]]></category>
		<category><![CDATA[Java EE]]></category>

		<guid isPermaLink="false">http://blog.marcomendes.com/2009/10/23/o-complexo-caminho-da-simplicidade-do-ejb-31-e-o-java-ee-60/</guid>
		<description><![CDATA[Para um novato Java que queira criar um EJB na especificação 3.1, o processo é muito simples. Você cria uma classe Java e com apenas uma anotação você tem um objeto distribuído que responde via protocolo RMI/IIOP.

Se você desejar criar um objeto distribuído que responda através de SOAP, i.e, um WebService, basta adicionar uma outra [...]]]></description>
			<content:encoded><![CDATA[Para um novato Java que queira criar um EJB na especificação 3.1, o processo é muito simples. Você cria uma classe Java e com apenas uma anotação você tem um objeto distribuído que responde via protocolo RMI/IIOP.

Se você desejar criar um objeto distribuído que responda através de SOAP, i.e, um WebService, basta adicionar uma outra [...]]]></content:encoded>
			<wfw:commentRss>http://blog.marcomendes.com/2009/10/23/o-complexo-caminho-da-simplicidade-do-ejb-31-e-o-java-ee-60/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>A evolução do MPS-BR &#8211; Guias para empresas que adquirem software, para fábricas de software e fábricas de testes</title>
		<link>http://blog.marcomendes.com/2009/10/14/a-evolucao-do-mps-br-guias-para-empresas-que-adquirem-software-para-fabricas-de-software-e-fabricas-de-testes/</link>
		<comments>http://blog.marcomendes.com/2009/10/14/a-evolucao-do-mps-br-guias-para-empresas-que-adquirem-software-para-fabricas-de-software-e-fabricas-de-testes/#comments</comments>
		<pubDate>Wed, 14 Oct 2009 14:24:01 +0000</pubDate>
		<dc:creator>Marco Mendes</dc:creator>
				<category><![CDATA[Sem categoria]]></category>
		<category><![CDATA[Gestão da Aquisição]]></category>

		<guid isPermaLink="false">http://blog.marcomendes.com/2009/10/14/a-evolucao-do-mps-br-guias-para-empresas-que-adquirem-software-para-fabricas-de-software-e-fabricas-de-testes/</guid>
		<description><![CDATA[O MPS-BR, modelo Brasileiro de maturidade de software, está evoluindo a pleno vapor. Três novos guias estão disponíveis no portal do MPS-BR.
- Guia de Implementação – Parte 8: 2009 (Outubro de 2009)
Este guia contém orientações para a implementação do Modelo de Referência MR-MPS em organizações que adquirem software.  
-Guia de Implementação – Parte 9: [...]]]></description>
			<content:encoded><![CDATA[O MPS-BR, modelo Brasileiro de maturidade de software, está evoluindo a pleno vapor. Três novos guias estão disponíveis no portal do MPS-BR.
- Guia de Implementação – Parte 8: 2009 (Outubro de 2009)
Este guia contém orientações para a implementação do Modelo de Referência MR-MPS em organizações que adquirem software.  
-Guia de Implementação – Parte 9: [...]]]></content:encoded>
			<wfw:commentRss>http://blog.marcomendes.com/2009/10/14/a-evolucao-do-mps-br-guias-para-empresas-que-adquirem-software-para-fabricas-de-software-e-fabricas-de-testes/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Os analistas de sistemas, os “soft skills”, a filosofia estóica e o budismo</title>
		<link>http://blog.marcomendes.com/2009/10/09/os-analistas-de-sistemas-os-soft-skills-e-a-filosofia-estoica-e-o-budismo/</link>
		<comments>http://blog.marcomendes.com/2009/10/09/os-analistas-de-sistemas-os-soft-skills-e-a-filosofia-estoica-e-o-budismo/#comments</comments>
		<pubDate>Fri, 09 Oct 2009 22:16:49 +0000</pubDate>
		<dc:creator>Marco Mendes</dc:creator>
				<category><![CDATA[Sem categoria]]></category>
		<category><![CDATA[Gestão de Pessoas]]></category>

		<guid isPermaLink="false">http://blog.marcomendes.com/2009/10/09/os-analistas-de-sistemas-os-soft-skills-e-a-filosofia-estoica-e-o-budismo/</guid>
		<description><![CDATA[Depois de um longo e pesado Setembro, estamos de volta ao nosso bom hábito de escrever. Desta vez gostaria de falar sobre uma habilidade cada vez mais valorizada pela empresas de TI, que são os &#8220;soft skills˜, ou habilidade suaves, em uma tradução literal. Estas habilidades são muito enfatizadas pelos agilistas e escolas ágeis e [...]]]></description>
			<content:encoded><![CDATA[Depois de um longo e pesado Setembro, estamos de volta ao nosso bom hábito de escrever. Desta vez gostaria de falar sobre uma habilidade cada vez mais valorizada pela empresas de TI, que são os &#8220;soft skills˜, ou habilidade suaves, em uma tradução literal. Estas habilidades são muito enfatizadas pelos agilistas e escolas ágeis e [...]]]></content:encoded>
			<wfw:commentRss>http://blog.marcomendes.com/2009/10/09/os-analistas-de-sistemas-os-soft-skills-e-a-filosofia-estoica-e-o-budismo/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Motores de Regras &#8211; BRMS 101</title>
		<link>http://blog.marcomendes.com/2009/09/08/motores-de-regras-brms-101/</link>
		<comments>http://blog.marcomendes.com/2009/09/08/motores-de-regras-brms-101/#comments</comments>
		<pubDate>Tue, 08 Sep 2009 15:52:37 +0000</pubDate>
		<dc:creator>Marco Mendes</dc:creator>
				<category><![CDATA[Sem categoria]]></category>
		<category><![CDATA[arquitetura]]></category>

		<guid isPermaLink="false">http://blog.marcomendes.com/2009/09/08/motores-de-regras-brms-101/</guid>
		<description><![CDATA[Com a popularização de projetos SOA, também houve um renascimento do conceito de motores de regras (Rule Engine). Mas o que são motores de regras?
Um motor de regra é um sistema computacional que tem a capacidade de executar um conjunto de regras de negócios em um ambiente de produção. Eles são chamados em inglês de [...]]]></description>
			<content:encoded><![CDATA[Com a popularização de projetos SOA, também houve um renascimento do conceito de motores de regras (Rule Engine). Mas o que são motores de regras?
Um motor de regra é um sistema computacional que tem a capacidade de executar um conjunto de regras de negócios em um ambiente de produção. Eles são chamados em inglês de [...]]]></content:encoded>
			<wfw:commentRss>http://blog.marcomendes.com/2009/09/08/motores-de-regras-brms-101/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Arquiteturas Testáveis</title>
		<link>http://blog.marcomendes.com/2009/09/07/arquiteturas-testaveis/</link>
		<comments>http://blog.marcomendes.com/2009/09/07/arquiteturas-testaveis/#comments</comments>
		<pubDate>Mon, 07 Sep 2009 16:20:20 +0000</pubDate>
		<dc:creator>Marco Mendes</dc:creator>
				<category><![CDATA[Sem categoria]]></category>
		<category><![CDATA[arquitetura]]></category>
		<category><![CDATA[SOA]]></category>

		<guid isPermaLink="false">http://blog.marcomendes.com/2009/09/07/arquiteturas-testaveis/</guid>
		<description><![CDATA[Um dos gaps existentes nos times de desenvolvimento de software é a distância entre a concepção e desenho da arquitetura e sua efetiva realização. Motivos para este problema incluem:

 Mudanças de escopo e mudanças nas prioridades dos condutores e requisitos arquiteturais,
 Ausência de desenvolvedores na definição da arquitetura. Quando uma pessoa não participa da definição [...]]]></description>
			<content:encoded><![CDATA[Um dos gaps existentes nos times de desenvolvimento de software é a distância entre a concepção e desenho da arquitetura e sua efetiva realização. Motivos para este problema incluem:

 Mudanças de escopo e mudanças nas prioridades dos condutores e requisitos arquiteturais,
 Ausência de desenvolvedores na definição da arquitetura. Quando uma pessoa não participa da definição [...]]]></content:encoded>
			<wfw:commentRss>http://blog.marcomendes.com/2009/09/07/arquiteturas-testaveis/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
