Loading ...

Architecture versus Design

0 (0votes)

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!



Comments (1)

Ravi Sharda
Rick Kazman and Amnon Eden's following articles provide a distinction based on Intension and Locality criteria.
- http://www.sei.cmu.edu/news-at-sei/columns/the_architect/2003/1q03/architect-1q03.htm
- http://www.eden-study.org/articles/2003/icse03.pdf

Top Posts