Predictions for the next decade (2011 – 20)

1. Android (and its derivatives) will be omnipresent in embedded, mobile and hand held devices.
2. In laptops/desktops, windows or some flavor of it will be preferred operating system.
3. SAAS and PAAS will prevail for small and big enterprise.
4. IAAS will thrive in enterprise data centers.
5. Fragmentation and Alternatives of Java and Enterprise Java (like Apache harmony, and Spring) will emerge stronger and official java from Oracle will loose its sheen due to lust for its monetization by Oracle.
6. Laptop, mobile and tablet will merge into one.
7. Indian IT workforce will shift from permanent job to contractual jobs like in USA.
8. 3G and 4G (BWA) will bring internet book in India over smart phone and tablets.
9. Developing countries will swept by telecom revelation like India in previous decade.
10. Gamification will engulf almost all experiences especially of social media.
11. Outsoucing will change from India focused to 2I + 1 (2 location in India and one elsewhere)
12. Apple will loose its grip on smart mobile phone market.
13. Application will be pervasive in devices and appliances like phones (mobile and fixed line), TVs, automobiles, refrigerators, disk (CD/DVD/BlueRay) players, and any computing device.

What questions (non financial) should I ask to a Cloud provide?

1. Number of years in service?
2. Number of subscribers?
3. Number of users?
4. Min number of users per subscriber?
5. Max number of users per subscriber?
6. Average number of users per subscriber?
7. Geographic spread of subscribers?
8. Mode by which Cloud can be accessed ( Browser, hand held device – mobile phone – which one, etc)
9. Does app has offline client?
10. Browser compatibility
11. List of business processes affected
12. Severity of affect to each business process (just touch, requires change, need complete change)
13. How to integrate with existing business systems – batch/real, synchronous/asynchronous, technology/platform?
14. Do employees need training?
15. Does Cloud affect master data?
16. How to integrate with Single Sign On (SSO)?
17. Does proposed cloud will capture any sensitive information (trade secret, patent, customer data, etc)?
18. What are the bandwidth requirements of proposed Cloud?
19. Does proposed Cloud have SSL support?
20. Does Cloud provider share with you external penetration tests and internal network security audits periodically?
21. Does provider have a documented policy for "hardening" the OS under Web and other servers?
22. Does provider have a documented set of controls to separate data and security information among customer applications?
23. Does provider perform background checks on personnel with administrative access to servers and applications?
24. Does provider has documented process for security alerts from IT partners?
25. What are the procedures for business continuity and disaster recovery?
26. Does provider certify the security of scripts and integration code; documented procedures for installing security patches
27. Does provider offer application- or transaction-based intrusion- detection services?
28. Does provider has documented identity management and help desk procedures?
29. What percentage of security staff has security industry certification?
30. What is the average experience of provider's security staff in information and network security?
31. What is the provider’s operational model: a. Self Hosting b. Co-location c. Managed Hosting d. Cloud Computing?
32. Is the provider's data center N + 1 for power?
33. Provider's Data facility: 1. Tier III 2. Tier IV
34. Is the provider's data center certified SAS 70 Type II or Type 1?
35. How many data centers does the provider have?
36. Which data centers will be used to server the application?
37. Is there a DR plan if a data center becomes unavailable?
38. Does the provider use at least 3 ISPs? Who are they?
39. Can a private connection to my enterprise WAN be provided?
40. Does the provider have network redundancy? How is this achieved?
41. How is network latency mitigated?
42. Can the provider provide location specific SLA's measured by a third party benchmarking service?
43. What are the hardware and software components provided by the provider?
44. Are provider servers dedicated or shared? If shared, by what method?
45. Is infrastructure redundant? If so, how is this accomplished?
46. What is Backup and retention schedule?
47. What monitoring is done as well as the interval, and reports that are available to review?
48. Is there staff 24/7? If not, what hours is staff available?
49. What is the provider's change management, patch management and upgrade policies and procedures?
50. What are the downtime notification policies (i.e. is advance notification given? How much?)?
51. Will a staging server/staging sand box be available for testing prior to production deployment?
52. Does provider has sand box for development?
53. How is security alerts handled? What are the security policies?
54. Do you have clear Service Level Agreements (SLAs) established with the service provider?
55. What kind of System Monitoring provided by the service provider?
56. What kind of help-desk support is available?
57. What are the change management processes available from the service provider?
58. Does the service provider provide you a staging environment to test changes before they are promoted to production?
59. Will the service provider support for full data and rule customization recovery on contract termination?
60. What API’s are exposed by service provider to develop application over cloud?
61. What API’s are exposed by service provider to deploy application over cloud?
62. Does my enterprise need new licensees of app servers/database or any other applications to be deployed over cloud?
63. How much time is needed to set up a proof of concept or trial demo?
64. How can offering being customized?
65. Industry references
66. Historical records of service availability?

