Complexity breeds Complexity

One of my teachers used to say, just like success breeds success, complexity breeds complexity.

Computers were introduced in business to handle increased size (in terms of customer reach, volume of market, globalization, voluminous production, etc) and complexity of business (different legal frameworks in different countries, understanding of business with increasing attributes, etc). But with increase in computing power and numerous business applications we have computer systems which are to support computer application and even department (IT department) and whole IT industry. Think about following applications/disciplines which exist to support computerization of business.

1. IT department
2. Identity Management
3. Master Data Management
4. Data ware house
5. Business Intelligence
6. Decision Support System
7. Collaboration Suites ( Email, messaging, Wiki, Document management system)
8. Integration Practice/Suite
9. ETL Suites
10. BPM Suite
11. Versioning System
12. Ticketing Systems
13. Software Licensing Management
14. Intrusion Detection System
15. Enterprise Search


Do you think that my teacher was correct?

What need to be standardized in Cloud Computing?

1. Federated Identity across cloud and non cloud applications
2. Meta data hierarchy and its exchange mechanism across cloud
3. Data exchange – real time and import/export standards
4. Standards for SLA – machine readable
5. Orchestration and Chorographic standards across cloud to create composite applications
6. Policy and Governance standards
7. Monitoring, billing, auditing, logging, and notification standards
8. Common Data Model across clouds for interfacing cloud resources
9. Privacy standards
10. Global standards (across government bodies and across governments) for data movement and its residency
11. Description of Non Functional requirements (Availability, Scalability, Latency, etc)

Some interesting concepts for Software Architect and Designer

