<?xml version="1.0"?>
<rss version="2.0">
<channel>
  <title>Coding the Architecture - ivorytower tag</title>
  <link>http://www.codingthearchitecture.com/tags/ivorytower/</link>
  <description>Software architecture for developers</description>
  <language>en</language>
  <copyright>Coding the Architecture</copyright>
  <lastBuildDate>Wed, 16 May 2012 08:01:04 GMT</lastBuildDate>
  <generator>Pebble (http://pebble.sourceforge.net)</generator>
  <docs>http://backend.userland.com/rss</docs>
  
  
  <item>
    <title>Infrastructure architecture and the similarities to software</title>
    <link>http://www.codingthearchitecture.com/2008/02/06/infrastructure_architecture_and_the_similarities_to_software.html</link>
    
      
        <description>
          &lt;p&gt;
I&#039;ve just finished working on a review of the infrastructure architecture behind a number of fairly large media websites. Infrastructure isn&#039;t really my speciality&lt;sup&gt;1&lt;/sup&gt;, but what I found interesting about this piece of work was the number of direct comparisons that can be made with software architecture.
&lt;/p&gt;

&lt;p&gt;
This particular environment had a group of thinkers (the architects) and a group of do&#039;ers (the team looking after the infrastructure boxes). As with many software projects, the architect team have become detached from the day to day reality of the infrastructure and see their job as predominantly forward facing. For example, they look at new technology and how the infrastructure can be modified in the future, leaving the do&#039;ers to get their hands dirty with the day to day operational aspects. This reminds me of ivory tower software architects dictating technology decisions to developers without truly understanding the nitty-gritty of the real-world requirements. It&#039;s the type of situation in which I can see &lt;a href=&#034;http://www.codingthearchitecture.com/2007/05/14/the_hand_off.html&#034;&gt;the hand-off&lt;/a&gt; taking place.
&lt;/p&gt;

&lt;p&gt;
One of the complexities with this particular environment stems from the fact that the do&#039;ers are actually split into multiple teams, with each team representing a different part of the architecture. While this isn&#039;t necessarily bad, the problem is that there is no single technical authority; be it a single person or a team with wide representation. With a lack of clearly defined technical authority, each team works within their own silo and, as with many software projects, inconsistencies evolve.
&lt;/p&gt;

&lt;p&gt;
In summary then, ivory towers aren&#039;t unique to software architecture and although somebody needs to own the coherent vision, they also need to be aware of the day to day problems that are being solved in the real-world.


&lt;p&gt;
&lt;sup&gt;1&lt;/sup&gt; thankfully I had a good team of SMEs with me; I naively just assume that the network people will wire my boxes up in the right way :-)
&lt;/p&gt;
        </description>
      
      
    
    
    
    <category>What is the the role of a software architect?</category>
    
    <comments>http://www.codingthearchitecture.com/2008/02/06/infrastructure_architecture_and_the_similarities_to_software.html#comments</comments>
    <guid isPermaLink="true">http://www.codingthearchitecture.com/2008/02/06/infrastructure_architecture_and_the_similarities_to_software.html</guid>
    <pubDate>Wed, 06 Feb 2008 11:41:23 GMT</pubDate>
  </item>
  
  <item>
    <title>The non-coding architect</title>
    <link>http://www.codingthearchitecture.com/2007/07/02/the_non_coding_architect.html</link>
    
      
        <description>
          &lt;p&gt;
I found a great blog entry today by Frank Kelly called 
&lt;a href=&#034;http://softarc.blogspot.com/2007/06/how-to-spot-dreaded-non-coding.html&#034;&gt;How to spot the dreaded non-coding architect&lt;/a&gt; (NCA), which is about some of the differences between architects that can code and architects that can&#039;t (or don&#039;t). Since this site is about &#034;coding the architecture&#034;, I thought you might find it interesting too.
&lt;/p&gt;

&lt;blockquote&gt;
These NCA folks can be really quite dangerous and give dev teams a bad name ... But how can you spot one? For most developers it&#039;s pretty easy but just in case you can&#039;t I&#039;ve compiled a list of example scenarios that should help - comparing the often dogmatic attitude of the NCA with the pragmatism of the experienced Coding Architect (CA).
&lt;/blockquote&gt;

&lt;p&gt;
Recommended reading and a little humour to brighten up your Monday.
&lt;/p&gt;
        </description>
      
      
    
    
    
    <category>What is the the role of a software architect?</category>
    
    <comments>http://www.codingthearchitecture.com/2007/07/02/the_non_coding_architect.html#comments</comments>
    <guid isPermaLink="true">http://www.codingthearchitecture.com/2007/07/02/the_non_coding_architect.html</guid>
    <pubDate>Mon, 02 Jul 2007 19:14:00 GMT</pubDate>
  </item>
  
  </channel>
</rss>

