Clever is complex, simple is clever

As an architect, you'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're building a new website to replace a couple of sites that exist already. Also, let's say that all users of the new website must re-register their accounts in order to consolidate their logins across the existing sites.

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.

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'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 Acegi) 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?

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

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

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.

About the author

Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.

You can find Simon on Twitter at @simonbrown ... see for information about his speaking schedule, videos from past conferences and software architecture training.

Re: Simplicity

Simplicity is, of course, subjective. The argument presented seems to be balanced but is this merely because we're projecting our own expectations and experience? What would my dad make of a form asking him to "re-register for the new site"? Dunno. But a phone call to a relative may well be involved...

Naturally you know that when you say "much simpler" you implicitly add "with respect to all the requirements I'm balancing". Beware what the development team and business analysts are implicitly adding - they may not see your solution as "much simpler"!

Finding that appropriate balance of requirements requires that an appropriate weight be given to each viewpoint. Additionally, the social role of an architect requires that appropriate language be used for each.

Re: Simplicity

a simple solution as you described is'nt as fun to develop as a complex solution. The developers and purhaps your self could easily choose the complex solution to get a challange.


Add a comment Send a TrackBack