[OBA Solution Framework Index]

Office Business Applications (or OBAs) represent a good way to provide solutions for cross-functional business processes. Office Client applications allow users to interact with systems from using familiar interfaces. Office servers bring together structured and unstructured processes, data and documents. However it is important to understand that the platform capabilities required to support a business process, are more than just what you get with the Office System. The good news though, is that the Office system is a good way to surface capabilities from other platform technologies e.g. SQL Server (data, integration / reporting / analysis services), BizTalk Server (business process management / monitoring), Active Directory (identity management).

Before going into details on how to do this, let us look at what the anatomy of a business solution looks like. This will be done from the perspective of a software solution provider - packaging an OBA solution for subsequent deployment and implementation at a customer location. This high level overview will set the stage for more detailed drilldown in subsequent blog posts.

Any business solution will need to include some (or all) of the following elements. All of these elements can be supported through an OBA.

1. Roles: Most solution providers won't know up-front who the users in the system are going to be. However they can (and should) partition artifacts of the solution by role. Later when the OBA is deployed, and actual users are assigned to roles, then these users should automatically have solution artifacts for their roles become available to them. Another benefit is that knowledge networks within the enterprise become explicit (e.g. who knows what, how to search for persons by skillset).
   Implications for OBA: Consider role specific SharePoint dashboards and personalization sites. Later when people are assigned roles, then links to their dashboards / personalization sites should automatically appear on their 'My Site's i.e. auto-discovery of tasks, documents, reports, ... etc that are part of their job.
2. Information Channels: Different roles can receive information through various channels e.g. through a web portal (i.e. ASP.Net, SharePoint), through an Office client document, through a mobile device, through a smart client application, through IM (i.e. Office Communicator). The business solution not only needs to support these multiple modes of information distribution, but also extends the reach of these front end systems into data stores in the back office.
   Implications for OBA: Consider the information architecture holistically e.g. design SharePoint site hierarchies and document libraries to match business processes, roles and organization structure. Key artifacts (e.g. documents, dashboards etc.) related to particular business processes can be arranged in the context of this information architecture. Office client applications can be extended through process specific add-ins that plug into these information structures. Consider using VSTO SE to build these add-ins.
3. Process: There is a spectrum of business process from collaborative (e.g. people-to-people interactions) to transactional (e.g. structured people-to-system, and system-to-system interactions). Any business solution needs to be able to represent business process that enables the right level of visibility and monitoring.
   Implications for OBA: For document routing within a team or organization, consider using Workflow technologies within SharePoint. These might be simple sequential workflows that extract information out of documents that get added to document library, or might be complex state machine worflows that coordinate tasks / document routing across subordinate workflows. For managing the lifecycle of business processes / business entities (esp. when coordinating across multiple groups or organizations), consider using BizTalk to handle business processes external to SharePoint.
4. Rules: Often business processes are fairly static. Once modeled, they are not updated very frequently. More often the dynamic elements of a business process are the business rules that make up the process. Consider externalizing rules from workflows / orchestrations, so that their lifecycle can be managed separately from the lifecycle of the processes that they support.
   Implications for OBA: For workflows that are embedded in SharePoint, consider management of these through a separate rules service - with a deployment mechanism into SharePoint.
5. Events: Most people tend to suffer from information overload as part of their job. A typical response to this is to handle business process through a process of Manage-By-Exception. Therefore a business solution might choose to support management of the lifecycle of events / exceptions that are part of the business process. The lifecycle of an event typically is Detection - Notification - Resolution.
   Implications for OBA: Consider modeling events within SharePoint through a Task libraries that 'own' a particular business event, and reports / dashboards to provide visibility. Consider managing the lifecycle of these events through State Machine workflows running within SharePoint. Alternatively, the lifecycle of these events could be managed by the BPM server (e.g. BizTalk) external to SharePoint, and SharePoint would just act as the visibility layer (for reporting / task management).
6. Data: In some sense, data is the fuel that drives any business solution. For solution providers, there needs to be a well defined data interface, that clearly marks out the data entities which are consumed in the business process - and which need to be mapped to back end data stores at deployment time.
   Implications for OBA: Consider modeling business entities, and the actions that can be taken on them, using the BDC (Business Data Catalog, a shared service within MOSS). Solution providers can map these to WSS lists, and then these could be mapped to other back end data stores at deployment time.
7. Performance Management: In order to support a complete business cycle, a business solution needs to enable roles to plan activities, carry them out, measure the impact, and make appropriate course corrections. These are covered through the following four steps - Monitor, Analyze, Plan, Execute. Implications for OBA: Personalization sites that support particular roles in a business process, should provide artifacts that support each of these four steps e.g. reports / dashbords for monitoring, links to activities for execution, and links to spreadsheets for analysis and planning. These artifacts should plug into the data / information / eventing channels described above. Also consider using Performance Point that plugs into SharePoint, and that provides capabilities for three out of the fours steps listed here (monitor, analyze and plan).