Tuesday, January 27, 2009

From requirements to architecture

Learning software architecture never flows smoothly as reading a good novel. Often novices get lost within a jungle of technical jargon such as architectural views, frameworks, styles, patterns, etc. When asked, I have seen many of them struggling just to get started due to this complexity mostly created for marketing purposes. With this post, I thought of sharing some of my experience on how to get started with architecting process when you are asked to do so.

Following is one of the definitions for the word 'architecture' by Grady Booch.
"All architecture is design, but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." - Grady Booch

I'm selecting the above as it is much relevant to our discussion. Correctly stated by Booch, it is the high 'cost-of-change' decisions that should be agreed in the system architecture. But the question is that 'from where and how' do we derive these decisions. Keep in mind that you 'MUST' start with requirements, not with a blueprint or a whitepaper that solves another set of problems (blueprints, etc has enormous value but that is not the correct place to start with!). Look for functional/non-functional requirements to identify areas where explicit architecture/design definitions are required (I will brief you on this process in my next post). Then sort the findings in the order of  'significance'. Interestingly it is preferable to omit lower 'significance' decisions from being pre-specified for few reasons.

 - problem understanding increases over the project life cycle, hence decisions taken later are generally more accurate
 - allowing development team to take some design decisions increases the architecture buy-in and provide good design exposure
 - having lesser concerns in the specification makes it less complex but focused

A good understanding of the product road map (explicitly defined) helps to make the architecture less brittle as time passes. It is important not to reinvent every single design decision by your self. Always look around to see relevant existing patterns and blueprints. Learning from someones experience is much cheaper than learning from your own for most of the cases!

I will share more of my experiences on the matter in a future post. Interesting reader can have a look at one of my previous posts on the subject here.

[tag: 99xt ]

Thursday, January 22, 2009

Personal Firewall Development

I have been looking in to "Personal Firewall" development techniques during last couple of days for my interest. Despite the less documentation on the subject, there are several methods available for implementing personal firewalls. But unfortunately what I found was that, only a very few methods are actually suitable. Most of the articles and samples available are not really meant for serious product development.

First of all I should say that I'm not an expert on  "Windows network architecture". But let me try to explain the subject in simple terms as it is really interesting to study. Following is a diagram summarizes the layers (pale blue) and extension points (dark blue) of the Windows network stack.

One of the primary functions of a firewall is to control the network traffic by packet filtering (block ports, etc). In order to do this, firewall has to intercept the  network stack at some point. Important question is "what is the best place to do this?".

 - Any intercepts at user mode (e.g. Winsock LSP) is useless because malware can easily bypass user mode to operate at kernel mode. Windows 2000 packet filtering API is another user mode alternative but with same limitations (sample implementation).

 - In kernel mode, a popular model is to plug in to TDI layer but this is still too high in the stack. Malware can bypass TCP layer to access NDIS layer if it wishes. Also with this approach, your TCP layer is open to a hacker coming from outside. Despite these facts, several commercial firewall products seems to use this method for their packet filtering.

 - Windows TCP layer provide an extension called 'Firewall hook driver'. But according to MSDN documentation 'firewall hook driver' has some severe limitations. But apparently, Microsoft has gone against their own recommendations to use it for their own Windows Firewall. You can find a sample implementation here.

 - Another extension point of TCP layer is to use 'Filter hook driver'. Filter hook drivers are also not recommended by Microsoft due to the limitation of only a single application can use this extension on a machine. Sample implementation is found here.

With all above considerations, NDIS layer stays as the only sustainable alternative for a commercial grade firewalls. One model is to develop a NDIS intermediate driver which is the recommended method by Microsoft. But due to various compatibility and stability issues, most of the vendors have considered a different approach for their products. Rather developing an intermediate driver, they have overridden some of the NDIS functions to point at your custom functions. This approach is called NDIS hooking but mostly undocumented. Despite less documentation, NDIS hooking seems to remain as the most favored model for developing commercial grade firewalls. As no Microsoft provided API available this method is sensitive to the OS changes. Good discussion thread comparing the two methods can be found here.

What we have discussed up to now is implementation details for just one feature (packet filtering) of a firewall. There are many other features that cannot be done by tapping to NDIS but require upper level tapping as well.

One thing I have noted is that there is very little information available on the net and the available information is hard to find on this subject. I hope you have learnt something by reading this post!

Some Interesting Reads:
Windows Network Architecture
NDIS hooking sample
Article on firewall Development
Firewall-hook driver
Alternative model in Vista
Design of a ideal firewall

[tag: 99xt ]

Saturday, January 17, 2009

What makes a good software architecture?

I remember reading dozens of 'must have' attributes for a good software architecture in several design books. Sometime back I even made a blog post with a list of such attributes. Last Friday I got to rethink when I was in a argument with two of my friendly techies Sanjaya and Samudra. When asked what makes a good architecture, I stated that an architecture is good if it has two simple qualities:
You shouldn't need an architect to understand it: Just because you are an architect, you don't need to use all complex design patterns in the books. Developing a simple workable architecture is always harder than building a complex one. When a developer reads your specification, if he asks "why the hell we needed an architect to design this?", the mission accoumplished! I love these two quotes taken from Kala's blog!
- Simplicity before generality, use before reuse
- If you design it, you should be able to code it

It solves the problem in hand but nothing more: As an architect what is expected from you is to solve the problem in hand but not to build a crystal ball that solves any other problem in the world. For example, if you are asked to build a custom LOB application, you are not expected to build a 'highly extensible framework for LOB products' from you. When expected if the former and you try to build the later, often the result is a system that is too complex. Design only for what is required; if scalability beyond 100k nodes isn't a requirement, don't design for it, unlimited scalability has unlimited cost! (Dont take me wrong, if requirement is for 100k nodes, rollup your sleeves and do it!)

Solving real world problem with software is naturally a complex task; don't make things unnecessarily complex with your architecture!

[tag: 99xt ]