Architecture versus Design

Being a member of the Technical Solutions Group (TSG) in our company, i was discussing/debating some concepts with other members and wanted to share the email thread so that I can have more feedback which will improve/correct my understanding too-:)

****************************EMAIL THREAD*******************************************************

Hi all,

Due to my extremely tight schedules, I was not able to review the handbook very deeply, but here are my 2 cents from a cursory look of the doc:

1. In section 3.2 Create Architectural Design: Frankly speaking, I don’t like this term “Architectural Design” much, as it can confuse the readers. Though it is mentioned in the doc that Arch is one level up than design, I want to make a clean distinction between the two. We simply cannot have a core class hierarchy in the architecture. Architecture is related to how the system is going to interact with other components and is not at all concerned about the design. We can have many designs for a particular architecture. For e.g.: while going for a front controller or page controller architecture, we don’t need to worry about which classes would be there to implement it. Struts uses FC and we can make ASP.Net. So I suggest that we have Architecture and Design mentioned separately in the handbook to promote clarity.

2. The handbook mentions very primitive 3 layer separation, which in my opinion is not correct to mention like the way it is done. Let me explain my point: We can have a single layer design too, and I have developed many projects using 2 layer design in collaboration with some of the best architects. My point is regarding how layering is decided: this depends on the nature of the project, and the architect should be experienced enough to decide the number of abstractions needed. Considering the complex and ever growing business requirements these days, many times we need 4-8 layers. Sometimes we can only do away with just 2 layers. So the handbook should mention this else people will start thinking that only 3 or greater layers are good. If a software design has just 2 layers, then it’s bad.

3. Less stress on Project management tasks like no mention of SCRUM approach? I really like that methodology and I am strongly in favor of chaos theory based approaches.

These are few points from the top of my head and I am not sure whether the handbook addresses them in the later pages as I haven’t gone through each section in detail.

Let me know your thoughts.

RE: Handbook Review Points

These are definitely good points to be considered. My take on this -

1. In my view, architecture should definitely specify what the components and interfaces are (otherwise it will just become quite difficult to verify that design is following the architecture) and design should specify how those components will be implemented. I thought that core classes are equivalent to components and have noted down this point in my comments. If this is so, I would probably like to include components and interfaces into the architecture. However, we should definitely engage into a discussion to nail down the precise meaning of the term.

For example, architecture should not only say that FrontController would be used, but also the interface that should be implemented by FrontController so that the designer is clear on the scope of the component. The designer would work out the helper classes and the methods required to implement the interface.

2. The three layer architecture is meant as a broad based guideline. Even in more complex architectures, the distinction between these layers remain and these layers are further broken down, for example business logic may be implemented using two layers. Two layered architectures can work, but in my view it is useful to have a business logic layer even if there is little business logic and all it does is to call the data access layer. That leaves some scope to inject processing later, for example, business level validations, before data reaches the data access layer.

Number of layers does depend on the application but three layers is a useful rule of thumb for most web applications.

Warm regards,

(name undisclosed)

RE: RE:Handbook Review Points

Nice points ...! But being a Libran I would definitely like to “argue” on these J…

Regarding #1: let’s start with A&D: I had the opportunity to frame the architecture of a HR product. I started out with typical MVC FC arch., just laying the component interactions and abstractions in a very granular scale. If I define the interface, it may be possible that architecture becomes “design dependent”. I leave such implementation issues to design guys (or design stage later on). Advantages (from personal experience) of such cleaner separation:

(i) System is not “tied” to particular implementations or core classes (or interfaces)

(ii) The designer is able to “think” and design the system to suit a particular programming paradigm

(iii) There is no overall confusion: many vendors still sell SOA as an architectural design product which is completely wrong!

So when we talk of architecture, including design components in it can create some sort of wrong mindset among people which might make it difficult for them to adopt pure architectural paradigms such as SOA. I still have developers asking me about some examples where they can see “SOA implementation” (its hard for them to understand that we can have SOA based design without web services or XML at all!).

I agree with you that we generally tend to blur the boundary b/w Arch and Design. But what I think is that since this handbook is to make sure BR follows industry standards and becomes efficient and professional across projects, and the fact that this handbook would be referred by many people who might not have the experience of the level of the TSG group, this means that we don’t have many experts here who can differentiate between these 2 terms clearly and use them wisely. So I just wanted things to be laid down in a more “stricter” way.

