Page Topic
This page describes the design decisions for designing a complete Office automation platform.
Recently, I was given the task of designing and writing the specifications for a large Office automation and
integration project for a medium sized financial firm. There were two of us involved in making the design decisions.
My counter-part was in charge of the SharePoint and Exchange pieces of the project, while I was tasked with designing the
Excel and other Office programs integration into the platform. Once we laid out the system requirements and functional
needs of the users, we came to the point at which we needed to recommend to management the development platform that
we and the company's own developers would use to take our plans to fruition.
Since the client was a financial services firm, the end users were Excel power users. They knew what Excel could do (and
what it couldn't) and had high demands for the functions we were to deliver. The office was a mix of Office 2003 and 2007, so
I needed a platform that could handle both versions with a single code base. We did not want to find ourselves in situation
of developing and maintaining two code bases. Moreover, the Excel side of the application needed several of the more advanced
features, such as COM Add-Ins, TaskPanes, extensions to the basic Excel user interface, real-time data servers, Smart Tags, as
well as XLL libraries.
This was a tall order. We evaluated several development platforms, including simple VBA, Microsoft's Visual Studio Tools For Office (VSTO) and
XL-DNA for the XLL libraries. One of our goals in making the decision regarding the development platform was to provide a single platform
that a developer could learn and then apply that knowledge to many different facets of the project. Once a developer learned how to
use one platform, we want him to be able to apply that knowledge elsewhere in the project.
Narrative goes here.
 |
This page last updated: 28-Oct-2008. |