<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/atom10full.xsl"?><?xml-stylesheet type="text/css" media="screen" href="http://feeds.feedburner.com/~d/styles/itemcontent.css"?><feed xmlns="http://www.w3.org/2005/Atom" xmlns:openSearch="http://a9.com/-/spec/opensearch/1.1/" xmlns:georss="http://www.georss.org/georss" xmlns:gd="http://schemas.google.com/g/2005" xmlns:feedburner="http://rssnamespace.org/feedburner/ext/1.0" gd:etag="W/&quot;CEABRX07eSp7ImA9WxNVFk8.&quot;"><id>tag:blogger.com,1999:blog-11168006</id><updated>2009-10-27T05:52:34.301Z</updated><title>Service Architecture - SOA</title><subtitle type="html">Simple Blog about Service Oriented Architecture (SOA), its tooling and delivery (SOD) or realisation (SOR) - now with added clouds. All opinions are mine and should be taken with a pinch of salt etc etc</subtitle><link rel="http://schemas.google.com/g/2005#feed" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/posts/default" /><link rel="alternate" type="text/html" href="http://service-architecture.blogspot.com/" /><link rel="hub" href="http://pubsubhubbub.appspot.com/" /><link rel="next" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default?start-index=26&amp;max-results=25&amp;redirect=false&amp;v=2" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email></author><generator version="7.00" uri="http://www.blogger.com">Blogger</generator><openSearch:totalResults>413</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>25</openSearch:itemsPerPage><link rel="self" href="http://service-architecture.blogspot.com" type="application/atom+xml" /><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="hub" href="http://pubsubhubbub.appspot.com" /><entry gd:etag="W/&quot;CEABRX05eip7ImA9WxNVFk8.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-6383872163828820176</id><published>2009-10-26T23:03:00.006Z</published><updated>2009-10-27T05:52:34.322Z</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-10-27T05:52:34.322Z</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="requirements" /><category scheme="http://www.blogger.com/atom/ns#" term="SOA" /><category scheme="http://www.blogger.com/atom/ns#" term="requirements landfill" /><category scheme="http://www.blogger.com/atom/ns#" term="governance" /><title>Requirements Landfill - the challenge of central services</title><summary type="html">Enterprise Services of any type from Business Services like procurement through to technical infrastructure services such as Identity management are all at risk from a threat of pollution.  I call this threat the requirements landfill.One of the key principles of SOA in operation has been the ability to have services which are used across the enterprise.  These single services represent a single &lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/ar0R5n3T_60" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/6383872163828820176/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=6383872163828820176" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/6383872163828820176?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/6383872163828820176?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/ar0R5n3T_60/requirements-landfill-challenge-of.html" title="Requirements Landfill - the challenge of central services" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="http://2.bp.blogspot.com/_3OcSUeGygTE/SuaFOpMHg4I/AAAAAAAABj8/UdK6uBgTiWc/s72-c/Service+Hub.png" height="72" width="72" /><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/10/requirements-landfill-challenge-of.html</feedburner:origLink></entry><entry gd:etag="W/&quot;CEUCQng6fyp7ImA9WxNVEEQ.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-6810343658418466113</id><published>2009-10-21T03:17:00.003+01:00</published><updated>2009-10-21T03:31:03.617+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-10-21T03:31:03.617+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="data" /><category scheme="http://www.blogger.com/atom/ns#" term="SOA" /><title>Data Accuracy isn't always important</title><summary type="html">Now while Amex really should have understood the term minimum there are examples where it really isn't an issue if someone gets it wrong in displaying the information to you.  Sometimes this indicates that a prediction has been incorrect or that "approximately" is good enough for this scenario.Is a good example of this, the current temperature on the Sydney Morning Herald site is listed as one &lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/for5XRmt96E" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/6810343658418466113/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=6810343658418466113" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/6810343658418466113?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/6810343658418466113?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/for5XRmt96E/data-accuracy-isnt-always-important.html" title="Data Accuracy isn't always important" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="http://4.bp.blogspot.com/_3OcSUeGygTE/St5vwzpkZRI/AAAAAAAABj0/GHzRCAnghkM/s72-c/Sydney+Weather+Anomoly.png" height="72" width="72" /><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/10/data-accuracy-isnt-always-important.html</feedburner:origLink></entry><entry gd:etag="W/&quot;C0cBR3o_cSp7ImA9WxNWFEs.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-3983899577565158037</id><published>2009-10-13T19:58:00.003+01:00</published><updated>2009-10-13T20:10:56.449+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-10-13T20:10:56.449+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="cloud" /><category scheme="http://www.blogger.com/atom/ns#" term="definition" /><title>When you know it isn't a cloud</title><summary type="html">Following up on the previous post I thought I'd do the REALLY obvious ones that indicate it isn't a cloud.  James' list wasn't nearly cynical enough in light of the things that are claimed to be a cloud.So here goesIf its just a single website with no backups storing stuff to disk then its just a standard WEBSITE not a cloud (Hello Sidekick)If its a physical box that is meant to help you manage a&lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/0rWq2_v7SaU" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/3983899577565158037/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=3983899577565158037" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/3983899577565158037?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/3983899577565158037?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/0rWq2_v7SaU/when-you-know-it-isnt-cloud.html" title="When you know it isn't a cloud" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/10/when-you-know-it-isnt-cloud.html</feedburner:origLink></entry><entry gd:etag="W/&quot;CEQNQHw6fip7ImA9WxNWFE4.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-2119044221189763872</id><published>2009-10-13T10:21:00.004+01:00</published><updated>2009-10-13T12:13:11.216+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-10-13T12:13:11.216+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="advertising" /><category scheme="http://www.blogger.com/atom/ns#" term="phones" /><title>How you know a phone is rubbish</title><summary type="html">My ever perceptive wife Heather spotted something the other day about mobile phone adverts.  They basically come in two flavoursiPhone adsThe restThe difference between them is simple  here are the apple ones, first from when it launchedand an "there is an app for that" oneNow for the competition: SamsungMicrosoftand (with the Omnia)and Google's Android (via HTC)See the difference? The Mrs did &lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/dc3-4OIAE0E" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/2119044221189763872/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=2119044221189763872" title="1 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/2119044221189763872?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/2119044221189763872?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/dc3-4OIAE0E/how-you-know-phone-is-rubbish.html" title="How you know a phone is rubbish" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">1</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/10/how-you-know-phone-is-rubbish.html</feedburner:origLink></entry><entry gd:etag="W/&quot;CEYMSHg9fyp7ImA9WxNWE0g.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-8148531732540081318</id><published>2009-10-12T13:23:00.002+01:00</published><updated>2009-10-12T13:56:29.667+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-10-12T13:56:29.667+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="cloud" /><title>Not a cloud?  Then what is it?</title><summary type="html">Redmonk are one of those smaller analyst companies who make up for a lack of numbers with a refreshing depth and honesty. James Governor's latest, and I assume light hearted, view of "15 Ways to Tell Its Not Cloud Computing" however does a bit of a disservice to the debate around clouds.  Mostly right but with a few glaring pieces I felt I had to disagree with.If you peel back the label and its &lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/JuissfCW3HA" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/8148531732540081318/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=8148531732540081318" title="3 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/8148531732540081318?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/8148531732540081318?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/JuissfCW3HA/not-cloud-then-what-is-it.html" title="Not a cloud?  Then what is it?" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">3</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/10/not-cloud-then-what-is-it.html</feedburner:origLink></entry><entry gd:etag="W/&quot;D0IDRHo_fyp7ImA9WxNXGE8.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-415235513557632342</id><published>2009-10-06T09:11:00.003+01:00</published><updated>2009-10-06T11:39:35.447+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-10-06T11:39:35.447+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="engineering" /><title>Alternative Engineering</title><summary type="html">Dan Creswell pointed me towards an interesting blog on Cargo Cults and Computing on the same day I looked at this video on YouTube...Then yesterday I was talking with someone who is helping dig out a project that has been driven into the ground by some people with very firm beliefs about how things should be done these were people who had taken pieces from agile, from waterfall, from TOGAF, from &lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/Y_Tl9DMRtVU" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/415235513557632342/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=415235513557632342" title="6 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/415235513557632342?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/415235513557632342?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/Y_Tl9DMRtVU/alternative-engineering.html" title="Alternative Engineering" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">6</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/10/alternative-engineering.html</feedburner:origLink></entry><entry gd:etag="W/&quot;A0EARn48fyp7ImA9WxNXF0g.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-6876638683177964066</id><published>2009-10-05T17:03:00.004+01:00</published><updated>2009-10-05T17:20:47.077+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-10-05T17:20:47.077+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="humour" /><category scheme="http://www.blogger.com/atom/ns#" term="interfaces" /><category scheme="http://www.blogger.com/atom/ns#" term="failure" /><title>American Express - Which number is greater?</title><summary type="html">Sometimes you just sit there and wonder about how the code managed to get to a certain end point... take my current Amex online bill...Now it could be the surprise that its the lowest monthly bill I've had since I got the card, but I don't quite think that "surprise" is something that should be built into a financial system.  But some how the amount that I have to pay (the last bill) is now less &lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/8EOrV0nO5AA" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/6876638683177964066/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=6876638683177964066" title="1 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/6876638683177964066?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/6876638683177964066?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/8EOrV0nO5AA/american-express-which-number-is.html" title="American Express - Which number is greater?" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="http://3.bp.blogspot.com/_3OcSUeGygTE/SsocukTE0MI/AAAAAAAABjs/1FQlo_KH2iI/s72-c/AMEX-Maths-FAIL.png" height="72" width="72" /><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">1</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/10/american-express-which-number-is.html</feedburner:origLink></entry><entry gd:etag="W/&quot;D0MHQn4yfip7ImA9WxNXFUQ.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-5390259073250192662</id><published>2009-10-03T19:23:00.004+01:00</published><updated>2009-10-03T19:43:53.096+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-10-03T19:43:53.096+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="SaaS" /><category scheme="http://www.blogger.com/atom/ns#" term="PaaS" /><category scheme="http://www.blogger.com/atom/ns#" term="vendors" /><title>In praise of vendor shipped AMI's and virtual machines</title><summary type="html">Roman Stanek is one of those guys who consistently gets things right and his point around AMIs and Virtual Machines not being SaaS is absolutely 100% spot on.  These aren't SaaS solutions they are PaaS solutions and they do indeed leave a huge amount of work for the developer to do.  Part of the problem is of course that the name Software as a Service is of course wrong its really Service as a &lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/k9GtO84HoHM" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/5390259073250192662/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=5390259073250192662" title="3 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/5390259073250192662?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/5390259073250192662?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/k9GtO84HoHM/in-praise-of-vendor-shipped-amis-and.html" title="In praise of vendor shipped AMI's and virtual machines" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">3</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/10/in-praise-of-vendor-shipped-amis-and.html</feedburner:origLink></entry><entry gd:etag="W/&quot;D08BQHk4cSp7ImA9WxNXFEw.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-5541096403754856274</id><published>2009-10-01T17:40:00.003+01:00</published><updated>2009-10-01T17:50:51.739+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-10-01T17:50:51.739+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="games" /><category scheme="http://www.blogger.com/atom/ns#" term="predictions" /><category scheme="http://www.blogger.com/atom/ns#" term="virtualisation" /><title>Why do games need an operating system?</title><summary type="html">Using my iPhone and looking at a PS3 console in Selfridges made me think about what the future could hold for games.  While there are companies looking at doing server side games and a VDI solution to the end device I just don't think that matches against Moore's Law.  But equally the model of downloading and installing loads of games onto a single device with multiple different anti-piracy tools&lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/blTx7hFjin0" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/5541096403754856274/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=5541096403754856274" title="3 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/5541096403754856274?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/5541096403754856274?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/blTx7hFjin0/why-do-games-need-operating-system.html" title="Why do games need an operating system?" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">3</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/10/why-do-games-need-operating-system.html</feedburner:origLink></entry><entry gd:etag="W/&quot;Ak4DQno9fSp7ImA9WxNQF0o.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-4073157272127484970</id><published>2009-09-24T08:34:00.004+01:00</published><updated>2009-09-24T08:56:13.465+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-09-24T08:56:13.465+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="Blueprints" /><category scheme="http://www.blogger.com/atom/ns#" term="REST" /><category scheme="http://www.blogger.com/atom/ns#" term="standards" /><title>REST Blueprints and Reference Architectures</title><summary type="html">Okay so the REST-* stuff appears to have rapidly descended into pointless diatribe which is a shame.  One of the questions is what it should be instead (starting with REST-TX and REST-Messaging wasn't a great idea) and around a few internal and external discussions its come down to a few pointsWhat is "best practice"What is the standard way to document the interactions available &amp; requiredHow do &lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/AYIUr-hpQh8" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/4073157272127484970/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=4073157272127484970" title="9 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/4073157272127484970?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/4073157272127484970?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/AYIUr-hpQh8/rest-blueprints-and-reference.html" title="REST Blueprints and Reference Architectures" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">9</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/09/rest-blueprints-and-reference.html</feedburner:origLink></entry><entry gd:etag="W/&quot;DkEHRHszcSp7ImA9WxNQFUk.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-2980896058042688909</id><published>2009-09-21T10:11:00.000+01:00</published><updated>2009-09-21T15:50:35.589+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-09-21T15:50:35.589+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="people" /><category scheme="http://www.blogger.com/atom/ns#" term="IT" /><category scheme="http://www.blogger.com/atom/ns#" term="practice" /><title>Theory v Practice - the opposite view</title><summary type="html">There is an age old sayingIn theory, practice and theory are the same thing, in practice they aren'tThis is true 90% of the time, but in Engineering it isn't always the case.  I was speaking to someone a day or so ago about interviews and they were nervous as the job they were applying for required a specific programming skill and they had only done "a bit" of it.What I told this poor young fool &lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/oo-2A3Ei5z8" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/2980896058042688909/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=2980896058042688909" title="5 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/2980896058042688909?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/2980896058042688909?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/oo-2A3Ei5z8/theory-v-practice-opposite-view.html" title="Theory v Practice - the opposite view" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">5</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/09/theory-v-practice-opposite-view.html</feedburner:origLink></entry><entry gd:etag="W/&quot;DEcDQHw_eip7ImA9WxNQEUw.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-1445769049641003897</id><published>2009-09-16T13:37:00.004+01:00</published><updated>2009-09-16T16:47:51.242+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-09-16T16:47:51.242+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="REST" /><category scheme="http://www.blogger.com/atom/ns#" term="standards" /><title>REST-* can you please grow up</title><summary type="html">Well didn't Mark Little just thrown in a grenade today around REST-* by daring to suggest that maybe just maybe there needs to be a bit more clarity on how to use REST effectively.As he said this "The REST-* effort might end up documenting what already exists which indicates that part of the challenge is that lots of people don't really know what REST is and certainly struggle as they look to &lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/Z7yIf1l1yE4" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/1445769049641003897/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=1445769049641003897" title="4 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/1445769049641003897?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/1445769049641003897?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/Z7yIf1l1yE4/rest-can-you-please-grow-up.html" title="REST-* can you please grow up" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">4</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/09/rest-can-you-please-grow-up.html</feedburner:origLink></entry><entry gd:etag="W/&quot;D08CRnwzcSp7ImA9WxNQEEQ.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-8957559735347882776</id><published>2009-09-16T09:42:00.005+01:00</published><updated>2009-09-16T11:11:07.289+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-09-16T11:11:07.289+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="economics" /><category scheme="http://www.blogger.com/atom/ns#" term="cloud" /><category scheme="http://www.blogger.com/atom/ns#" term="SaaS" /><category scheme="http://www.blogger.com/atom/ns#" term="XaaS" /><category scheme="http://www.blogger.com/atom/ns#" term="business" /><title>Business Utilities are about levers not CPUs</title><summary type="html">"As a Service" is a moniker tagged against a huge number of approaches.  Often it demonstrates a complete marketing and intelligence fail and regularly it just means a different sort of licensing model."As a Service" tends to mean utility pricing and the best "As a Service" offers have worked out both what their service is and what its utility is.  Salesforce.com have a CRM/Sales Support service &lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/IF7lcuA3VvU" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/8957559735347882776/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=8957559735347882776" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/8957559735347882776?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/8957559735347882776?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/IF7lcuA3VvU/business-utilities-are-about-levers-not.html" title="Business Utilities are about levers not CPUs" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="http://4.bp.blogspot.com/_3OcSUeGygTE/SrC220wCFSI/AAAAAAAABjM/PwN8BtZ0qmY/s72-c/Dashdoard+1.png" height="72" width="72" /><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/09/business-utilities-are-about-levers-not.html</feedburner:origLink></entry><entry gd:etag="W/&quot;DEEBRHkzcSp7ImA9WxNSGUs.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-5140913078405574898</id><published>2009-09-02T17:33:00.003+01:00</published><updated>2009-09-03T09:30:55.789+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-09-03T09:30:55.789+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="people" /><category scheme="http://www.blogger.com/atom/ns#" term="documentation" /><category scheme="http://www.blogger.com/atom/ns#" term="Open Source" /><title>Why I like Open Source documentation</title><summary type="html">I've got someone creating a structured Semantic Wiki for me at the moment and we are using Semantic Forms.  One of the things we needed to do was pre-populate the fields. This means something like{{#forminput:form_name|size|value|button_text|query_string}}With the query string set... The documentation saidquery_string is the set of values that you want passed in through the query string to the &lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/mAz2TVergOs" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/5140913078405574898/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=5140913078405574898" title="1 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/5140913078405574898?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/5140913078405574898?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/mAz2TVergOs/why-i-like-open-source-documentation.html" title="Why I like Open Source documentation" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">1</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/09/why-i-like-open-source-documentation.html</feedburner:origLink></entry><entry gd:etag="W/&quot;A0QMRnY9eSp7ImA9WxNTF0o.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-2487580383570954752</id><published>2009-08-20T15:32:00.002+01:00</published><updated>2009-08-20T15:43:07.861+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-08-20T15:43:07.861+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="REST" /><category scheme="http://www.blogger.com/atom/ns#" term="resource" /><title>What conference calls tell us about REST</title><summary type="html">I've just got off a conference call, the topic isn't important.  What is important is that at the end of the call lots of other people started joining.  Why was this?  Well they were joining the next call that the meeting organiser had.This got me thinking about REST and resource identifiers and why if you are doing REST its really important to understand what the right resource is.  With &lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/gDYFyQ4d-EU" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/2487580383570954752/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=2487580383570954752" title="3 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/2487580383570954752?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/2487580383570954752?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/gDYFyQ4d-EU/what-conference-calls-tell-us-about.html" title="What conference calls tell us about REST" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">3</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/08/what-conference-calls-tell-us-about.html</feedburner:origLink></entry><entry gd:etag="W/&quot;CU8MQ34_fip7ImA9WxJaGEg.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-3276162238056213013</id><published>2009-08-06T13:24:00.003+01:00</published><updated>2009-08-09T22:38:02.046+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-08-09T22:38:02.046+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="standards" /><category scheme="http://www.blogger.com/atom/ns#" term="SaaS" /><category scheme="http://www.blogger.com/atom/ns#" term="ERP" /><category scheme="http://www.blogger.com/atom/ns#" term="business" /><title>Start on the road to SaaS with SPUD</title><summary type="html">Lots of companies are leaping onto SaaS in the manner of a drowning man grabbing onto a tiger shark in the vain hope that all will be fine.  The problem is that they haven't really thought about what they want and what it takes to properly adopt SaaS so what they do is take the same old approach to package adoptionWork out what you want to doBuy a package/SaaS solution to do some of itCustomise &lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/ytE-XzrrsOg" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/3276162238056213013/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=3276162238056213013" title="1 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/3276162238056213013?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/3276162238056213013?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/ytE-XzrrsOg/start-on-road-to-saas-with-spud.html" title="Start on the road to SaaS with SPUD" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">1</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/08/start-on-road-to-saas-with-spud.html</feedburner:origLink></entry><entry gd:etag="W/&quot;Dk4HRn09cSp7ImA9WxJVFk4.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-5157282899543960357</id><published>2009-07-03T16:02:00.003+01:00</published><updated>2009-07-03T16:28:57.369+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-07-03T16:28:57.369+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="cloud" /><category scheme="http://www.blogger.com/atom/ns#" term="public" /><category scheme="http://www.blogger.com/atom/ns#" term="private" /><title>Vendor Managed Infrastructure - Are clouds just a VMI solution?</title><summary type="html">Tweeting with Neil Ward-Dutton I had a thought about what he has written on public v private clouds and it made me think that the only real difference between them is in the who manages and pays.  This might sound like a big thing but taking a leaf out of the retailers book it doesn't need to be that large.Vendor Managed Inventory is simply where a supplier takes over the management of a products&lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/P7SnkGFCInA" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/5157282899543960357/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=5157282899543960357" title="1 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/5157282899543960357?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/5157282899543960357?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/P7SnkGFCInA/vendor-managed-infrastructure-are.html" title="Vendor Managed Infrastructure - Are clouds just a VMI solution?" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">1</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/07/vendor-managed-infrastructure-are.html</feedburner:origLink></entry><entry gd:etag="W/&quot;CUENQHY_eCp7ImA9WxJVEkw.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-5241343062259733132</id><published>2009-06-25T21:48:00.000+01:00</published><updated>2009-06-28T19:28:11.840+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-06-28T19:28:11.840+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="systems" /><category scheme="http://www.blogger.com/atom/ns#" term="SOA" /><category scheme="http://www.blogger.com/atom/ns#" term="people" /><category scheme="http://www.blogger.com/atom/ns#" term="debt" /><title>When successful systems go bad - boiling frogs with Technical Debt</title><summary type="html">One of the challenges I often see in companies is when successful systems go bad.  These aren't the systems that were delivered 3 times over time and 5 times the budget, these are the systems that many years ago delivered real benefits for the business and delivered in a reasonable time and budget.The problem is that all those years ago the team in question was focused absolutely on getting the &lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/eHkY3LawuwY" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/5241343062259733132/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=5241343062259733132" title="1 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/5241343062259733132?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/5241343062259733132?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/eHkY3LawuwY/when-successful-systems-go-bad-boiling.html" title="When successful systems go bad - boiling frogs with Technical Debt" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">1</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/06/when-successful-systems-go-bad-boiling.html</feedburner:origLink></entry><entry gd:etag="W/&quot;DEMDRXo_eip7ImA9WxJWGE8.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-9065876163880333794</id><published>2009-06-24T07:34:00.002+01:00</published><updated>2009-06-24T07:54:34.442+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-06-24T07:54:34.442+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="humour" /><category scheme="http://www.blogger.com/atom/ns#" term="SOA" /><category scheme="http://www.blogger.com/atom/ns#" term="SaaS" /><category scheme="http://www.blogger.com/atom/ns#" term="religion" /><title>Religion as a Service</title><summary type="html">Okay a few weeks ago I had a brain-wave for a new business.  What do you really need for a business to take off in the "as a Service" space?It needs to be 80%+ commodityYou need a large customer baseYou need the end customer to add their own differentiationAbove all I wanted a business that would be a much higher margin one than simply a SaaS business, which meant including the actual business &lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/3urW6nhUe80" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/9065876163880333794/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=9065876163880333794" title="1 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/9065876163880333794?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/9065876163880333794?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/3urW6nhUe80/religion-as-service.html" title="Religion as a Service" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">1</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/06/religion-as-service.html</feedburner:origLink></entry><entry gd:etag="W/&quot;DEABQ345eSp7ImA9WxJWEkU.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-9108291359483676146</id><published>2009-06-18T01:53:00.002+01:00</published><updated>2009-06-18T01:59:12.021+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-06-18T01:59:12.021+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="SOA" /><category scheme="http://www.blogger.com/atom/ns#" term="clint eastwood" /><category scheme="http://www.blogger.com/atom/ns#" term="change" /><category scheme="http://www.blogger.com/atom/ns#" term="business" /><title>The Clint Eastwood school of change</title><summary type="html">Change is hard, change against people who don't want to change is extremely hard bordering on impossible.  In any change programme therefore you need to be clear about what you are up against and what success looks like.This is where Clint Eastwood can help.  Sure Chuck Norris can run around the world and punch himself in the back of the head but Clint Eastwood has many more lessons on delivering&lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/zp1prlI7bqI" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/9108291359483676146/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=9108291359483676146" title="5 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/9108291359483676146?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/9108291359483676146?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/zp1prlI7bqI/clint-eastwood-school-of-change.html" title="The Clint Eastwood school of change" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">5</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/06/clint-eastwood-school-of-change.html</feedburner:origLink></entry><entry gd:etag="W/&quot;AkcFQX48eyp7ImA9WxJWEU4.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-6219713423048791420</id><published>2009-06-16T08:14:00.004+01:00</published><updated>2009-06-16T08:40:10.073+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-06-16T08:40:10.073+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="IBM" /><category scheme="http://www.blogger.com/atom/ns#" term="cloud" /><title>Why would a cloud appliance be physical?</title><summary type="html">IBM often lead in technology areas and with the history of LPAR on the mainframe they've got a background in virtualisation that most competitors would envy.  So clearly with cloud they are going to go after it.  Sometimes they'll do what they did with SOA and tag a (IMO) dog of a product with the new buzzword (MQSI = Advanced ESB - I'm looking at you) and other times they will actually do &lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/tORHo67EapI" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/6219713423048791420/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=6219713423048791420" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/6219713423048791420?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/6219713423048791420?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/tORHo67EapI/why-would-cloud-appliance-be-physical.html" title="Why would a cloud appliance be physical?" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/06/why-would-cloud-appliance-be-physical.html</feedburner:origLink></entry><entry gd:etag="W/&quot;A0YERXo_cCp7ImA9WxJXF0Q.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-168837047103034359</id><published>2009-06-12T10:15:00.004+01:00</published><updated>2009-06-12T10:31:44.448+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-06-12T10:31:44.448+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="SOA" /><category scheme="http://www.blogger.com/atom/ns#" term="SaaS" /><category scheme="http://www.blogger.com/atom/ns#" term="canonical form" /><title>Single Canonical Form?  Only Suicidal Dinosaurs need apply</title><summary type="html">Now I said a while ago that Single Canonical form wasn't for SOA well now I've been doing some SaaS projects and I've realised with traditional modesty that not only am I right, but that people who are still pushing it as an approach can be described as suicidal dinosaurs.If SaaS is anywhere in your future, and it will be unless you are a military secure establishment and even then it might me, &lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/UdN7yrL5knk" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/168837047103034359/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=168837047103034359" title="5 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/168837047103034359?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/168837047103034359?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/UdN7yrL5knk/single-canonical-form-only-suicidal.html" title="Single Canonical Form?  Only Suicidal Dinosaurs need apply" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">5</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/06/single-canonical-form-only-suicidal.html</feedburner:origLink></entry><entry gd:etag="W/&quot;AkQMRH07eSp7ImA9WxJXF0Q.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-3959753805937714179</id><published>2009-06-01T23:28:00.001+01:00</published><updated>2009-06-12T10:19:45.301+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-06-12T10:19:45.301+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="economics" /><category scheme="http://www.blogger.com/atom/ns#" term="SaaS" /><title>The challenge of "build for the web" to SaaS economic models</title><summary type="html">Build for the web is a strong meme.  Most of the time people focus on the technical elements of this and the end user elements.  What I haven't seen people talk about much is the impact that this has on the current financial models from SaaS vendors. SaaS can give great benefits for companies by enabling an OpEx rather than CapEx model but the solutions today do assume that a person is using them&lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/Ctx-k4RKqWk" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/3959753805937714179/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=3959753805937714179" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/3959753805937714179?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/3959753805937714179?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/Ctx-k4RKqWk/he-challenge-of-build-for-web-to-saas.html" title="The challenge of &quot;build for the web&quot; to SaaS economic models" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="http://1.bp.blogspot.com/_3OcSUeGygTE/SiRJc1ML68I/AAAAAAAABV0/OIIR7GWkhnY/s72-c/SaaSbasic.png" height="72" width="72" /><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/06/he-challenge-of-build-for-web-to-saas.html</feedburner:origLink></entry><entry gd:etag="W/&quot;C0cGQXwzfSp7ImA9WxJQGEQ.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-6212913434013798237</id><published>2009-06-01T08:58:00.000+01:00</published><updated>2009-06-01T22:17:00.285+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-06-01T22:17:00.285+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="package" /><category scheme="http://www.blogger.com/atom/ns#" term="SOA" /><category scheme="http://www.blogger.com/atom/ns#" term="cloud" /><category scheme="http://www.blogger.com/atom/ns#" term="SaaS" /><category scheme="http://www.blogger.com/atom/ns#" term="ERP" /><title>SaaS and the Cloud a development challenge</title><summary type="html">A while back I blogged on how to do ERP with a middleware solution.  The point was to leave the package untouched while adding your customisations in an environment that was better suited to the challenge.  It made upgrades easier and also would help to reduce your development timescales.Well the world is moving on and now I'm looking at a challenge of SaaS + cloud.  A standardised package &lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/4hv8U2vpZxM" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/6212913434013798237/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=6212913434013798237" title="1 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/6212913434013798237?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/6212913434013798237?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/4hv8U2vpZxM/saas-and-cloud-development-challenge.html" title="SaaS and the Cloud a development challenge" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="http://1.bp.blogspot.com/_3OcSUeGygTE/SiRE2423_6I/AAAAAAAABVs/whbWs-1gM5g/s72-c/SaaSandPackage.png" height="72" width="72" /><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">1</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/06/saas-and-cloud-development-challenge.html</feedburner:origLink></entry><entry gd:etag="W/&quot;DkUESX0_eSp7ImA9WxJQEks.&quot;"><id>tag:blogger.com,1999:blog-11168006.post-61149639826381985</id><published>2009-05-25T14:57:00.005+01:00</published><updated>2009-05-25T16:10:08.341+01:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-05-25T16:10:08.341+01:00</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="predictions" /><category scheme="http://www.blogger.com/atom/ns#" term="cloud" /><category scheme="http://www.blogger.com/atom/ns#" term="Apple" /><title>Will Apple dominate the cloud?</title><summary type="html">At dinner the other night with a friend we were talking about what we wanted the iPhone to do.  We agreed that a new camera would be good but neither of us thought that a forward facing camera had any point as we don't know anyone who has made more than two video calls despite having phones that could do it.So what we thought would be really good for the 4th Generation iPhone?  In particular what&lt;img src="http://feeds.feedburner.com/~r/ServiceArchitecture/~4/c8GIgyzh3hs" height="1" width="1"/&gt;</summary><link rel="replies" type="application/atom+xml" href="http://service-architecture.blogspot.com/feeds/61149639826381985/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=11168006&amp;postID=61149639826381985" title="1 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/61149639826381985?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/11168006/posts/default/61149639826381985?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/ServiceArchitecture/~3/c8GIgyzh3hs/will-apple-dominate-cloud.html" title="Will Apple dominate the cloud?" /><author><name>Steve Jones</name><uri>http://www.blogger.com/profile/18324989580856894788</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="01403912785657473695" /></author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="http://2.bp.blogspot.com/_3OcSUeGygTE/Shqy8fyUPeI/AAAAAAAABU8/Ug5bxbjJD_s/s72-c/iTunes.png" height="72" width="72" /><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">1</thr:total><feedburner:origLink>http://service-architecture.blogspot.com/2009/05/will-apple-dominate-cloud.html</feedburner:origLink></entry></feed>
