<?xml version="1.0"?>
<rss version="2.0">
<channel>
  <title>Coding the Architecture - duediligence tag</title>
  <link>http://www.codingthearchitecture.com/tags/duediligence/</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>Trusted advisers</title>
    <link>http://www.codingthearchitecture.com/2007/08/22/trusted_advisers.html</link>
    
      
        <description>
          &lt;p&gt;
If you take a look at most organisations, it&#039;s fairly obvious that technology is there to support the business - it&#039;s there to enable new business, make existing business more efficient, reduce costs and so on. With technology taking on this subservient role, it should come as no surprise that &#034;the business&#034; is often lured head-first into new technology because of the &#034;business benefit&#034; that it offers. Sometimes this is coupled with fancy marketing, a visit to the golf course, champagne on a yacht, tickets to an international rugby game or whatever. It&#039;s all very appealing, but unfortunately technology purchases aren&#039;t that straightforward and you shouldn&#039;t always believe the hype.
&lt;/p&gt;

&lt;p&gt;
As technologists, it seems to be a fairly common occurrence to find ourselves stuck with a technology that we didn&#039;t choose or don&#039;t like. Worse still, we could find ourselves stuck with a technology that simply isn&#039;t fit for purpose, despite what it says in the glossy marketing material. Case in point - a city organisation has bought into a technology that will help deliver real-time streaming market data to their clients anywhere on the Internet. Sounds fantastic, until you look under the hood. In this particular instance, the system in question doesn&#039;t actually do any streaming (it polls for new data once a second) and the vendor company doesn&#039;t know what the performance/scalability limits of the system are. Having briefly looked at the implementation myself, I was able to come up with about a dozen *basic* questions that I couldn&#039;t find answers to. I can also think of numerous times where I&#039;ve seen a project trying to cram some functionality into a product that it simply wasn&#039;t designed to do.
&lt;/p&gt;

&lt;p&gt;
I&#039;m more than happy to let the business take the lead and define their technology requirements, but it&#039;s *essential* that they involve technologists in any technology decisions they want to make. Early involvement from technologists could really save a massive amount of money and prevent the wrong technology from being purchased. It could also prevent technologists feeling isolated and resenting the organisation in which they work.
&lt;/p&gt;

&lt;p&gt;
The problem many organisations have is that they don&#039;t know who to turn to for advice in helping them make these sorts of purchasing decisions. I&#039;d like to offer a solution to this - experienced technical architects are able to fulfil this role because they have a good understanding of the business and a good understanding of what technology needs to do in order to support the business. Also, technical architects are well placed to ask those &#034;tricky&#034; questions, such as &#034;what technologies does this use under the hood?&#034;, &#034;how exactly are you doing that?&#034; and &#034;how do you support high availability?&#034;.
&lt;/p&gt;

&lt;p&gt;
I&#039;ve performed this role many times in the past and it&#039;s provided valuable insight that has either strengthened or weakened a purchasing decision. It works both ways and is equally applicable regardless of whether you&#039;re looking to purchase a single technology, and entire stack or even acquire another organisation. With a broad ranging yet technically deep skill-set, technical architects have the ability to make excellent trusted advisers.
&lt;/p&gt;
        </description>
      
      
    
    
    
    <category>What is the the role of a software architect?</category>
    
    <comments>http://www.codingthearchitecture.com/2007/08/22/trusted_advisers.html#comments</comments>
    <guid isPermaLink="true">http://www.codingthearchitecture.com/2007/08/22/trusted_advisers.html</guid>
    <pubDate>Wed, 22 Aug 2007 08:39:00 GMT</pubDate>
  </item>
  
  </channel>
</rss>