1. Convention over Configuration (aka Coding by convention)
2. Don't Repeat Yourself (DRY, aka Single Point of Truth)
3. Code Reuse
4. The KISS principle (Keep it Simple, Stupid, aka Keep it Short and Simple)
5. 'You Aren't Gonna Need It' (YAGNI)
6. Reinventing the wheel (aka Not built here or Not Invented Here)
7. Worse is better (aka New Jersey style)
8. Occam's razor or Ockham's razor
9. Make everything as simple as possible, but not simpler.
10. MoSCoW Method (M - MUST have this, S - SHOULD have this if at all possible, C - COULD have this if it does not affect anything else, W - WON'T have this time but WOULD like in the future.
11. No Silver Bullet
12. The principle of good enough (POGE)
13. The Pareto principle (aka 80-20 rule, or the law of the vital few or the principle of factor scarcity)
14. Satisficing (a portmanteau of "satisfy" and "suffice")
15. Rule of three
16. The single choice principle
17. Greedy reductionism
18. The principle of least astonishment (or surprise)
19. N - version programming (NVP)( aka multiversion programming)
20. Separation of concern

Design Consideration for SaaS Application

1. Asynchronous Logging
2. Asynchronous Auditing
3. Tenant level Logging
4. Tenant level Auditing
5. Tenant Aware Controller
6. Functionality Aware Controller
7. Hierarchy of Meta Data Objects
8. Tenant Aware Data Objects
9. Clear demarcation of data on the basis of where to store – RDBMS, Hierarchical data base – LDAP, File system, NOSQL, etc.
10. Usage of Virtual Database or similar technique
11. Tenant aware load balancer
12. Tenant aware data store
13. Caching to be used at every level – View, controller and data layer and must be tenant aware and policies must be well defined
14. Fault Barrier pattern for Exception Handling
15. Heart beat like mechanism
16. Do not treat business conditions as business exception

Book Review: Against the Gods-The Remarkable Story of Risk

Book Review: Against the Gods-The Remarkable Story of Risk by Peter L. Bernstein : Publisher- Wiely: ISBN- 13: 978-0471295631

Against the Goods – The Remarkable story of Risk gives historical account of concept of Risk and its development in contemporary economic world. This is primarily addressed to economic and financial professionals but my motive of reading it was to understand Risk in context of Software architecture and project management.

Essentially Game theory and Prospect Theory are very important from Software architecture and its development over the life cycle of any software application. Similarly Game and Prospect theories play important role in Project Management specially in software projects due to volatile employment scenario. Since Software development and management is Human Resource intensive and actors are highly qualified which makes them in demand. This phenomenon must be understood from Game and Prospect Theory.

For any serious software architect and project manager, at least understanding of Game and Prospect Theory is must.

Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.


One can get more information about book and related topics from:

1. Amazon: http://www.amazon.com/Against-Gods-Remarkable-Story-Risk/dp/0471295639
2. Publisher: http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471295639.html
3. Alibris: http://www.alibris.com/search/books/qwork/165523/used/Against%20the%20Gods%3A%20The%20Remarkable%20Story%20of%20Risk
4. Audio Book: http://www.audiobooksonline.com/0671576461.html
5. Flipkart: http://www.flipkart.com/against-gods-peter-l-bernstein-book-0471295639
6. Business Week Review: http://www.businessweek.com/1996/43/b349881.htm
7. Book Review: http://www.ams.org/notices/199901/rev-zabell.pdf
8. One more review: http://www.bainvestor.com/Against-the-gods-story-risk.html
9. Third Review: http://members.cox.net/kdrum/Againstgods.htm
10. New Review: http://www.bos.frb.org/economic//nerr/rr1997/spring/bkrv97_2.htm
11. Review by Insurance Book Review: http://www.insurancebookreview.com/
12. Last Review: http://www.enteleky.com/ag.html
13. Prospect Theory: http://en.wikipedia.org/wiki/Prospect_theory
14. Prospect Theory: http://www.econport.org/econport/request?page=man_ru_advanced_prospect
15. Game Theory: http://en.wikipedia.org/wiki/Game_theory
16. Game Theory: http://levine.sscnet.ucla.edu/general/whatis.htm

Book Review: Software Piracy Exposed

Book Review: Software Piracy Exposed by Paul Craig, Mark Burnett: Publisher- Syngress: ISBN- 13: 978-1932266986

Though book is published 2005 but still relevant in present context. Book goes in details of software piracy in detail. It nicely covers social structure of piracy and discusses its impact and reasoning. Book might have covered anti piracy measures in software in little more in detail. But is must for any software professional.

Book is divided in two parts, regular chapters and then Appendix. Appendix summarizes the book and covers social reasoning and impact of piracy.

Book does not cover the effect of piracy on actual sale of software (For example Microsoft and Oracle), multimedia and games.

Nevertheless book is good read and gives insight into Software piracy.


Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.

Similar Book: Piracy: The Intellectual Property Wars from Gutenberg to Gates by Adrian Johns (http://www.amazon.com/Piracy-Intellectual-Property-Gutenberg-Gates/dp/0226401189)


One can get more information about book and related topics from:

1. Amazon: http://www.amazon.com/Software-Piracy-Exposed-Paul-Craig/dp/1932266984
2. Publisher: http://www.syngress.com/hacking-and-penetration-testing/Software-Piracy-Exposed/
3. Alibris: http://www.alibris.com/booksearch.detail?invid=9846632240&browse=1&qwork=9181080&qsort=&page=1
4. Book Review: http://taosecurity.blogspot.com/2006/08/review-of-combating-spyware-in.html

Book Review: Oracle Fusion Middleware Patterns

Book Review: Oracle Fusion Middleware Patterns by Harish Gaur and, Markus Zirn: Publisher- Packt: ISBN- 13: 978-1847198327

Oracle Fusion Middleware pattern book is a collection of case studies for Oracle Fusion Middleware across the globe and across the industry. This book is primarily targeted to planners and high level business decision makers with hints of technical stuff. With respect to target audience, packtpb site indicates for IT manager but, I differ here.

Book can be read online at http://www.oracle.com/technetwork/articles/entarch/index-098853.html.

Book is divided into three groups: Process Improvement, Business Visibility, and Collaboration and Security to club case studies accordingly.

Book is good read for staff members of enterprises who are moving to Oracle Fusion Middleware stack.


Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.


One can get more information about book and related topics from:

1. Book’s web presence http://www.oracle.com/technetwork/articles/entarch/index-098853.html
2. Amazon: http://www.amazon.com/Oracle-Fusion-Middleware-Patterns-Harish/dp/1847198325
3. Publisher -- Packtpb https://www.packtpub.com/enterprise-solution-architecture-patterns-by-oracle-fusion-middleware/book
4. Harish Gaur’s Blog: http://blogs.oracle.com/harishgaur/2010/10/fusion_middleware_patterns.html
5. Surachart Opun’s Review: http://surachartopun.com/2010/09/oracle-fusion-middleware-patterns-book.html
6. Wow Books Review: http://www.wowebook.com/business/oracle-fusion-middleware-patterns.html

Characteristics of a Good API

• • Easy to learn
• • Easy to use, even without documentation
• • Hard to misuse
• • Expose only what is required
• • Easy to read and maintain code that uses it
• • Sufficiently powerful to satisfy requirements
• • Easy to extend
• • Appropriate to audience

General Principles

• API Should Be As Small As Possible But No Smaller
• Implementation Should Not Impact API
• Minimize Accessibility of Everything
• Names Matter–API is a Little Language
• Documentation Matters
• Document Religiously
• Consider Performance Consequences of API Design Decisions
• Effects of API Design Decisions on Performance are Real and Permanent
• API Must Coexist Peacefully with Platform

Cloud Promises and Truth

1.
Promise: Scalability
Truth: Absolutely (Think of Salesforce, EC2, Azure, AppEngine, etc)
2.
Promise: Peak Load Capacity on the fly
Truth: Think of Wimbledon, famous case study of Washington and EC2
3.
Promise: Zero Capex
Truth: Reduced not Zero (Think of appliance needed, integration required, and one time fee)
4.
Promise: Lower Beta and Testing cost
Truth: Yet to prove it
5.
Promise: Geographic Independence
Truth: Depends upon cloud provider. But remember of compliance challenges
6.
Promise: Device and Operating System and Technology platform independence
Truth: Depends upon genre of Cloud ( SaaS, PaaS or IaaS). Consider licensing issues.
7.
Promise: Multi tenancy enhances the utilization
Truth: Theoretically, Yes but Still to prove
8.
Promise: Centralization reduces cost
Truth: Theoretically, Yes but Still to prove
9.
Promise: Consistent Performance
Truth: Mostly. Consider network latency, bandwidth, 8 fallacies of distributed computing (http://blogs.sun.com/jag/resource/Fallacies.html)
10.
Promise: Enhanced Reliability
Truth: Questionable (jus remember EC2, AppEngine, and Salesforce outage)
11.
Promise: Cloud Computing Removes the Need for an Internal IT Department
Truth: Lie
12.
Promise: Applications Can Be Moved without Change to the Cloud
Truth: Not possible as of today
13.
Promise: It Is Easy to Switch Cloud Computing Vendors
Truth: Not possible as of today
14.
Promise: Moving to Cloud Computing Just Requires a Credit Card—It’s Computing as a Utility
Truth: Lie. Think of integration, training and other stuff

Why does enterprise need Data Services?

1. SOA essentially promotes mushup application, which requires data from various sources in any enterprise application. This paradigm shift in application architecture and design requires reusable services to live with SOA promises.
2. BPM is again collection of mush up application.
3. To promote canonical view of data to increase reusability of services across enterprise.
4. To promote consistent view of data across enterprise.
5. To move towards enterprise wide standards and compliance.
6. To reduce work load on application developers by leveraging data services.
7. To promote enterprise wide vocabulary and consistent semantics.
8. To promote consistent data type irrespective of data source (RDBMS, Hierarchical, NOSQL, etc).
9. To promote consistent quality of data.
10. To promote Master Data Management.

Book Review: Beautiful Visualization

Book Review: Beautiful Visualization Edited by Julie Steele and Noah Iliinsky: Publisher- O’Reilly: ISBN- 13: 978-1449379865


Beautiful Visualization is beautiful book in itself. It has essays from heavy weights from visualization field. The first chapter “On Beauty” is by editor Noah Iliinsky discusses subtleties of Beauty in the context of Visualization in lucid language. Examples quoted by Noah are excellent – Periodic Table and London Underground.

The last chapter “Visualization: Indexed” encompasses bigger picture of Visualization to help think beyond Blind Men’s Elephant. I think this chapter should be second one.

Rest of the chapters in the book covers, various tools and techniques of visualization from various fields – quantative data to medical imaging. Mostly all contributors of this book has one underlying theme – data visualization techniques are not only for visual representation but also for finding out missing (obvious and non obvious) information or at least indicating that information is missing.

From a software professional perspective, whole of the book may not be useful because of its generalist nature but it gives insight into visualization which I feel software professionals’ lack.

Certainly book is worth its price. I highly recommend book to anybody who is interested in software and visualization.

Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.

Further reading: Two complementary books are Information is Beautiful by David McCandless http://www.amazon.com/Information-Beautiful-David-McCandless/dp/0007294662 and The Visual Display of Quantitative Information by Edward R. Tufte http://www.amazon.com/Visual-Display-Quantitative-Information/dp/096139210X

One can get more information about book and related topics from:

1. Amazon: http://www.amazon.com/Beautiful-Visualization-Looking-through-Experts/dp/1449379869
2. Flipkart: http://www.flipkart.com/beautiful-visualization-julie-steele-noah-book-1449379869
3. Publisher – O’Reilly http://oreilly.com/catalog/0636920000617
4. Review at http://informationr.net/ir/reviews/revs378.html
5. Review at iProgrammer: http://www.i-programmer.info/bookreviews/6-graphics/1093-beautiful-visualization.html
6. Review at Dr Dobb’s: http://www.drdobbs.com/blog/archives/2010/07/beautiful_visua.html
7. List of Vizualization tools (2008): http://www.readwriteweb.com/archives/the_best_tools_for_visualization.php
8. Five Best Data Visualization Projects of the Year – 2009: http://flowingdata.com/2009/12/16/5-best-data-visualization-projects-of-the-year-2009/
9. Examples of Data visualization: http://www.webdesignerdepot.com/2009/06/50-great-examples-of-data-visualization/

Architectural Quality and Consistency: Rules Rule

To maintain architectural quality and consistency at macro (architectural) and micro (implementation) level it is necessary to follow certain rules across the life cycle of any software project and product. From easy enforcement, it is recommended to use automated tool set.

There are three types of rules:

1. Enforced: Must be followed in all cases.
2. Advisable: Should be followed and exception must be documented with reasoning.
3. Guidelines: These are the best practices and recommended to be followed in given context. Exceptions must be documented.

To match with SDLC of any software project, rules are also classified as:

1. Architectural and Design Rules: These rules affect larger part of system and define the resulting product. They form the core of the product.
2. Construction Rules: These rules are applied at micro level, programming aspect of product/application
3. Environmental Rules: These rule define construction environment of product/application
4. Test Rules: These rules affect testing (Quality Control as well as Quality Assurance) at all levels – review of artifacts, unit testing, integration testing, functional testing, user acceptance testing, stress (load) testing, etc.
5. Deployment Rules: These rules affect deployment environment of product/application

For quantitative analysis of architectural quality and consistency, matrices must be identified with respect to each rule. To covey weight of each rule in architectural quality, a weightage should be provided to each metric and the preferable a radar chart should be prepared.

To further enhance the matrices, bugs can be classified as

1. Missing functionality
2. Correctness
a. Absolutely
b. Probably
c. Suggestion
3. Rule Violation
a. Enforced
b. Advisable
c. Guideline
4. Confusing or tricky or non-intuitive