Seven Sins of Software Architecture Siddhartha Chandurkar WIPRO

1. Seven Sins of Software ArchitectureSiddhartha ChandurkarWIPRO

2. Patterns and Anti-Patterns Design Pattern Architecture or design pattern is a general reusable solution to a commonly occurring problem in software design. • Anti Pattern • Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results • A refactored solution that is clearly documented, proven in actual practice and repeatable.

3. Seven Sins Of Architecture

4. Architecture Definition Sin • Description Salvation

5. Architecture Definition Architecture definition does not exist or is not in sync with the code • Many projects don’t have any defined architecture and if it exist it gets out of sync as the project advances • The knowledge about what and how the product has to be implemented gets lost • The Stakeholders are not aware how the end product will look like • In some cases it is defined during the Architecture phase but as the product goes into development it gets out of sync • Learning's of the project are not captured Titanic • Architecture definition should be a must have milestone in any development cycle, very much how a blueprint is required to construct a building or a bridge • It should be reviewed by all the stakeholders • Thought on the structure of layers, modules, interfaces(Internal + External), decomposition, Non functional requirements should be given in advance • At every milestone of development the architecture should be reviewed so that it is in sync with the changes, learning's, deviations etc. • Helps in maintaining the conceptual integrity • Web 2.0 technologies like wikis, blogs, collaboration tools can be used to capture information and discussions

6. Team Structure Architect reports to Project Manager • By nature the Architect and Project Manager are driven by different goals. • The Project Manager is driven my timeline, effort, cost etc. • Where as the Architect is driven by Technology, Quality of the end Product • If the Architect is reporting to the Project Manager. The Architects creativity and quality of the product can get effected since the Project Manager will always push back on deadlines and deliveries. • In the reverse case if the Project Manager reports to Architect then there is a danger that the Architect might purse his technological desires/fantasy and the product will never get delivered. • The Architect and Project Manager should report to Line Managers so that all the drivers (Business, Management and Technical) are pursued. • Since both are at the same level they balance out each other

7. Architecture Evaluation & Reviews Not getting Architecture Evaluated/Reviewed by all Stakeholders • Very often Architectures are made in a hurry and the team straightway jumps into Implementation. • No validation is done with the stakeholders • Very late during the development the team realizes that the Architecture is not aligned with the Vision, Business and Technology drivers • The cost to refactor is enormous since the base of the whole product gets impacted. In worst cases the Product never sees the light of the day. • Once the Architecture is defined an internal or external review should be conducted where all the different stakeholders of the Product participate e.g. Sponsors, Product Managers, Architects, Developers, Testers etc. And if possible the end Users/Customers. • The architecture should be theoretically or through POC’s be validated by running through scenarios developed by various stakeholders e.g. The product should installed in X hours, It should be possible to support multiple devices, It should be testable, Should have minimum Point of Failures etc • Evaluation methods like ATAM (Architecture Tradeoff Analysis Method), SAAM (Software Architecture Analysis Method), ARID, FIDR etc.. Can be used

8. Proof Of Concept Not validating the Architecture through a Proof Of Concept (POC) • Architectures are often fleshed out on paper, without identifying and addressing the various risks and unknowns • As the developers start implementing they realize that the Architecture is fundamentally flawed / technically not feasible, it does not perform, cannot be integrated, has security flaws etc. • Realizing that the Architecture is technically not feasible at a very late stage can be disastrous. • During the process of Architecture definition and even after its made. POC’s should be identified and developed to mitigate risks, issues which are unknown, need to be proven (e.g. Performance, interoperability, security etc.) • Philosophy of Divide and Conquer should be used where each problem should be segregated and attacked as early as possible. • One can develop throw away POC’s or take them as base and build on them.

9. Not-invented here Note-invented here – Everything will be developed in-house • This is one of the most common Sins which is committed in a project. • It is primarily driven by the Architect’s engineering curiosity and will to prove himself. Sometimes its about doing something which he or the team always wanted to do. • Proprietary frameworks are developed, components which are available within or outside the company are again developed, which eventually increase the effort, cost and Time To Market. • Sometimes the teams core skills are different and they are unable to deliver it at all. • Focusing more on technology and less on the Business Features results making products which might be technological marvels but don’t do well in the market. • Focus on the business features first and then see how technology can enable it. • Before implementing anything first find out within or outside whether you can reuse something. • It will reduce your development, testing effort but above all you will get a ready made well tested component which will save huge amount of time.

10. Feature Overloading – Club Sandwich effect Too many features developed in the first release • After the Requirement finalization the increment and iteration definition phase is skipped • Attempt is made to load as many features as possible in one go or in one release • Since no scope or boundaries are defined the release keeps on bloating • Resulting into a product with many features some how squeezed which can severely impact reliability • Customer feedback in not taken hence most of the features might not be aligned with their needs. Vasa • Even before the Architecture is made an increment and iteration plan should be made in consultation with the Product Manager and the Architect • The Architect should subsequently define the architecture so that it is aligned with the increment plan • Its advisable to focus on cross cutting components and one major usecase in the first increment

11. Integrated Teams Architect missing in phases other than the Architecture phase • Some Architects define boxes and consider that the job is done • Its often seen where Architect is involved in more than one project • Team is left to develop, test, deploy a product whose architecture is not been defined by them • No further guidance or mentoring is there on every step of the way • Once the Architecture goes for development they realize that it is not feasible to implement • The code deviates from the original Architecture definition or intention • Its mandatory for the Architect to be part of all the Software development phases i.e. development, integration, System test, staging, production etc. • Integrated teams should be formed where the Architect is the common member e.g. Design Team, Development Team, Performance Team, System Test Team, Integration Team etc.

12. Thank You Email: siddhartha.chandurkar@wipro.com Mobile : +91-9910174725 IM:siddharthachandurkar@skype.comsiddharthachandurkar@gmail.com SNS :http://www.linkedin.com/pub/siddhartha-chandurkar/2/567/454