<?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"
	>
<channel>
	<title>Comments on: Hävitä oma ohjelmistoarkkitehtuuri</title>
	<atom:link href="http://www.resiina.com/blogi/ketterat-menetelmat/havita-oma-ohjelmistoarkkitehtuuri/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.resiina.com/blogi/ketterat-menetelmat/havita-oma-ohjelmistoarkkitehtuuri/</link>
	<description>Ketterästi perille</description>
	<pubDate>Wed, 08 Sep 2010 00:08:10 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.1</generator>
		<item>
		<title>By: Lare Lekman</title>
		<link>http://www.resiina.com/blogi/ketterat-menetelmat/havita-oma-ohjelmistoarkkitehtuuri/#comment-1055</link>
		<dc:creator>Lare Lekman</dc:creator>
		<pubDate>Mon, 30 Mar 2009 13:55:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.resiina.com/?p=1808#comment-1055</guid>
		<description>Ari,

Ohjelmistoarkkitehtuurilla tarkoitan järjestelmän teknisiä ratkaisuja, en varsinaista sovelluslogiikkaa.

Usein arkkitehtuuri yli- tai alikorostuu. Nuorempi ohjelmistokehittäjä ei ymmärrä koodaavansa pyörää uudestaan ja vanhempi innostuu pyytämättä rakentamaan  "parempaa versiota" kirjastosta tai sovelluskehyksestä, josta olisi saatavilla laadukas, ylläpidetty ja dokumentoitu avoimen lähdekoodin ratkaisu.

