<?xml version="1.0" encoding="utf-8"?>
<feed xml:lang="en-us" xmlns="http://www.w3.org/2005/Atom"><title>Simon Willison's Weblog: service-oriented-architecture</title><link href="http://simonwillison.net/" rel="alternate"/><link href="http://simonwillison.net/tags/service-oriented-architecture.atom" rel="self"/><id>http://simonwillison.net/</id><updated>2019-05-14T18:32:36+00:00</updated><author><name>Simon Willison</name></author><entry><title>Amazon’s Away Teams laid bare: How AWS's hivemind of engineers develop and maintain their internal tech</title><link href="https://simonwillison.net/2019/May/14/amazons-away-teams/#atom-tag" rel="alternate"/><published>2019-05-14T18:32:36+00:00</published><updated>2019-05-14T18:32:36+00:00</updated><id>https://simonwillison.net/2019/May/14/amazons-away-teams/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="https://www.theregister.co.uk/2019/05/14/amazons_away_teams/"&gt;Amazon’s Away Teams laid bare: How AWS&amp;#x27;s hivemind of engineers develop and maintain their internal tech&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Some interesting insights into how Amazon structure their engineering organization to maximize team productivity in a service-oriented environment. Two things that stood out to me: each service is owned by a “home team”, but sometimes features that are needed by other teams can be built by forming an “away team” to build out that functionality. Secondly, Amazon has a concept of “bar raisers” who are engineers across the organization who help approve key design and architectural decisions. It’s possible to go against the recommendation of a bar raiser but “such a move is noted and made visible to higher levels of management”.

    &lt;p&gt;&lt;small&gt;&lt;/small&gt;Via &lt;a href="https://twitter.com/cote/status/1128202812515594240"&gt;@cote&lt;/a&gt;&lt;/small&gt;&lt;/p&gt;


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/amazon"&gt;amazon&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/service-oriented-architecture"&gt;service-oriented-architecture&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/management"&gt;management&lt;/a&gt;&lt;/p&gt;



</summary><category term="amazon"/><category term="service-oriented-architecture"/><category term="management"/></entry><entry><title>Quoting Pete Lacey</title><link href="https://simonwillison.net/2007/Oct/6/pete/#atom-tag" rel="alternate"/><published>2007-10-06T01:44:26+00:00</published><updated>2007-10-06T01:44:26+00:00</updated><id>https://simonwillison.net/2007/Oct/6/pete/#atom-tag</id><summary type="html">
    &lt;blockquote cite="http://wanderingbarque.com/nonintersecting/2007/10/05/what-is-soa/"&gt;&lt;p&gt;SOA [...] is the generally held belief that when implementing systems one should expose system functionality for general consumption directly from the network, as well as or instead of burying it behind a user interface.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p class="cite"&gt;&amp;mdash; &lt;a href="http://wanderingbarque.com/nonintersecting/2007/10/05/what-is-soa/"&gt;Pete Lacey&lt;/a&gt;&lt;/p&gt;

    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/definitions"&gt;definitions&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/pete-lacey"&gt;pete-lacey&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/service-oriented-architecture"&gt;service-oriented-architecture&lt;/a&gt;&lt;/p&gt;



</summary><category term="definitions"/><category term="pete-lacey"/><category term="service-oriented-architecture"/></entry><entry><title>FIPA Abstract Architecture</title><link href="https://simonwillison.net/2007/Jan/17/fipa/#atom-tag" rel="alternate"/><published>2007-01-17T23:32:06+00:00</published><updated>2007-01-17T23:32:06+00:00</updated><id>https://simonwillison.net/2007/Jan/17/fipa/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://www.dehora.net/journal/2007/01/fipa_abstract_architecture.html"&gt;FIPA Abstract Architecture&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Bill de hÓra shows how the work of the Intelligent Agents community relates to SOA / WS-*. We studied FIPA at University and the parallels to parts of the Web Service stack are pretty interesting.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/bill-de-hora"&gt;bill-de-hora&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/fipa"&gt;fipa&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/service-oriented-architecture"&gt;service-oriented-architecture&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/ai-agents"&gt;ai-agents&lt;/a&gt;&lt;/p&gt;



</summary><category term="bill-de-hora"/><category term="fipa"/><category term="service-oriented-architecture"/><category term="ai-agents"/></entry></feed>