Maintenance and Support Technical Handbook- Template

Maintenance and Support Technical Handbook- Template

Legal Challenges in cloud computing: Software Architect Perspective

Though Cloud gaining currency across the globe and across the industry. But if one carefully observe, he will find slow adoption of cloud in big enterprises. From a Software Architect perspective one should be aware of the legal challenges while evaluating cloud platforms for a solution.

1. Intellectual Property Rights
a. Is application and data protected under intellectual property rights?
b. If cloud provider gives access to your application, data, log etc to third party then what legal responsibility cloud provider assumes?
2. Trade Secrets
a. How secure are the trade secrets?
b. How far cloud provider can go to protect data, log, etc. in case of court summons and/or quasi legal requests/pressure?
c. How long cloud provider keeps application data and logs even after application is deleted from cloud and/or log deleted from cloud?
3. Privacy
a. What responsibility cloud provider assumes to protect Application Owner’s privacy?
b. What responsibility cloud provider assumes to protect Application users’ privacy?
c. Is there any liability coverage for privacy breach?
d. How behavioral tracking is maintained?
4. Data Centre
a. What legal responsibility does cloud provider assume in case of disaster?
b. What legal responsibility does cloud provider assume in case of hacking?
5. Jurisdiction
a. In case of any legal dispute which law apples – location of application provider, location of end user, location of cloud provider, location of server farm or any other?
b. In case of data breach who will send the notice of data breach – application provider or cloud provider?
c. How trans-border laws will be handled?
d. How do reputational risks covered?
e. How long data will be retained for legal and taxation purpose?
f. What is damage policy (say total dames are capped by amount of fee)?
g. Does the flow of data meet the regulatory requirements of each jurisdiction it flows through?
h. Does the cloud provider provides solutions for de-identifying data for transboarder data flow?
i. Where will the data and processes be stored? Can a commitment be obtained?
j. Are there multiple cloud platforms/parties involved?
k. Can the movement of data be controlled?
l. Should/can the data be encrypted?
6. Service Level Agreement
a. What are the SLA’s for cloud provider?
b. What matrices will be used to measure performance of cloud provider?
c. In case of dishonoring of SLA, what are the penalties and they will be enforced?
7. Licensing
a. Do libraries, components, services, servers, etc used in application creation, deployment, etc have cloud compatible licenses?
b. Do libraries, components, services, servers, etc used in application creation, deployment, etc licenses cover upgrade and maintenance as well?
c. How application’s license is structured for end users?
8. Physical Location of Data and processes
a. What is the location of data?
b. What is the location of processes?
c. Is any point of time, location of data and process be ascertained?
9. E-discovery
a. What are the evidentiary issues when client data is in cloud?
b. What are the SLA’s of e-discovery?
c. Who is responsible for e-discovery?
10. Termination
a. In case of contract termination, how data will be moved from cloud to in agreed upon format?
b. Who is responsible to move data?
c. If cloud provider goes out of business then how termination will be handled?
d. If application provider goes out of business then how termination will be handled – data, intellectual property.
e. Is there any lock in?
11. Change in Terms and conditions
a. How change in terms and conditions to be handled?
b. Does cloud provider change terms and condition by inserting URL?
12. Audit
a. Can application provider do audit of facilities and processes/procedures and how extensive are these audits?
b. Can application provider do audit of logs and how extensive are these audits?
13. Miscellaneous
a. What insurance cover cloud provider has?
b. In case of emergencies how data be accesses and who will be responsible?
c. Use of application provider’s name and logo for publicity by cloud provider?
d. Use of cloud provider’s name and logo for publicity by application provider?
e. How service renewal will be handled?

Cloud Computing Taxonomy

A Small Step for Service Governance

While talking about SOA Governance, one visualizes big fat software and tools which costs millions of dollars and a platoon of support staff to “govern” SOA Governance platform.
In my experience, I noticed that small baby steps always more helpful and governance should be embedded in architecture and design. Instead of SOA Governance, I like it to be service governance first.
Recently, talking to one of my counterpart at my client place, I encountered a classic case of mis governance in services space. Once service is created and deployed, its contract ( wsdl in case of web service) is freely available across enterprise which makes unknowns its customer (sic) without any controlling authority. This uncontrolled distribution and usage of contract leads to nightmares and fights when service performance decreases or new version of service need to be releases and older version to be retired.

How to avoid such dogfight!

Simply create a registry (not UDDI) of service and make sure that this registry contains the information that who is calling whom and authentication has to pass through this registry. I understand this suggestion violets purist form of SOA but in this world nothing is perfect.

