When we talk architecture we talk in abstractions. We say we need capabilities such a persistent storage, document editing or a portal. We may say that the characteristics of the persistent store should be relational, but we don’t say SQL Server. For portals we may say we have capabilities such as collaboration, workflow, subscription and audience targeting, but we never say SharePoint.

 

The most common example where ISVs do technology abstraction is in the data and data access layers. Most of the ISVs I meet have implemented some kind of database abstraction layer 10+ years ago that talks with any database in a generic fashion such as through ODBC. Today ISVs build similar layers with .NET using its specialized providers that talk natively with most commercially available databases. Since the providers all implement the same interfaces and .NET now includes the DbProviderFactory class, it’s easy to abstract the database away using a factory pattern. With the Data Access Block in Enterprise Library we even provide a sample implementation such data access layer using factories. The question is if you really want to do this.

 

From an architectural perspective it looks great at first sight. The ISV builds their applications and let the customers choose any database vendor. The ISVs application will run on top of whatever the customer decides to buy. Customer gets a choice and the ISV broadens its potential market. What’s wrong with that?

 

The problem as I see it is that we restrict ourselves to the least common denominator across the vendors when we do these abstractions. If we only treat the database as a place to persist an object oriented domain model, we discard millions of R&D dollars that the vendors have put into new features and abstract them away in order to be independent.

 

If the data store was the only parameter, it may have been ok but if we restrict ourselves for the relational data store, for the document editing/viewing tool, for the portal system, for the forms editing system, for the handheld device and so on we end up with a solution that is too generic and too loosely coupled to win the hearts of the users. I would argue that the user could get a better experience if certain ISV products where tightly coupled a specific platform or a particular vendors products.

 

Looking at the numbers (lines of code, time to market etc) that I hear from the ISVs that have visited me in the development centre the past 18 months, the level of integration and functionality isn’t the only thing that is suffering. The ISVs also spend an awful amount of time and money building generic wrappers and abstraction layers to build something that comes in the box in a specific Microsoft implementation.

 

For a conceptual architecture, I think it’s great to talk in abstractions and capabilities. However, when the architecture evolves from conceptual to logical and physical, we need to make a platform decision.

 

I would claim that for many applications, both the ISV and the users would be better of with a platform dependent version. To offer customers a platform choice and to broaden the potential market, the ISV would benefit from implementing multiple platform specific applications. The typical objection is that it will be too expensive to develop and maintain, but looking at the numbers that I have heard past 18 month, I really doubt it. Developing two solutions sounds worse than developing one. But what if you can only use what is common between platforms and on top of that need to write and maintain many thousands of lines of code to build generic wrappers and abstractions to iron out the differences instead of just using what came free in the box.

 

I would argue that, in many cases, developing and maintaining two solutions is both faster and cheaper than developing one and, as a bonus, it would provide a better experience for the user.