An inflection point decision
In any major product development effort there are 3 to 6 key decisions that I term as inflection points. The path one chooses at these junctures ultimately influences the “soul of the product”. The entire small business application suite of products has been developed from scratch so there were no boundaries or constraints predetermining any inflection point decision. The only guiding principle was to innovate using software so the small business eco system would benefit from the final solution. As I look back at the last five years, I can pin-point these inflection points for each component of the suite (BCM, SBA, POS, Payroll and our suite of online services). Today I will share some of the background behind one of these crucial decisions that we had to make at the very beginning of the project. This decision was around the selection of the best technical architecture and framework to build Office Small Business Accounting i.e what tools and technologies should this new product be based on.
Selecting a technology foundation is not a simple matter of picking a programming language and kicking off development. While ease of programming and ability to create the best features for the customers is of primary importance, equally critical is the ability and flexibility the architecture will provide for scalability (growing with the needs of the user), maintainability, reliability, security, deployment and maintenance. Furthermore a key need in the accounting space is to enable ISVs to build extensions to the application so they can add industry specific functionality (from construction to farming). We began the selection process by first hiring some of the most talented engineers in the industry most of whom had built multiple software applications in the past, then we undertook one of the most extensive customer research studies to deeply understanding the needs of the customers, the CPAs & the ISV community and finally and probably the most crucial step was to identify all the choice available to build the application.
In late 2002 we created multiple teams to evaluate each technology choice by building a sample prototype on each option. Every member of each prototype team was someone who believed deeply in that choice. So the effort was more like a technical bakeoff or the computer science equivalent of the popular TV series survivor. We put together a set of selection criterion and started voting off the options that failed to meet the sum total of all our priorities. Each prototype effort actually helped us flesh out the information architecture that finally was the basis of SBA as these were not academic exercises but rather small representative steps of what we were trying to accomplish with SBA. After nearly six months of very deep technical due diligence the choice was very clear. The best and most efficient platform for developing a complex application that would span a desktop exe and several web services was our very own .NET framework.
The .NET framework is a development and execution environment that allows different programming languages and libraries to work together seamlessly to create Windows based applications. The .NET framework consists of the common language runtime and framework class libraries, a consistent object oriented library of prepackaged functionality. SBA has been architected to run on top of the .NET framework and consists of a clean three layer application comprising
- A presentation or the User Interface (UI) layer built using winforms
- A business logic layer primarily built using C#
- A storage layer using a rich relational data base (MS SQL 2000 desktop edition); Data access is via ADO.NET
Using .NET was a phenomenal decision as it enabled us to rapidly develop and deploy a very complex application like SBA and yet abstract all the deep accounting logic with the simplest and cleanest interfaces in the industry. In addition, we could expose the application to both CPAs and ISVs for the deeper processes and integration each of these communities needed.
There is a great article on MSDN that articulates the benefits of .NET for ISVs. In many ways, SBA was an ISV building on .NET and on behalf of the entire R&D team, I can attest to the benefits we received during the development effort (and continue to receive as we work on the next version) :
1) Speed of development as a result of quick ramp up of new developers on modern well factored tool set based on object oriented programming
2) Language independent
3) A solid and robust security layer,
4) Focus on SBA business logic (.NET takes care of system interfaces for managing buffer overrun, memory mgt etc)
Another article on MSDN has a very nice background on what is .NET framework that is a very good starting point for new developers on the framework. Our small business effort is a testament to the true value that a company can gain by betting on the right underpinnings and foundational technology and architecture. Starting from scratch and releasing the most innovative products in eons old categories in just 2-3 years was primarily possible because of this important decision.
As a result of the clean architecture and .NET underpinnings, SBA is exposed at every layer of its architecture and the resulting software developers kit (SDK) gives ISVs a complete set of tools and supporting material to build solutions on top of the application. An ISV can develop several types of solutions with SBA:
1) Build a standalone app that works alongside SBA and calls in to relevant business logic. BCM is actually an internal example of this type of integration
2) SBA Application add-ins – ability to add menu items and tool bar buttons and connect to ISV managed add-in business logic; Also hook to events for pre and post save/delete (eg : notification to a sales person via IM when an invoice changes); Customizing field labels via XML template
3) Build addl solutions in other office apps like access and excel using SBA data (eg reports, pivot tables etc)
The SBA SDK primarily consists of :
1) .Net framework (CLR, framework class libraries and object oriented library of prepackaged functionality)
2) SBA API which consists of four dynamic link libraries created in C# and can be included in the ISV dev environment
§ SBAAPI.dll – Guts of the business logic – Exposing the core business logic of SBA
§ SBAUI.dll – Enables ISV applications to call SBA forms and UI logic
§ SBAIAPI.dll – Public Interface for the SBAAPI.dll
§ SBAIUI.dll – Public interface for the SBAUI.dll
3) Property field customization template
4) Property fields customization uploader
5) MSDE
6) Code Samples
7) SDK help files
All the benefits of .NET accrue to the users of the SBA SDK. In addition there are some important advantages over other development platforms in the domain :
1) Applications linking or integrating to SBA get in-process access to SBA (SBA logic can accessed within the process of the ISV app i.e the SBA executable doesn’t have to be separately fired up)
2) Full functionality of SBA is exposed to developers (all core business logic within SBA is exposed via its public API)
3) Integrated platform security at a database level
4) Access to data via a high performant relational database
5) Multiple levels of customization
In April 2005, we announced the availability of the SDK and within a few weeks the SBA SDK became one of the most downloaded of all MSDN technologies. In upcoming posts I will profile and write about the great applications that our ISVs have built on top of SBA using its powerful SDK. A current list of all shipping ISV applications available for SBA is available at office.microsoft.com.