Convention over Configuration

Now a days every software using or claiming to use convention over configuration.

Is anybody paying any attention on negatives of this paradigm?

1. To utilize a piece of software which is based on Convention over Configuration paradigm, one requires deep familiarity of software.
2. Refactoring becoming difficult and specifically if at any point of time, need arise to change convention, developers have night mares.
3. Bloated code is very normal because of binding the logic with convention. This pain can be reduced if conventions are made configurable.
4. This paradigm makes software very restrictive in view of “ only one way” of doing the things.

Few of the well known examples of softwares using Convention over Configuration paradigm are:
1. Java Bean
2. XDocLet
3. EJB
4. Spring
5. Hibernate
6. Grails
7. Ruby on Rails
8. Apache Camel
9. Struts
10. Maven
11. Apache Wicket

Reference:
1. http://softwareengineering.vazexqi.com/files/pattern.html
2. http://msdn.microsoft.com/en-us/magazine/dd419655.aspx
3. http://elegantcode.com/2009/11/28/convention-over-configuration/
4. http://en.wikipedia.org/wiki/Convention_over_configuration
5. http://marekblotny.blogspot.com/2009/04/convention-over-configuration.html
6. http://codebetter.com/jeremymiller/2009/01/24/convention-over-configuration-in-msdn-magazine/
7. http://www.javalobby.org/java/forums/t65305.html
8. http://www.sonatype.com/books/mvnref-book/reference/installation-sect-conventionConfiguration.html
9. http://weblogs.asp.net/sfeldman/archive/2009/07/20/convention-over-configuration.aspx

Light Weight

It has become now fashionable to call any software component, application, library, platform, product, and any other piece of code as light weight. Now every piece of software claim itself as light weight. Just like “Life Time Warranty”.
In reality what does light weight means??

In my point of view term “light weight” is comparative. A piece of software is light weight or not in comparison to its contemporary competitors.
I have listed few of the criteria to tag some piece of software as light weight:

1. Deployment memory foot prints.
2. Runtime memory foot prints.
3. Run time consumption of other resources other than memory.
4. Dependency on other libraries.
5. Need of containers (!)

Operations in a Service Interface v 2.0

I have listed the operations a service should exposes in my earlier post. I have revised the list. The latest is:

BPMS Types

While doing assessment for one of my client for BPMS platform/tool set, I divided the BPMS system on the basis of three main features.
1. Human Centric
2. Integration Centric
3. Document Centric

Certainly some of the BPMS platforms/toolsets belong to more than one category but majority of them focuses one aspect or another. This focus is at large determined by vendors’ historical association with that aspect of product.

P2P in Business

With the rise of Cloud (SaaS, PaaS and IaaS) centralization of business application is taking place which certainly offers its own benefits but also introduces single point of failure and too much control by very few entities. Centralization also asks for non interrupted connectivity which may not be feasible in lot of scenarios.

At the same time increasing interdependency of workers and businesses requires networked individuals and resources. In few of such scenarios networks get created on adhoc basis for short duration of project.
To solve these opposing requirements, P2P networks can be of great help. P2P does not require very centralized systems and divide the data ownership and infrastructure needs among participants.
Keeping this paradigm, I looked into various products and platforms and surprised to find that lot of small and big enterprises are using P2P technology and platforms in their business applications. One Further investigation revealed that the biggest share is cornered by BitTorrent.

