By Tim Landgrave
Applying the principle of the least (PTL) in your architectural plans requires that you ask yourself a simple question whenever you approach any element of the design. That question always starts with "What’s the least amount of ...." Although this principle can be applied throughout the design process, let’s look at three common areas that you should consider using it for.
Least amount of code
It’s a documented fact that the more lines of original code required to create a system, the more that system costs to create and to maintain. Moreover, as the lines of code in a system increase, so do the potential holes through which security can be breached. There are two keys to successfully minimizing the lines of code in a system while still getting all of the functionality the system requires.
First, always look for existing features in the underlying operating system or virtual machine before coding a feature yourself. For example, developers writing systems that run on Windows 2000 without the .NET Framework have to create their own mechanisms for managing threads and thread pools. This lack of a clear methodology often leads to several incompatible and expensive (from a support perspective) implementations of threading models within a development organization.
But with threading support built into the .NET Framework, developers can minimize the lines of new code they have to write by taking advantage of the System.Threading namespace. Any architect or developer using the .NET Framework as a development platform owes it to his or her company to become an expert on the capabilities of the Base Class Library (BCL) before designing or implementing a new system.
Second, design your own code for reusability. I encourage development organizations to build the PTL into their developers’ mindset by thinking about designing everything for reuse. This requires a new way of thinking for most developers because they don’t think anyone can write better code than they can. But given proper guidance—and the chance to critique and test the code they’re asked to reuse—you can build a PTL attitude when it comes to code development.
One of the best places to start is to build some base ASP.NET page classes that all your developers share. These classes can implement common functionality like link-tracking, identity context and skinning or theme support, and can greatly minimize the amount of new code required to generate a new ASP.NET application.
Least amount of data necessary
System architects can sometimes be lazy. Rather than do the work to decide which particular data elements a particular class requires to do its work, they just pass in the equivalent of a SQL “select *” and throw away what they don’t use. When large numbers of users are added to the system, these inefficiencies become evident because performance suffers. And security breaches become more acute when the amount of data compromised is increased unnecessarily.
Applying PTL to your data architecture means that you’ll make two commitments. First, you’ll limit the amount of data passing between objects to the bare minimum required to complete the required operation. And second, you’ll limit the amount of data returned to users to the amount they should have access to at any given point in time and to only that data that they can actually use from a given view.
Least amount of security required
The other key PTL violation that I commonly see in development shops involves system security. To make their developers more productive, many organizations allow the developers to write code in an administrator environment rather than in a user environment. This is a bad practice for development shops because it leads to sloppiness in testing, deployment, and operations. At a minimum, developers should be required to test their code with a user’s security context before they can check any code into a source code repository or send it to the testing organization.
As an architect, you should apply the PTL to your security practices by determining the security requirements for any users or groups that will have access to your application. Work with the operations team to create Active Directory groups that have only the specific privileges required for your application to execute. And architects should create any common user IDs and password required for package security with the same eye toward applying the PTL.
Applying PTL across your application design can have dramatic financial consequences for your organization. An application with fewer lines of code will take less time to develop and debug and will be less expensive to maintain. Applications that use data more efficiently will scale better, requiring less equipment and software to support the same number of users. More secure applications means less exposure to viruses and hackers, thereby lowering the overall support cost for deployed applications. Making the PTL a core part of your .NET application architecture will help you reap these benefits for your company.