Software Architecture Principles

In my day to day role, I am architecting enterprise business applications using multiple COTS product(s) and creating solutions around them.

Following are the architecture principles I tend to stick to when architecting solutions:

ENTERPRISE PORTAL

KISS (Keep it Simple and Stupid) - First cardinal rule I always follow is to keep the architecture simple. I make sure that I do not use jargons or abbreviations that require Googling every 2nd word. I create multiple views of the architecture for different stakeholders (IT, Business, Implementation Team, Infra Team and so on) to convey the design and architecture Buy vs Build Decision - I generally in favor of buying the functionality instead of trying to re-invent the wheel. I recommend not falling in the trap of "not invented here" syndrome to start creating everything in-house. Requirement Mapping - When using COTS (Commercial Off The Shelf) products in your design, make sure you have mapped your requirements to the product features. Use a COTS product only, if it fulfill 70-80% of the requirements out of box Identify Integration Points - When you are dealing with multiple COTS products, it is very important to identify the integration points for those products. If you even an iota of doubt, do a proof of concept to validate the same. Do not go by the product brochures, or sales talk. There is nothing like knowing what works and what does not early in the game Decision Making - In any architecture design, decisions need to be made. Usually people do not want to stick their neck out. I believe in taking decisions based on the information and data available and moving ahead. I might be wrong but at least we move ahead. If the decision was wrong, we correct it on the way. I do not believe in wasting time in endless meetings that do not lead anywhere. I also make a point to validate my decisions by doing proof of concepts to validate some of the technical design issues Stakeholders - In any solution design, make sure you are aware of your stakeholders. The stakeholders might be direct like Business, Development Team or may be indirect like IT Team, Infra Team, Hosting vendors and Maintenance team. Make sure you share and get feedback from stakeholders on your architecture to avoid any unpleasant surprises later on Prepare for change - We might always want the requirements to be cast in stone, but seldom they are. To tackle the uncertainty, I try to view requirements as what can potentially change vs what will not change. Design for requirements that are not likely to change (e.g. logging, auditing, persistence mechanism, messaging etc). For the requirements that keep changing (e.g. HTML look and feel, content layout etc) be prepared with a design that is fluid and ready to accommodate changes. If you are aware of areas of change and are expecting changes in that area's, it will be easy to accommodate them Communication - Communication of architecture to the entire stakeholder team is very important. The stakeholder's include both internal and external teams. On the client side you will have Business, IT, Infra, Security, Enterprise teams. On the other side, you will have your own PMO, Development team, testing team, deployment Be prepared for surprises - Whatever you do, you still need to be prepared for surprises. Make sure you plan for the same. I have not done a single solution where you do not come across at least one surprise Enjoy - in the end, do not get bogged down. Enjoy the work. People will appreciate the same!

These things work me. Do share what works for you!

Software Architecture Principles

Tech Spot is my den where I jot my thoughts on the Technology landscape. I blog my experiences in the J2EE World and my word on some of the happenings in the Tech world.

Focus Areas - Portal Servers, Application Servers, Web Services, SOA, Web 2.0 and Enterprise 2.0

ENTERPRISE PORTAL