<?xml version="1.0"?>
<rss version="2.0">
<channel>
  <title>Coding the Architecture - simplicity tag</title>
  <link>http://www.codingthearchitecture.com/tags/simplicity/</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>Simplicity</title>
    <link>http://www.codingthearchitecture.com/2006/02/17/simplicity.html</link>
    
      
        <description>
          &lt;p&gt;
As an architect, you&#039;ll undoubtedly be called upon to make decisions about how a particular requirement should be fulfilled. Remember, you bring together the appropriate balance between functional and non-functional requirements to produce what the end-users need. However, some decisions are easy and others are hard. To take an example, imagine that you&#039;re building a new website to replace a couple of sites that exist already. Also, let&#039;s say that all users of the new website must re-register their accounts in order to consolidate their logins across the existing sites.
&lt;/p&gt;

&lt;p&gt;
Now, clearly there several ways to make this happen. The first of these is to provide a transparent re-registration process so that users can enter their existing username/password combination. Upon logging in with these credentials, an initial attempt is made to authenticate them against the new consolidated authentication realm and, when this subsequently fails, tries to authenticate them against the existing realms. Assuming that the user is authenticated against one of these existing realms, their credentials are then automatically migrated into the new realm.
&lt;/p&gt;

&lt;p&gt;
Ideally, this is great because users can just use the new website without any knowledge of the re-registration process because they use their existing username/password as normal. From a technical perspective, however, this raises some interesting issues, particularly if you want to take advantage of something like Java EE&#039;s container managed authentication or any other mechanism that expects you to perform authentication in a specific way. True, you could customize a security framework (such as &lt;a href=&#034;http://acegisecurity.org&#034;&gt;Acegi&lt;/a&gt;) to incorporate this credential migration behaviour, but would you really want to pollute a simple authentication process with it? Think about how difficult this would become to implement/test and what happens if a particular username is shared by different users across the different existing realms?
&lt;/p&gt;

&lt;p&gt;
There is, of course, a much simpler solution whereby the user is offered a facility to explicitly migrate their account via a &#034;click here if you&#039;ve not used the new site before&#034; link. Just think about it. No complex authentication/migration logic and the user knows exactly what&#039;s going on because you can explicitly ask them for a specific username/password combination.
&lt;/p&gt;

&lt;p&gt;
For me, the latter solution represents something that&#039;s much easier to design, build and test, which leads me to imply that it&#039;s going to be developed quicker. Also, it&#039;s potentially more secure and can easily be &#034;switched off&#034; when it&#039;s deemed that all users have (or should have) migrated their existing accounts.
&lt;/p&gt;

&lt;p&gt;
Simplicity is something that an architect should strive for, especially when the elements (such as time) are against you. Clever solutions are often complex, but simple ones can be clever. Always strive for simplicity.
&lt;/p&gt;
        </description>
      
      
    
    
    
    <category>How do you define software architecture?</category>
    
    <comments>http://www.codingthearchitecture.com/2006/02/17/simplicity.html#comments</comments>
    <guid isPermaLink="true">http://www.codingthearchitecture.com/2006/02/17/simplicity.html</guid>
    <pubDate>Fri, 17 Feb 2006 21:24:29 GMT</pubDate>
  </item>
  
  </channel>
</rss>

