I'm moving on...

mbaladi.net — Fri, 30 Mar 2007 12:43:00 GMT

After a six and a half year career at Microsoft, first as a principal consultant in Microsoft Consulting Services and later as Architect and Technical Lead in the EMEA Microsoft Innovation Centre (MIC) in Denmark, it is time fo me to move on.

Lately I have been working almost exclusively with innovation and software as a service (SaaS, and now it's time for me to stand on my own legs and practice what I hav been preaching. As of April 1st I will be doing free-lance consulting (mainly SaaS related) and also go back to my roots by starting a SaaS ISV with a couple of friends.

From April 1st, my blog will live at http://blog.baladisoftware.net and my web site will be living at http://www.baladisoftware.net

I'll talk about the remaining two sceanrios in the SHP from there...

Independent. Sure, but at any price?

mbaladi.net — Tue, 14 Feb 2006 18:48:00 GMT

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.

New architecture community on MSDN for ISVs

mbaladi.net — Sun, 08 Jan 2006 19:06:00 GMT

Today we have launched a new architecture community primarily for solution architects working for Independent Solution Vendors (ISVs).

The goal of this community is to create a forum where architects from Independent Solution Vendors (ISV’s) can discuss solutions architecture and how to implement these using the Microsoft platform. Since no application is an island, topics can also include Identity and Access management, how to integrate and interoperate with other platforms and systems as well as other topics architects care about such as security, related tools and processes.

I’ll be monitoring and facilitating discussions in that forum together with subject matter experts from the MTC team. You can find the new forum at http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=231&SiteID=1.

Michel Baladi on software : ISV

I'm moving on...

Independent. Sure, but at any price?

New architecture community on MSDN for ISVs