1. Aggregator Juice (http://juicereceiver.sourceforge.net/index.php) uses BitTorrent
2. Video Player Miro (http://www.getmiro.com) uses BitTorrent
3. Music Retailer DGM Live (http://www.dgmlive.com) distributes using BitTorrent
4. Music Retailer Sub Pop (http://www.subpop.com) uses BitTorrent for distribution
5. Canadian Broadcasting Corporation (http://www.cbc.ca), Norwegian Broadcasting Corporation (http://www.nrk.no) and VPRO (http://www.vpro.nl) have often distributed their content using BitTorrent.
6. The Amazon Simple Storage Service (S3) is equipped with built-in BitTorrent support.
7. Blizzard Entertainment (http://us.blizzard.com/en-us/) uses BitTorrent (using a proprietary client "Blizzard Downloader") to distribute most content for StarCraft II and World of Warcraft, including the games.
8. Entropia Universe (http://www.entropiauniverse.com/) distributes files through BitTorrent
9. Facebook (http://facebook.com) and Twitter (http://twitter.com) use BitTorrent to distribute updates to servers.
10. CRM Ajatus (http://www.ajatus.info) is built on top of CouchDb
11. Bug Traking system SimpleDefects(http://syncwith.us/) is built using Distributed database Prophet
12. Avvenu (http://www.avvenu.com/) is a Personal File Sharing, Mobile Sharing platform. It is acquird by Nokia.
13. Dekoh (http://dekoh.com) facilitates Personal File Sharing with Web Integration platform
14. ShareDirect (http://www.laplink.com/business_solutions/sharedirect.html) is data synchronization tool by LapLink
15. Pando (http://www.pando.com) by Pando is Publishing, Media Streaming, and file sharing solution
16. StreamerP2P (http://www.streamerp2p.com) is a Broadcasting solution over internet
17. Syncura (http://www.syncura.com) has few products for document sharing and collaboration
18. Digital Media Delivery framework by Velocix (http://www.velocix.com) uses P2P paradigm
19. The Digital Media Exchange (DMX - http://cyber.law.harvard.edu/media/projects/dmx) operated by Harvard Law School
20. Social VPN (http://socialvpn.wordpress.com) is a P2P based VPN platform

Some of the Peer to Peer Initiatives:

1. JXTA (https://jxta.dev.java.net) is P2P Networking initiative by Java
2. P2P-Next (http://www.p2p-next.org) is open source initiative which primarily focuses on digital media.
3. Secure P2P Framework (SePP - http://sourceforge.net/projects/securep2p) focuses on security aspects of P2P. It is developed in java.
4. GNUnet (https://gnunet.org) is one more P2P Framework which focuses on security.
5. AntHill (http://www.cs.unibo.it/projects/anthill) is based on Complex Adaptive System paradigm.
6. MsgConnect (http://www.eldos.com/msgconnect) is proprietary P2P framework offered by Eldos.
7. Brunet (http://boykin.acis.ufl.edu/wiki/index.php/Brunet) is P2P library written in C#

Some of the P2P frameworks for developing business applications:


• Apache CouchDb (http://couchdb.apache.org) is a RESTful object database
• DBE (http://swallow.sourceforge.net) is a Java based P2P container for service oriented architecture
• Prophet (http://syncwith.us) is a P2P-replicated database
• Friend to Friend (F2F - http://ulno.net/f2f) is a Java framework for building P2P business applications using the SIP protocol
• Telepathy Tubes (http://telepathy.freedesktop.org/wiki/Tubes) is a framework to channel application information over instant messaging networks
• BitTottent (http://www.bittorrent.com) is one of the most popular P2P framework to develop enterprise grade applications.

Software Architecture Template

Software Architecture Document Template v 1.0 Dated Oct 17 2010

Lean - Software Development

Lean has gained tremendous currency in manufacturing industry. Even in service industry Lean has significant influence. But in software development Lean is still in infancy due to two dominant reasons:

1. High level of manual intervention: Can you imagine coding done by robots at present state of technological sophistication. I understand up to a large extent code is automatically generated but still crucial part is requires human ingenuity.

2. Software engineering is still not a science or engineering but art or at the best craft. There is tremendous debate is going around in industry but still craftsman and artist are winning.

Software development is like Research and Development work where new materials and processes are being invented to fulfill newer needs in better way. Nevertheless, pioneers like to convert art and craft into science and engineering and bring automation into main stream to achieve consistency in quality and reducing the cost of development.
Therefore keeping the spirit of engineering, Lean can be applied in software development. The basic principles of Lean in software development can be transformed.

1. Add Nothing But Value (Eliminate Waste): Think of Agile methodologies in software development. Scrum and User stories are few of the efforts in this direction.

2. Center On The Resources Who Add Value: Since Software Development is labour intensive, value humans and then non human resources like software, hardware and processes.

3. Flow Value From Demand (Decide as late as possible): Work only for those features which are essential for customer now not in future. Think of Just in Time paradigm.

4. Optimize Across Organization: Do ever hear of SOA?

5. Optimize Across Organizations: I hope, you know about Cloud Computing?

6. See the whole: Do not make code as Spaghetti. Follow the principle of Code depth first and the breadth in moderation.

In line with seven wastes of manufacturing, software development also has its own wastes:

1. Overproduction  Extra Features: User stories, Scrums

2. Inventory  Huge amount of investment in work in progress. Think of water fall model. Details of Stories for current iteration

3. Over Processing  Paralysis by Analysis. Follow Test Driven Development, Daily build, write enough code to just pass unit tests. Extra Steps: Co-location, better communication

4. Motion  Finding Information: Figuring out what to do, where to go, and how to do.

5. Defects  Defects Not Caught by Tests: Test driven development. Catch defects in early of SDLC.

6. Waiting  Requirement gatherers are waiting for customers, designers are waiting for requirements, Coders waiting for design, testers waiting for code, and finally customer is waiting for product. Release often and early

7. Transportation Handoffs: Close interaction among developers, designers, testers and certainly with customer. Source code branch merging, email maze.


Reference:
1. http://en.wikipedia.org/wiki/Lean_software_development
2. http://www.leansoftwareinstitute.com/art_ilsd.php
3. Applying Lean to Software Development, an Excerpt from The Art of Software Development by Sara Peyton
4. http://leansoftwareengineering.com/
5. http://poppendieck.blogspot.com/2003/04/lean-software-development.html
6. http://en.wikipedia.org/wiki/Muda_%28Japanese_term%29
7. http://www.leaninnovations.ca/seven_types.html

Myths of Agile

1. Agile is just Scrum or Extreme Programming
Truth: Agile is not a single methodology. It is a collection of Best Practices.

2. Agile methods are not suitable for large projects
Truth: Agile is not a fixed notion but is a collection of best practices. Use whatever suites in the given conditions. Use judicious use of Depth First and Breadth then.

3. Agile means no documentation
Truth: Working software is more valued than documentation but documentation is required for green horns, partners, customers and lots of others. Teams separated by time, space and discipline require documentation to pass understanding.

4. Agile means no upfront design
Truth: Any software system requires infrastructure. So always think of depth with breadth. Agile values ability to change over plan.

5. Agile is undisciplined
Agile requires disciple of high standard. Each member is responsible of her acts and deliverables.

6. Agile Development is not planned one.
Agile believes in rolling wave planning not in static plan.

7. Agile is not suitable for product development
Agile is for software development not for the product conceptualization. Keep proper check and balances on depth vs breadth of code.

8. Agile is not suitable for fixed bid projects
Lot of service companies are using it for fixed bid project. Agile requires transparency from service provider and customer.

References:
1. http://blog.versionone.com/blog/the-agile-development-blog/0/0/five-myths-of-agile-development-myth-5-agile-development-is-just-another-fad
2. http://www.authorstream.com/Presentation/vickydhiman-67414-common-myths-agile-myth-main-science-technology-ppt-powerpoint/
3. http://www.theappgap.com/exploring-ten-myths-about-agile-development.html
4. http://www.wiziq.com/tutorial/7418-Common-Myths-about-Agile
5. http://www.versionone.com/pdf/AgileMyths_BetterSoftware.pdf
6. http://agileworld.blogspot.com/2008/04/agile-myths.html
7. http://www.projectez.com/Files/special%20report%20-%20myths%20of%20Agile.pdf
8. http://stackoverflow.com/questions/1871110/agile-myths-and-misconceptions
9. http://www.drdobbs.com/architecture-and-design/206501655;jsessionid=BQPXX0LZG1ASLQE1GHPCKH4ATMY32JVN

Book Review: I. M. Wright's Hard Code

Book Review: I. M. Wright's Hard Code by Eric Brechner: Publisher- Microsoft Press: ISBN- 13: 978-0735624351


I.M Wright’s Hard Code is authored by Eric Brechner, veteran a Microsoft. Though book is published in 2007 but still holds its value in software project management. Book is filled with nuggets of wisdom for any person who is involved in Software project management or influence corporate IT culture.

Author is very straight forward and blunt in delivery of his opinion and belief which makes him distinct in crowd.

Book is collection of short essays which are organized in ten chapters. Book covers almost all aspects of software developments and primarily targets project managers and higher ups in management chain.

Certainly this book will stay in my bookshelf. I highly recommend this book.

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: Complementary books to I.M Wright’s Hard Code are Getting Results from Software Development Teams by Dr. Lawrence J. Peters (http://www.amazon.com/Getting-Results-Software-Development-Teams/dp/0735623465), Solid Code by Donis Marshall & John Brono (http://www.amazon.com/Solid-Code-Donis-Marshall/dp/0735625921), Code Complete: A Practical Handbook of Software Construction by Steve McConnell (http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670)

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

1. Amazon: http://www.amazon.com/Wrights-Hard-Code-Best-Practices/dp/0735624356
2. Author’s Blog: http://blogs.msdn.com/b/eric_brechner/
3. Review: http://mvark.blogspot.com/2008/11/book-review-i-m-wrights-hard-code.html

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

Software Testing and Time machine

Software Testing and Time Machine

API Documentation Mistakes and How to Avoid Them

Treat API documentation as User Interface for developers who will develop and extend your application/product beyond your imagination. Good API documentation is first step of making your API popular.

Mistake #1: Developer doubles up as documentation writer
The Mistake and Misconception
Developer, the creator knows about the system the best, so she can write the best documentation. More over API documentation is targeted to developers’; they understand each other’s lingo and mindset.
The Truth
Certainly developer the creator knows the best but most of the time her sight is myopic due to limited understanding of whole system. Moreover developers are not got in natural language due to their engineering background (no offence to engineers and developers. I am a proud engineer and developer). And lastly, developers are too near to system. What is obvious to them may not be so simple and straight forward to a greenhorn or outsider.
The Solution
Get a good technical writer.

Mistake #2.: A typical technical writer writes the documentation
The Mistake and Misconception
A typical technical writer is good at writing about user interface which targets non technical users. API documentation writer should be skilled to explain from developers’ perspective.
The Truth
Sometimes you will find technical writers who have dabbled in programming. This is a big improvement to working with those who haven't, because they will at least have an understanding of the concepts of programming. But what they won't have is an understanding of how a commercial software developer thinks. How do developers get started learning something new? How do they use prototyping and architectural design? How do they debug their code?
The Solution
Get a technical writer who can code (certainly not on regular basis) or at least have done coding in past.

Mistake #3: Focusing on How and forgetting Why
The Mistake and Misconception
Most of the documentation put emphasis on How to use an API but ignore Why.
The Truth
Sometime this avoidance is purposefully but most of time this is due to lack of attention. Just remember that if documentation does not answer Why, they may end up using API in wrong way and API may become unpopular among developer community.
The Solution
With How, answer Why as well and explain under what scenario what to use, How, and Why.

Mistake #4: Not providing enough help for Getting Started
The Mistake, Misconception, and Truth
In most of API documentation, certain level of maturity of developer is assumed but never stated. This lead to lot of confusion and un-popularity of API..
The Solution
Provide multiple levels of documentation. One targeted to newbie and one at advanced developers. Also state the assumptions very clearly.
Provide simple tutorials and sample codes. Strive for sample applications which use the best practices of API.

Mistake #5: Sketchy sample code
The Mistake, Misconception and Truth
For a technical writer it is very tempting to be descriptive about API.
The Solution
Certainly descriptive text is important and helpful but just remembers that developers like to learn by doing not only by reading. Pair up Technical Writer and developer if needed to develop sample code and sample applications.
Sample code should consider:
1. Relevant information should be grouped together
2. Clarity is more important than efficiency
3. Simplicity is one of the most important factor
4. Completeness of code
5. Avoid unnecessary details ( for example use hardcoded values instead of parametrization)
6. Comment the code
7. Use sensible nomenclature

Software Product Life Cycle

There is vast amount of literature on Software Development Life Cycle (SDLC) but hardly any on Software Product Life Cycle. Event with invent of Product Life Cycle (PLC) systems, focus is on non Software product.
From my experience, I have tried to depict Software Product Life Cycle in following picture:

This picture tries to depict only one product. This does not cater to product family concept directly. Using two life cycle approach, one can support product family as well with depicted Software Product Lifecycle.

Contemporary non function requirements of a Software Product

Version 2 of this article is posted at: http://architecture-soa-bpm-eai.blogspot.com/2011/06/contemporary-non-function-requirements.html

In any software product one has functional and non-functional requirements. It is always easier (is it so?) to identify and define functional requirements. But not so easy to define non functional. With increasing experience of software development communities, traditional non functional requirements like availability, usability, robustness (http://en.wikipedia.org/wiki/Non-functional_requirement) becoming commodity. But with changing business and technological landscape, new set of non functional requirements are emerging.
1. Open API ( synchronous and/or asynchronous)
a. Remote Object
b. Service (for example)
i. SOAP based Web Service
ii. REST Based Web Service
iii. JSON based web service
2. Multiple Channel Access (for example)
a. Connected Desktop (web browser)
b. Disconnected Desktop
c. Mobile application
d. RSS/Atom
e. WAP
f. Mobile browser
3. 3rd party/partners can build on your platform/product
4. Product as vehicle for 3rd party content
5. User as editor of relevant content
6. Content is made available to user when it is ready (push mechanism or at least reactive alert)
7. User add ancillary data ( like rating, reviews, ranking, link submission, recommendations, etc)
8. Settings/configurations can be exported and imported
9. Allow product to run as slave as well as master while integrating with other applications
10. User as owner of identity
a. Published Privacy policy with some control to end users
b. Authentication and authorization using industry wide acceptable standards ( like OpenID, facebook Id, google ID, Yahoo ID, etc)
11. Variable licensing options (for example)
a. Transaction based
b. Revenue sharing
c. User based
d. Fixed onetime cost
e. Time based
f. Cloud compliant
g. Processor based
h. Virtualization compliant
12. Social Networking features
13. Serving high band width as well as low band width environment
14. Information and data search capability
15. Domain Specific language
16. Framework for customization
17. Support distributive SDLC with multiple out sourcing partners
18. Hardware independence
19. Place for online advertisement ( like google ad)
20. Open to migrate to cloud or to non cloud deployment
21. User Analytics
22. Dash board
a. Users
b. Administrators
c. Maintenance and support staff
23. Hooks to monitoring tools
24. Early release and flexible design & architecture to modify
25. Concepts of Roles and Permissions (Identity Management)
26. Multiple Browser compatibility

Reference

1. http://en.wikipedia.org/wiki/Non-functional_requirement
2. http://en.wikipedia.org/wiki/List_of_system_quality_attributes
3. http://broadcast.oreilly.com/2010/02/nonfunctional-requirements-how.html
4. http://en.wikipedia.org/wiki/Requirements_analysis
5. http://en.wikipedia.org/wiki/ISO/IEC_9126
6. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=22749

Pattern Product Code Management - Customer Specific Folders

Pattern Product Code Management - Customer Specific Folders v 1.0 Dated Oct 5 2010

Book Review: The New World of Wireless How to Compete in the 4G Revolution by Scott Snyder

Book Review: The New World of Wireless How to Compete in the 4G Revolution by Scott Snyder: Publisher- Wharton School Publishing: ISBN- 13: 978-0-13-700379-2

The New World of Wireless depicts two possible scenarios on effect of 4G technology on society and business. Book then focuses on business strategy to be adopted by enterprise to take advantage of scenarios emerging.

Certainly book projects new thought for business but it does not try to pick any cue from historical events and scenarios which has emerged in other industries.

Though book does not discuss this but both scenarios have parallel scenarios in today's world. Take example of computer operating systems (Microsoft Windows - dominant in consumer arena, UNIX - AIX, HP UX, Solaris, BSD etc - dominant in server market and linux and with its numerous variant trying to dominant consumer and server market simultaneously). Nature Align scenario is too good to be true due to current geo political conditions, IP related issues and desire of corporations to dominant the market (for example in social networking Google has tried to enforce its standard for communication - which miserably failed). On the same lines, Killer Bee scenario on the other extreme. I visualize scenario in wireless communication will be very similar to computer operating system, where no one standard dominates but each has strong presence in their respective fields and trying to encroach in others strong areas.

Scenario one, Virtual network provider (VNP) consolidates network capability from various network providers. Consumers get the network access via VNP. For example in Indian context, Virgin Mobile is acting not only over Tata Telecom netork but also over Reliance, Bharti, Vodaphone and others. Consumer logs into Virgin network (!) which in turn gets access to all underlying networks. This type of model is must for Nature Align scenario. Book is missing on such details.

Nevertheless, book provides fresh insight on 4G technologies on society and businesses. Book also introduces two important and interested concepts, Digital Swarm and Wireless IQ (WIQ).

I certainly recommend this book from strategic thinking perspective.


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/New-World-Wireless-Revolution-ebook/dp/B002HMJY6U
2. Publisher - Wharton School Publishing http://www.whartonsp.com/store/product.aspx?isbn=013700379X
3. Podcast of Author http://www.enterpriseleadership.org/blogs/podcasts/2009/11/13/dr-scott-snyder-author-talks-about-4g-wireless-disruptive-technology-and-what-cios-need-to-do-now
4. Safari: http://my.safaribooksonline.com/9780137026845
5. Interview with author: http://www.smartplanet.com/people/blog/pure-genius/how-4g-accelerates-the-wireless-revolution-and-how-to-compete/826/
6. Author’s Employer: http://www.thinkdsi.com/index.asp
7. Review: http://strategicframing.com/2009/07/31/digital-swarms-anyone-the-new-world-of-wireless
8. Funny 4G: http://www.squidoo.com/What_Makes_4G_The_Inevitable_Future
9. Interesting site on Mobile and Wireless: http://mobilebeyond.net/

Pattern Product Code Management - Customization by Customer

Pattern Product Code Management - Customization by Customer v 1.0 Dated Oct 4 2010

Pattern Product Code Management - Customization Using DSL

Pattern Product Code Management - Customization Using DSL v 1.0 Dated Oct 5 2010

Pattern Product Code Management - Distinct Code Base

Pattern Product Code Management - Distinct Code Baser v 1.0 Dated Oct 5 2010

Product Code Management - Use Customer Specific Marker

Pattern Product Code Management - Use Customer Specific Marker v 1.0 Dated Oct 5 2010

Architecture Pattern: Reference Object

Pattern Reference Object v 1.0 Dated Sep 07 2010

Architecture Pattern : Business Entity Extensibility

Pattern Business Entity Extensibility v 1.0 Dated Aug 09 2010

Architecture Pattern: Distributive Object

Pattern Distributive Object v 1.0 Dated Aug 09 2010

Software Architecture and Design – How to Change!

With time everything changes, so the architecture and design of any software. To avoid Architectural Erosion, one has to manage Architectural changes with great care. To do required changes following are the few techniques:

1. Adaptation: In this technique, single implementation is maintained but it offers interfaces to adopt demanded behavior. To accomplish this configuration parameters (design or compile/build or deployment or run time) are adjusted. Even reimplementation or patch to source code is used. Adapter and Inversion of Control pattern is most used example of this technique. Inheritance is also one of the popular way to achieve adaptation.


2. Replacement: In this technique, various implementations are available. As per the need specific implementation is used.

3. Extension: In this technique, component provides facility to add additional components as and when required (design or compile/build or deployment or run time). This is also called plug-in approach.
To understand Architectural Erosion one can use Inter Service Dependency Model.

Reference:

1. http://architecture-soa-bpm-eai.blogspot.com/2009/01/inter-service-dependency-model.html
2. http://www.methodsandtools.com/archive/archive.php?id=85
3. http://www.lattix.com/g_architecture
4. http://blog.softwarearchitecture.com/2009/04/10-principles-of-change-management.html

Book Review: Event Processing in Action

Book Review: Event Processing in Action by Opher Etzion and Peter Niblett: Publisher- Manning: ISBN - 9781935182214

As the name suggests, book covers basics of event processing independent of language and underlying technology framework. Before starting this book, my impression about event architecture was colored by TIBCO’s technology stack. But after reading event has larger mind share from my side.

Book is divided into three parts covering almost all parts of event based architecture or in authors’ terms event processing. Opher manages a blog (http://epthinking.blogspot.com) which is very good source of information. He is also active member of Event Processing Technical Society (http://www.ep-ts.com) which is one of the most active site for Event Processing technology.

Book strives to develop a notation based language for Event based systems modeling but it requires more efforts and time to reach wide acceptance like UML or BPMN. Nevertheless, book is excellent in its content and approach.

I surely recommend this book to anyone who is involved in any form of event based architecture.



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: Competing books are Event Processing: Designing IT Systems for Agile Companies by K. Mani Chandy and W. Roy Schulte http://www.amazon.com/Event-Processing-Designing-Systems-Companies/dp/0071633502 and Event-Driven Architecture: How SOA Enables the Real-Time Enterprise by Hugh Taylor, Angela Yochem, Les Phillips & Frank Martinez http://www.amazon.com/Event-Driven-Architecture-Enables-Real-Time-Enterprise/dp/0321322118

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

1. Book’s web presence http://www.ep-ts.com/EventProcessingInAction
2. Amazon: http://www.amazon.com/Event-Processing-Action-Opher-Etzion/dp/1935182218
3. Flipkart: http://www.flipkart.com/event-processing-action-opher-etzion-book-1935182218
4. Hans Review: http://hansgilde.wordpress.com/2009/12/02/first-thoughts-on-event-processing-in-action
5. Author’s (Opher) Blog: http://epthinking.blogspot.com
6. Opher at Twitter: https://twitter.com/opheretzion
7. Publisher – Manning: http://www.manning.com/etzion
8. Event Processing Technical Society: http://www.ep-ts.com

Book Review: Digital Identity by Phil Windley: Publisher- O’Reilly

Book Review:  Digital Identity by Phil Windley: Publisher- O’Reilly: ISBN: 0-596-00878-3

Phil was CTO for Utah state of USA and implemented Identity Management Systems there. During the course of book he reveals his learning which should be useful any big decentralized enterprise.

Book consists of twenty chapters spanning from introduction of Identity Management to various concepts of Identity Management is sufficient depth. The best part of book is that it does not lean to any vendor specific solution and provides conceptual level understanding of Identity Management.

Book is nearly 5 year old, so does not provides information about latest developments in Identity Management like OpenID, CardSpace etc but concepts outlined still hold good.

I recommend this book to get high level understanding of Identity Management.

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:

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

1. Author’s website: http://www.windley.com
2. Book’s web presence http://apidesign.org
3. Amazon: http://www.amazon.com/Digital-Identity-Phillip-Windley/dp/B002AWX8B4
4. Publisher – O’Reilly http://oreilly.com/catalog/9780596008789
5. Wikipedia on Identity Management: http://en.wikipedia.org/wiki/Identity_management
6. Book at FlipKart: http://www.flipkart.com/digital-identity-phil-windley-book-0596008783

7.      Identity Management white paper by  Skip Slone & The Open Group Identity Management Work Area

8. Novell Identity Manager: http://www.novell.com/products/identitymanager/
9. Windows Identity Foundation: http://msdn.microsoft.com/en-us/security/aa570351.aspx
10. Oracle Identity Management: http://www.oracle.com/technetwork/middleware/id-mgmt/overview/index.html