<?xml version="1.0"?>
<rss version="2.0">
<channel>
  <title>Coding the Architecture - transition tag</title>
  <link>http://www.codingthearchitecture.com/tags/transition/</link>
  <description>Software architecture for developers</description>
  <language>en</language>
  <copyright>Coding the Architecture</copyright>
  <lastBuildDate>Mon, 21 May 2012 09:41:00 GMT</lastBuildDate>
  <generator>Pebble (http://pebble.sourceforge.net)</generator>
  <docs>http://backend.userland.com/rss</docs>
  
  
  <item>
    <title>Architects during the transition phase</title>
    <link>http://www.codingthearchitecture.com/2007/08/13/architects_during_the_transition_phase.html</link>
    
      
        <description>
          &lt;p&gt;
If you view the software development cycle from a RUP perspective, the &lt;a href=&#034;http://en.wikipedia.org/wiki/Rational_Unified_Process#Transition_phase&#034;&gt;transition phase&lt;/a&gt; is all about ensuring operational quality and moving the system into production deployment. Nothing new here, but what&#039;s interesting is that most architecture roles (certainly from my consulting experience) are mainly focussed around the start of the project life cycle. Of course, the start of the project is where all of the fun starts - complex decisions are made, designs are done, the architecture is proved and so on. Once the &#034;complex&#034; stuff has been completed, the time spent doing &#034;architecture&#034; typically decreases, with architects either taking on a part-time role, being involved in the hands-on construction elements or simply rolling off of the project. This raises an interesting question - how long should the architect remain on the project? Moreover, should the architect remain engaged with the project during the transition phase of the project?
&lt;/p&gt;

&lt;p&gt;
Conventional wisdom says that software architects are expensive so it&#039;s in everybody&#039;s interest that they roll-off the project as soon as possible. In a consulting/outsourced engagement, this results in cost savings for the project (customer) and the architect gets to move on to do more &#034;architecture&#034; work elsewhere.
&lt;p&gt;

&lt;p&gt;
That&#039;s just one viewpoint and my take on this is that architects should absolutely remain engaged with the project until it comes to a successful conclusion. After all, architects are responsible for ensuring the non-functional requirements are satisfied and they probably have the best overview of the system from several different perspectives; ranging from the functional and logical views of the system right through to other aspects such as the system interfaces, security and the physical deployment. In my mind, losing this knowledge so close to the end of the project could prove disastrous, particularly if complex deployment issues arise and only a skeleton project team of developers remains.
&lt;/p&gt;

&lt;p&gt;
What do you think? Should architects remain engaged with the project until it&#039;s successfully delivered and deployed into production, in either a full-time or part-time capacity? Or should they roll-off as soon as possible? Is this cost effective or a false economy?
&lt;/p&gt;
        </description>
      
      
    
    
    
    <category>What is the the role of a software architect?</category>
    
    <comments>http://www.codingthearchitecture.com/2007/08/13/architects_during_the_transition_phase.html#comments</comments>
    <guid isPermaLink="true">http://www.codingthearchitecture.com/2007/08/13/architects_during_the_transition_phase.html</guid>
    <pubDate>Mon, 13 Aug 2007 19:45:00 GMT</pubDate>
  </item>
  
  </channel>
</rss>

