Developers are experiencing a breakthrough now that the common services described in previous sections are being offered in a single platform. With fewer platforms and tools to learn and with a common deployment model, developing OBAs in conjunction with .NET applications and Web services provides for faster development at a lower cost.
Previously, in Figure 1-2, the four major areas show how information is presented and consumed by end users, how information is processed, how collaboration occurs, and how information is stored. Information is made available through a MOSS 2007 portal that has sites composed of pages, and pages composed of Web parts. A Web part is the most basic building block of the portal. Solution providers can develop Web parts and incorporate Web parts that are provided out of the box, one of which provides Excel spreadsheets and charts and another the capability to view lists and tables.
Web parts are aggregated within pages. Users can assemble this aggregation from the collection of Web parts made available to them, or dashboard templates can be created from these pages. For example, developers can create standard dashboards for business functions involved in sales, inventory, or any other business area or provide business intelligence views for specific managers or disciplines within the organization.
The architecture of an OBA involves leveraging multiple parts of the Office platform. For example, developers can create and package template sites along functional lines. An entire site can be deployed as part of an OBA solution. Users can also work with My Sites, personal sites in which they can create pages from scratch using the Web parts made available to them, or simply pull in links to standard dashboards that are appropriate for their role. Further, these sites can be integrated with a custom Office client.
Within this architecture, information is processed and can be worked on by the users of a site through a number of services within the 2007 Office system. For example, documents live in document libraries, and forms live in form libraries. Document libraries for spreadsheets can be registered with Excel Services, and the worksheets they contain can then be distributed through MOSS-based views of charts and tables. You can also present business data in lists and tables in Office MOSS 2007 through the BDC.
Figure 1-9 provides a high-level architectural overview of the Microsoft Office platform. This figure illustrates the various technologies, tools, and layers that make up an OBA.
Workflows can be created using Visual Studio Tools for Office 3.0 or Microsoft Office SharePoint Designer. Then you can associate these workflows with document and form libraries. You can indicate to SharePoint Server 2007 which workflows to invoke against a document when it is modified or created. These workflows might be related to a business process (document approval, for example) or to document life-cycle management (for example, record expiration dates).
Finally, you can access the information that lives in back-end systems through the BDC or by workflows. This information can be presented through a Web service interface or through direct ADO.NET data connection. The BDC makes information available in lists and tables within MOSS and allows an association of actions to be taken on that data. A drop-down menu on the table, invoking specified URLs and passing in context, then makes these actions available. These URLs can correspond to a Web service or link to an Office document that is prepopulated by the context that is passed in from the BDC.
OBAs have certain attributes that are enabled by the platform capabilities and the supporting technologies. When building an OBA, the following attributes make your solution more robust and allow you to focus on solving the particular business problem being addressed by your application.
IWs today often need to request LOB system experts to export useful business data from an LOB system into tools such as Excel. The data, in this case, is presented in a disconnected fashion. OBAs bridge this gap by presenting business data in the user interface that information workers are familiar with. IWs can now analyze the data using tools they already know how to use, thereby facilitating more informed decision making and actions.
OBAs take people-centric processes and map them to system-centric processes to enable workers to perform a particular task from beginning to end without having to shift context, pull data from various data sources manually, or perform analyses in disparate applications. A common identity and security system are also built with OBAs.
Team collaboration is often required to accomplish a business task and typically occurs outside the context of enterprise systems. The OBA platform allows developers to capture many aspects of a business process within a Microsoft Office application so processes and data are centrally located and key information is not lost. The ability to share and connect with others is built into the platform and supports both formal and informal processes (such as workflows), allowing for more complex applications.
OBAs are serviceable by their end users, adaptive, and highly customizable by both IT developers and end users. The collaboration and business rules are not hard-coded into the presentation tier, so end users have substantial control over customizing applications to meet their own needs. Power users can arrange their portals in the manner they choose and set business rules for certain tasks using familiar tools. As business needs undergo change, IT developers can rebuild and redeploy the business-tier components, thus maintaining their business applications relatively easily and with less code.
OBAs focus on business interactions, analytics, and actions. Users are thus allowed to make informed decisions and act within the context of the business problems at hand by having real-time business data at all times. OBAs do not reinvent the wheel for functions such as data access, data interactions, workflows, analysis, and reporting. However, they leverage these capabilities from the underlying platform. Thus business applications can build on the foundational capabilities of the Office system to provide business capabilities of their own while at the same time doing so in an environment that is comfortable and familiar to the IW.