OSF 1: Introduction to the OBA Solutions Framework

[OBA Solution Framework Index]

The set of blog postings tagged OSF will provide architectural guidance on how to build / package / deploy / deliver business applications on the Microsoft Platform, using Microsoft Office (Client / Server) and other platform technologies. These solutions are called OBAs (Office Business Applications) as they heavily leverage the new technologies in SharePoint v 3.0 (MOSS / WSS) and the Office Client. However OBAs also pull through capabilities of a number of other platform technologies e.g. SQL Server (and IS, RS, AS), BizTalk, Performance Point, and the core .Net 3.0 Framework.

The OSF is not a product, nor even an official MS code name, but instead a unified set of architectural guidance (plus ref. architecture and ref. code) for building OBAs. I work on solution architecture in the Microsoft Architecture Strategy Team. This team (AST) works with customers, partners and the larger architect community to help come up with innovative ways to put our different technologies together. Over the past year and a half I've been looking at the architecture of business applications in the enterprise, and focussing on OBAs. As I've talked to different architects who are trying to build their own OBAs, I've found that I usually get a common set of questions. So over the next month or two, I'm going to put out a set of blog postings on this topic - each around a different question - and I'm infomally calling this the OBA Solution Framework.

I'm going to focus on three broad areas in my set of postings:

  1. What are the kinds of solutions that I can build as OBAs? What are the application patterns?
  2. What are the infrastructure / operational implications of OBAs?
  3. What would Management / Governance of OBA solutions look like? For example, SDLC (Software Dev LifeCycle)? ALM (Application LifeCycle Management)?

Needless to say, feedback / discussion / comments on any of the postings in the OSF are very welcome :-). Also my views are that of a solution architect, and not the official views of the various Office development teams.