<?xml version="1.0"?>
<rss version="2.0">
<channel>
  <title>Coding the Architecture - non functional requirements tag</title>
  <link>http://www.codingthearchitecture.com/tags/non functional requirements/</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>Mind the gap again</title>
    <link>http://www.codingthearchitecture.com/2008/08/04/mind_the_gap_again.html</link>
    
      
        <description>
          &lt;p&gt;
I did some technical consulting/due diligence on a large software development project recently where I&#039;d been called in to look at how the project team was dealing with some of the non-functional requirements. I&#039;m not sure exactly how large the project team was, but it was somewhere over 50 people and the project itself was subdivided into a number of smaller teams, where each team was responsible for looking after a small subsystem within the overall architecture.
&lt;/p&gt;

&lt;p&gt;
The summary of my review was that very little thought has gone into the non-functional requirements and that retrospectively performing some non-functional testing *could* expose a whole host of problems that are expensive to fix. One of the reasons for the lack of work on the non-functional requirements is that each of the subsystem teams basically doesn&#039;t have an architect. Instead, they have a Technical Project Manager and a Technical Team Lead, with definitions as follows (I&#039;m simplifying this a little). 
&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;b&gt;Technical Project Manager&lt;/b&gt; : a generalist rather than specialist, and somebody that has a technology background but doesn&#039;t necessarily understand technology in great detail.&lt;/li&gt;
&lt;li&gt;&lt;b&gt;Technical Team Lead&lt;/b&gt; : depending on the team, this person is either similar to the Technical Project Manager but working at a lower level of detail, or it&#039;s the lead developer.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;
This sort of team/resource profile isn&#039;t actually that uncommon and I see many project teams that are organised in this way. In essence, teams get in a Technical Project Manager because they think people in this role can successfully undertake the project management *and* architecture roles on the project. Unfortunately, my experience suggests that this isn&#039;t always the most successful approach.
&lt;/p&gt;

&lt;p&gt;
In &lt;a href=&#034;http://www.jrothman.com/weblog/2005/04/i-need-technical-project-manager.html&#034;&gt;I Need a Technical Project Manager&lt;/a&gt;, Johanna Rothman talks about the dynamics of taking on both the project management and architecture roles. Specifically, she says that one of the roles usually has to give way, and I agree. Coming back to the project I was reviewing, the basic problem was this - the Technical Project Managers didn&#039;t have enough experience of dealing with the architecture aspects (including NFRs). As for the Technical Team Leads, the same thing applies (their focus is generally at a lower level), but in addition they don&#039;t have the &lt;a href=&#034;http://www.codingthearchitecture.com/2007/05/21/authority.html&#034;&gt;authority&lt;/a&gt; to make architectural decisions. Also, with both roles, it&#039;s hard to ascertain exactly who has the &lt;a href=&#034;http://www.codingthearchitecture.com/2007/05/16/responsibility.html&#034;&gt;responsibility&lt;/a&gt; for something like the non-functional requirements.
&lt;/p&gt;

&lt;p&gt;
I see this pattern crop up fairly regularly, and it&#039;s a variation of what I talk about in my &lt;a href=&#034;http://www.codingthearchitecture.com/pages/book/mind-the-gap.html&#034;&gt;Mind the gap&lt;/a&gt; essay, where key responsibilities fall down the gap between team members. The easiest way to fix this sort of problem is to be explicit about the roles/responsibilities when starting the project. And that means pinning those responsibilities on somebody.
&lt;/p&gt;
        </description>
      
      
    
    
    
    <category>What is the the role of a software architect?</category>
    
    <comments>http://www.codingthearchitecture.com/2008/08/04/mind_the_gap_again.html#comments</comments>
    <guid isPermaLink="true">http://www.codingthearchitecture.com/2008/08/04/mind_the_gap_again.html</guid>
    <pubDate>Mon, 04 Aug 2008 16:12:46 GMT</pubDate>
  </item>
  
  </channel>
</rss>

