Welcome to my inaugural blog post. My name is Tim Brookins, and I'm an Architect in the Developer Division here at Microsoft.

For those without context, the “Unfrozen Caveman” was a running Saturday Night Live skit about a decade ago. I work at Microsoft, so I haven't watched TV in the last decade to know if the skit ever runs anymore or not!

My area of expertise is building platforms for business applications. Some people simplistically think: “Here's a database (SQL Server), and a language (C#)... now go build your business application”. But in reality it’s a lot more complicated than that, at least if the application is significant.

All the major players in the business application space have traditionally built their own proprietary platforms to support their applications. For example, SAP has ABAP and PeopleSoft has PeopleTools.

Even smaller companies have made large investments in business application platforms. I was formerly a principal architect at Great Plains Software, and I led the team which developed our own client\server based business application platform called “Dexterity”. Along the way, we acquired or merged with several other mid-market accounting companies: Solomon Software in the US, and Navision Software in Copenhagen, Denmark. Guess what... They all had proprietary platforms as well!

These proprietary platforms are <expensive>. Both Dexterity (the Great Plains business application platform), and MorphX (the Navision Axapta application platform) are complete, vertically integrated environments. They have their own form layout packages, their own database APIs, their own scripting languages, and even their own debuggers. Think home brewed Access, Powerbuilder, or FoxPro... it’s not cheap to build something like this from scratch!

So why do companies do this? Do they really enjoy investing boatloads of resources into building infrastructure rather than building the business application itself? Of course, the answer is “No”. Nobody wants to spend money unwisely.

Some might argue that these companies built their own platforms to provide “API stability”. I'll be the first to admit the Microsoft hasn't done a very good job over the years of providing long lasting, stable APIs. ERP applications are huge. They have thousands of forms in the UI, thousands of tables in the database, and millions of lines of business logic. They take years or even decades to build. Completely abstracting an application via your own platform can really ensure that some unforeseen API change doesn't force you to throw away your business logic and start from scratch.

But I argue that the “API abstraction” was an important, yet secondary motivation for building these platforms. In many cases, the cost of building the platform was probably more than the cost of re-writing the application because of technology changes.

So what was the motivation? Well, we didn't know it at the time, but these proprietary business platforms were early attempts at what we would now call “Domain Specific Models”, with an accompanying custom Framework.  You can see these elements by simply looking at the hard drive of a Great Plains install. An installed Great Plains system has a main application exe (the framework) which is about 3 meg. Then next to it on the hard drive is a giant data file which contains the entire application, as data (domain model).

Now of course both the Navision and Great Plains platforms were early, baby steps toward a full featured domain model with framework.  I don’t want to over blow their capabilities.  However, even in their early form, they provided enough value to merit the significant investment to build the platform.  We'll learn more about the compelling value of domain modeling over the life of this blog.

So enough of the history lesson… what about the future?  We believe that there are several gigantic paradigm shifts occurring which will revolutionize business applications in the next decade.  I don’t have the space in this post to discuss them all, but I will touch quickly on two of the most important:  robust domain modeling in mainstream tools, and service oriented architectures (SOA).

We’ve established that pretty much every significant business application developer has historically invested in building their own platform.  These platforms were typically simplistic domain specific models with an accompanying framework, based on client\server technology. 

The emergence of SOA pretty much obsoletes these client\server toolsets.  Of course business developers can prolong the lifecycle of their proprietary tools.  They can keep building monolithic client\server applications and bind them together at the edges with some XML and a few web service calls.  But sooner or later the life support will give out and customers will see the duct tape and bailing wire holding these applications together.

Don’t get me wrong… SOA doesn’t exist today.  The current “state of the art” is exactly duct tape and bailing wire.  But SOA <will> exist in the future, and when it does it will drive a tidal wave of change through the “I built my own client\server toolset” crowd.

This blog will talk about this gigantic impending shift.  I work on an effort within the Developer Division to build a toolset and accompanying service oriented framework which supports robust business domain modeling integrated into Visual Studio.  The codename of this effort is the Microsoft Business Framework (MBF).