Regarding #2: I here do not agree with you. As an example: I was involved in a not-so-big product for a Rotary international, and we decided to have 2 layers only: GUI and BL+DAL. The business logic wasn’t very complex and creating a separate layer for just BL would have been on overkill and added to reduced performance. People tend to create a “new project/assembly” and treat it as a layer. This is wrong. If we know that a system is never going to be distributed then why add such an overhead? To separate the logic from the data access, one can create simple classes by different names (instead of creating new projects) or also use data access in the same class using some separator (like #region). I have seen some projects which have 3 assemblies for 3 layers and each class contains only 15-20 lines of code which created more confusion as number of classes swelled considering the small scope of the entire project. Also, Rockford Lhotka has used Data access code in its business logic classes in CSLA.NET framework, which is being in use across very big projects!

We need to re-think on the concept of abstraction from scratch instead of just following a 3 layered strategy for every project. We need to think from an average developer’s perspective: he/she should not use 3 layers just to follow the thumb rule, but should use his mind and think out of the box too.

Finally, I may be wrong in my arguments, but that’s what the TSG is for J :to share, discuss and improvise!

Thanks

Vivek

posted on Wednesday, June 21, 2006 10:40 PM

Feedback

# re: Architecture versus Design 10/9/2006 6:02 AM Chris Ongsuco

>> People tend to create a “new project/assembly” and treat it as a layer.

It is a layer. :-)

>> This is wrong. If we know that a system is never going to be distributed then why add such an overhead?

Now you are talking about a "tier". Layers and tiers are 2 different things. A layer is for "logical" separation while a tier is for "physical".

My 2 cents....

# re: Architecture versus Design 10/9/2006 9:55 AM Vivek Thakur

I beg to differ. I know the difference b/w tiers and layers so lets leave tiers and assume that I am talking of layers only. Adding another assembly as a layer will definitely add overhead and I would better use good namespacing and folder structure inside the same assembly to separate components logically. This will involve no cross assembly overhead. Layering is a logical concept and can be done without creating separate assemblies.

Hope things are clear.

Thanks
Vivek

# re: Architecture versus Design 10/9/2006 11:03 AM Chris Ongsuco

Overhead depends on how do things. Certainly if one is loading assemblies manaully through their code then mostly like things will be slower than usual because one might make a mistake in their code however adding a "new project" into your solution as layer is not something that will affect performance. I have implemented the "3-tier" approach that you mentioned and didn't find anything that affects the performance of the application. In fact the project is performing very well until now.

The separation of layers is something the architect will decide. It is true that some projects doesn't need multi layers but for me, I always like to separate my projects into layers even if it is a small project so that I can always make adjustments later on. I like loose coupling however I don't like an overkill design.

And yes good structuring of namespaces is part of designing a good architecture.

# re: Architecture versus Design 10/9/2006 11:11 AM Vivek Thakur

My point is that why to introduce even the slight performance hit while referencing another assembly if the same can be done using a folder inside the same project? This is only for small projects which are not expected to scale up or bloat later on. I have done many such small commercial projects and benefitted immensely from using a 2 tier approach (and avoiding 3 tier complexity, even if that is not very significant).

If we have even the slightest hunch regarding scalabitliy, then I will go with you and use the 3 layer design.

# re: Architecture versus Design 10/9/2006 1:04 PM Chris

Like I said earlier, the project I developed long ago is performing very well until today so I don't any performance issues there.

If what you said is true then we will all be designing our applications as 2-tiers, right? If there is a performance issue about referencing other projects/assemblies then why is it that there are a lot of projects designed using 3 layers and are still scalabale?

# re: Architecture versus Design 10/9/2006 1:12 PM Vivek Thakur

Not two tiers, but two layers (tiers may be needed if we consider physicallly distributed systems). And you are right that many apps are "blindly" being developed as 3 layered systems. This is precisely why I raised this issue to bring out the facts that Architecture and Design is being taken wrongly by many programmers. They just feel that using a 3 layers is good, without considering all the issues involved. I say: use it when needed. Don't follow the "rules" blindly.

Also, just think of it, using an external assembly would "definitely" occur some performance hit compared to calling code within a single assembly. My idea is: why to incur such a hit if we can manage small projects well by logically separating the code (and when we don't need distributed architecture)?

# re: Architecture versus Design 5/12/2007 11:29 AM Deepak

Vivek,
If the Business logic is intended to be used across multiple projects or used for integration, you definetely would want to separate any DAL logic from it.
There is no "Correct" way of doing it (2 layer vs 3 layer) but in my experience it almost always makes sense to use a separate business layer.

Thanks,
Deepak.

Post Feedback

Title:
Name:
Email: (never displayed)
Url:
Comments:
Please add 7 and 2 and type the answer here: Remember Me?

Vivek Thakur

News

Archives

ASP.NET Ventures

3. Less stress on Project management tasks like no mention of SCRUM approach? I really like that methodology and I am strongly in favor of chaos theory based approaches.

Feedback

Post Feedback