When should server maintenance affect implementation descisions?

Question

Here's my situation...

I'm writing a .Net/C# security system (authorization and authentication) for a large collection of web applications that require a single sign-on process. I'm using Active Directory as a data store and have written a very nice prototype that communicates with AD through LDAP. This component retrieves information about the logged in user that I have stored in AD which I then use to set their security roles in .Net forms authentication.

1) All is good.

Not being a System Admin, or Network Engineer, I wasn't familiar with the amount of system administration involved with setting up an AD instance. I wasn't aware that for each domain, I needed a separate server and domain controller. As it turns out, there are like 9 different domains that my team requires to be set up for all of the different environments that we're going to be accessing AD...

• env1.dev.mycompany.com
• env1.qa.mycompany.com
• env1.stage.mycompany.com
• env2.dev.mycompany.com
• etc

...So now I have placed on upon myself somewhat of an administrative headache because I'm going to have to maintain all of these machines (or VM's), which is something that I'm not necessarily sure I want to do.

2) All is not good.

The prototype is really solid, and AD makes for a very good database for the solution, but now I'm wondering if I should scrap the code and write a SQL Server data provider instead (I know .Net already provides one, but it doesn't alone fit my business requirements for authorization).

Anyway, so I'm trying to think through this problem from a high level perspective. In general, I keep tripping over the fact that I would be throwing a really good solution just because of some server maintenance? I'm wondering if anyone here has experienced a scenario like this and what exactly you decided to do.

Doesn't have to be specific to AD either, just a situation where you had to evaluate between a good software solution and it's server maintenance constraints.

Answer 1

In general, the usability of a product is what makes people to choose between it and similar products. If the product has bad usability, the users won't care how high quality its code is - all that matters to them is how easy and effective it is to use and how well it fills their needs.

Maintenance can be thought as one aspect of usability. I would make it top priority to have an easily maintainable product. In the long run that will save many hours of work from the administrators.

One way to think about it, is first designing what would be the most usable solution from the end user's/administrator's viewpoint, and then making it an intellectual challenge to actually implement that optimal solution. It will probably require more effort from the programmer, but the end result will be better.

For example ZFS is one product where maintenance has been taken care of well (although I have not used it personally). When it was designed, much effort was put into making it easy to administer the file system with ZFS's command line tools - and those design decisions affect all levels of ZFS (for example storage pools).

As another example, I've been recently planning how do maintenance in a future project of mine - a distributed database and application server. Thinking about how typical administration tasks will happen (installing/upgrading applications, adding/removing servers in the cluster, resolving hardware failure etc.), has helped me to sort out some design decisions. Some of them go quite deep into the architecture of the system (for example how applications and extensions are loaded at runtime, and how the servers find other servers in the cluster).