Liiketoimintaa ymmärtävä ohjelmistoarkkitehti hävittää yrityksen sisäiset arkkitehtoniset himmelit, valitsee sopivan valmiin sovelluskehyksen kirjastoineen ja keskittää näin tiiminsä ajankäytön asiakkaan lisäarvoon. Arkkitehtuuria ei voi hävittää, mutta omat viritykset voi.</description>
		<content:encoded><![CDATA[<p>Ari,</p>
<p>Ohjelmistoarkkitehtuurilla tarkoitan järjestelmän teknisiä ratkaisuja, en varsinaista sovelluslogiikkaa.</p>
<p>Usein arkkitehtuuri yli- tai alikorostuu. Nuorempi ohjelmistokehittäjä ei ymmärrä koodaavansa pyörää uudestaan ja vanhempi innostuu pyytämättä rakentamaan  &#8220;parempaa versiota&#8221; kirjastosta tai sovelluskehyksestä, josta olisi saatavilla laadukas, ylläpidetty ja dokumentoitu avoimen lähdekoodin ratkaisu.</p>
<p>Liiketoimintaa ymmärtävä ohjelmistoarkkitehti hävittää yrityksen sisäiset arkkitehtoniset himmelit, valitsee sopivan valmiin sovelluskehyksen kirjastoineen ja keskittää näin tiiminsä ajankäytön asiakkaan lisäarvoon. Arkkitehtuuria ei voi hävittää, mutta omat viritykset voi.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ari Tanninen</title>
		<link>http://www.resiina.com/blogi/ketterat-menetelmat/havita-oma-ohjelmistoarkkitehtuuri/#comment-1054</link>
		<dc:creator>Ari Tanninen</dc:creator>
		<pubDate>Thu, 26 Mar 2009 08:13:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.resiina.com/?p=1808#comment-1054</guid>
		<description>En aivan käsitä mitä tarkoitat ohjelmistoarkkitehtuurilla. Alan terminologia on puhki kulunutta ja epämääräistä mutta onko esimerkiksi mahdollista kirjoittaa riviäkään koodia ilman että jo se yksi koodirivi muodostaisi ohjelmiston arkkitehtuurin?

Mielestäni ohjelmistoa ei voi luoda ilman että sillä olisi "arkkitehtuuri", oli se sitten suunniteltu etukäteen tai luotu inkrementaalisesti kehitysjaksoissa ohjelmoinnin yhteydessä. Arkkitehtuuria on mahdotonta hävittää, se on olennainen osa ohjelmistoa.

Sovelluskehyskään ei sellaisenaan ratkaise asiakkaan ongelmia, vaan se tarvitse tuekseen koodia. Usein oliomaailmassa puhutaan domain-mallista missä koodissa esiintyvät rakenteet ja termit heijastelevat tosimaailmaa. Yksinkertaiset tietokantapohjaiset Web-sivusta ovat asia erikseen eikä sellaisissa kenties domain-mallia tarvita. Mutta eikö vähänkään monimutkaisemman ohjelmiston domain-mallin rakenne ole olennainen osa ohjelmiston arkkitehtuuria?

Näkisin käsitteet siten, että sovellusarkkitehtuurin muodostaa  domain-malli joka on sovelluskehysten ja kirjastojen kautta sidottu oikeaan maailman kuten vaikkapa tietokantaan ja käyttäjän Internet-selaimeen. Ohjelmistoarkkitehtuuria ei täten voi hävittää vaikka käytössä olisi millainen sovelluskehys.

Kuten kirjoitit ketterässä kehityksessä kaikki mikä ei tuo lisäarvoa on haaskuuta. Täten arkkitehtuuria pitäisi suunnitella ja toteuttaa juuri sen verran kuin on tarpeen, eikä tippaakaan enempää.  Yleiskäyttöisten ("geneeristen")  ohjelmistojen, arkkitehtuurien saatika sovelluskehysten kehittäminen on rahan tuhlausta, ellei yrityksen bisnes ole niiden myynti.</description>
		<content:encoded><![CDATA[<p>En aivan käsitä mitä tarkoitat ohjelmistoarkkitehtuurilla. Alan terminologia on puhki kulunutta ja epämääräistä mutta onko esimerkiksi mahdollista kirjoittaa riviäkään koodia ilman että jo se yksi koodirivi muodostaisi ohjelmiston arkkitehtuurin?</p>
<p>Mielestäni ohjelmistoa ei voi luoda ilman että sillä olisi &#8220;arkkitehtuuri&#8221;, oli se sitten suunniteltu etukäteen tai luotu inkrementaalisesti kehitysjaksoissa ohjelmoinnin yhteydessä. Arkkitehtuuria on mahdotonta hävittää, se on olennainen osa ohjelmistoa.</p>
<p>Sovelluskehyskään ei sellaisenaan ratkaise asiakkaan ongelmia, vaan se tarvitse tuekseen koodia. Usein oliomaailmassa puhutaan domain-mallista missä koodissa esiintyvät rakenteet ja termit heijastelevat tosimaailmaa. Yksinkertaiset tietokantapohjaiset Web-sivusta ovat asia erikseen eikä sellaisissa kenties domain-mallia tarvita. Mutta eikö vähänkään monimutkaisemman ohjelmiston domain-mallin rakenne ole olennainen osa ohjelmiston arkkitehtuuria?</p>
<p>Näkisin käsitteet siten, että sovellusarkkitehtuurin muodostaa  domain-malli joka on sovelluskehysten ja kirjastojen kautta sidottu oikeaan maailman kuten vaikkapa tietokantaan ja käyttäjän Internet-selaimeen. Ohjelmistoarkkitehtuuria ei täten voi hävittää vaikka käytössä olisi millainen sovelluskehys.</p>
<p>Kuten kirjoitit ketterässä kehityksessä kaikki mikä ei tuo lisäarvoa on haaskuuta. Täten arkkitehtuuria pitäisi suunnitella ja toteuttaa juuri sen verran kuin on tarpeen, eikä tippaakaan enempää.  Yleiskäyttöisten (&#8221;geneeristen&#8221;)  ohjelmistojen, arkkitehtuurien saatika sovelluskehysten kehittäminen on rahan tuhlausta, ellei yrityksen bisnes ole niiden myynti.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
