Is Architecture = Design of the application

Today morning, I’ve attended an interview with one of the prestigious companies of the world. It doesn’t matter what company is that, but all that matters is the significant means of the questions and the replies by me. I can’t post the entire dialogue questions here, but what I can point here is the gist of the interview. The position is for an architect, who would be working extensively for various stages of the project and should also play the managerial role. Isn’t it asking too much for a given role? Well, in Indian companies, there is no real means of Architect. He is just like any other Manager, but doing the technology stuff as well. Anyhow, that’s a different thread of discussion all together, but for the current purpose, let me concentrate on an idle situation, where an Architect is an Architect and manager is manager.

The interviewer concentrating on the design guidelines and seeking answers for standard questions. Sometime back I’ve written about the common mistakes that every interviewer do during the interview. The purpose of this post is not about how the interview progressed and the result of the interview. But understanding the fundamentals of ARCHITECTURE and how it is misinterpreted as DESIGN.

IMHO, an Architect should understand the overall picture of the existing situation as well as the purpose behind developing a new code for the future needs. I remember a quote by Grady Booch about these both..

“ .. architecture is all about design, but not every design is architecture .. ”

On the generic note, we can say that designing the application means architecting the application, but, at the same time, when you measure the cost of change in the shape of the system, certain design principles are proved to be very expensive. Such design decisions are not considered to be the architecture of the application. In most of the application, every one talks about CRUD operations. But I say that it is not just merely the CRUD operations. There are various other operations that influence the decision of design. Those factors define the nature of the application and yield you the definition of the Architecture of the application. Those principles give you the design guidelines.

When you talk about the code usage within any application, most folks say that you would be end up CRUD operations only. But, in my 10 years of experience, I’ve learned that 30% of the application functionality is dwell around R in CRUD and the 10% is around the CU of CRUD operations. A very negligible amount of 5% is D in CURD. Once the data is being read from the Data store, it is either processed or optimized for the purpose of the UI. Thus, 20% of the code is written to process and 10% of the code is towards optimization. Hence, 75% of the code is classified.

What about the rest of 25%? This is that code which is never used, DEAD CODE lying there just for all the unexpected / future expected / maintenance / blah .. blah .. features that e defined at the time of Requirements gathering.

There are various other studies that defines the percentages according to 80-20 rule. Everyone has their own way of seeing things, so is me. I see the code from the point of the usage factor within the scope of most functionality of the application.

Having, mentioned this, one has to keep in mind about all the –-ilities, i.e.., scalability, usability, interoperability .. etc.,

Apart of this kind of classification, all it matters to the investor is ROI. But how do we calculate the ROI with the design guidelines? What is the measurement for ROI in-terms of Architecture definition? What standards dictate the application development? There are many questions that arise at this junction. Let me not deviate from this core theme of the blog post, but these questions help us to quantify the characteristics between them.

So the design (or) architecture of the application is to target the (READ + PROCESS + OPTIMISATION + CU =) 60% of the code or 100% of the code?

While finding the suitable answer for this question, we should not forget that every application would have some sort of reporting need. The reports can be considered as NFR of the application. Some reports are asked, some evolve over the process of development, some may come as the development reach to the fag end of the UAT rollout, but most unfurl at UAT phase. Hence, REPORTs are excluded from my discussion.

Navigation

The first point that comes to my mind while understanding the need of any proposed application is the User Navigation. The UI / UI contract plays vital role in making the application a big success. Even if you develop a great application and the UI sucks, it is not adopted by the end users. Thus, if the UI is user friendly and has lot of issues, it is proved that the users adopt it but they curse the application. Yet, they live with it. Windows operating system is a best example for this. Unix is not user friendly, but a strong operating system. It could not penetrate into the user community as the Windows operating system did. Windows OS has lot of vulnerabilities, leaving the hackers a gateway into the system, but yet, users prefer to use the anti-virus software's to prevent the malicious code get into their systems.

Simplicity

The second point is all about KISS factor, Keeping It Simple and Straight. Some define KISS as Keep It Simple & Stupid. Yes, of course, asynchrony is being the buzz word in the current web trend. But, yet, I prefer to concentrate STRAIGHT @only one task at any given point of time. The investor may ask for everything between hell and heaven, but at any given point of time, the user is either at hell or heaven. If not @hell or @heaven, it is definite that the user is some where between these extreme states. Hence, do multiple tasks depending the runtime infrastructure, but make sure that they appear as simple as we do the normal activities like breathing, thinking, walking, etc., at parallel.

Tasks & Activities

There is a huge debate between the level of micro focusing towards any given need. It is up to the investor to chop the needs into the TASKs and ACTIVITies. If the investor is not willing to take the ownership, someone has to own it. Technically speaking ( ha ha ha .. WRITING ), in most cases, the POC between investor and the application team owns this responsibility. This is the prime factor for deciding the Architecture of the application.

Patterns

It is time to mention about the PATTERNS, they evolve as the application progress. It is a bad practice to develop app based on a set of pattern that is available. Every application is unique by nature. By definition of the patterns, they are recommended as the guidelines for development, but they are not the yardsticks. The team has to identify and tweak the pattern to the best customizable need of the project proposal.

Components

It is said that we are in the world of OBJECTS and every application has to be compelled with the OOPs methodology. But it is not a mandate that we have to think thru OOPs principles. All I feel is that, we have to think about ACID. It doesn’t mean (or) it shouldn’t be misinterpreted that we should not give attention about the OBJECTS. I’m more of a .NET developer, thus, the below two point ponder in my thoughts when ever I think of components

• Cohesion : Components should be highly cohesive. They must be performing a small set of highly related responsibility
• Coupling : Components should be loosely coupled with inbound & outbound interface contracts

External Dependencies

This point is very important if the proposed application has the need of Technology Independence. APIs & SOA are the buzz words at this junction. This debate is a worth of another invention such as GOF principles. Thus, I dare not to write much about this. But this factor also influence the Architecture of the application. Let me write once again, this is also another important phase to ARCHITECTURE the application but NOT THE DESIGN of the application.

DATA is every where

Data is every where, the level of data that we decided to store tells that, how wise or how foolish are we towards the need of the business proposal. At this junction the data experts jump and say that ..

• Data has to be secured
• Data has to be defined decently and should not be vulnerable
• Data should not be volatile
• Data should be trustee accountable for quality
• Shared data is always an Asset

 

CONCLUSION

There are many-a-things that has to be given attention while mentioning the ARCHITECTURE. Simply to conclude that I don’t agree with the statement that DESIGN is not ARCHITECTURE, but ARCHITECTURE involves DESIGN strategy.