However, hardly anyone's heart should be crying for Microsoft. As the old adage says, "still water runs deep" , and Microsoft has at least used the Duet and Snap experience to bide time to come up with an even more encompassing solution. Before that, the giant had to conduct some serious soul-searching, such as whether to conclude "Project Green", which sought synergy across its ERP product lines.. Considering this hindsight, it is no longer that important to know whether Microsoft merely toyed with the product convergence idea or if it was the wishful thinking of the news-hungry press and eager analysts (some of which are now gloating about the idea's abandonment). Most likely, the temptation was there (who, after all, wouldn't be tempted to deal with only one product line, as opposed to four?), but a deeper analysis of acquired products has likely caused Microsoft to conclude that each product line has some distinctive technical and functional aspects. This, in conjunction with the partner ecosystem, would make doing anything injudiciously and precipitously (such as imposing unfamiliar tools and technologies) result in the alienation of the existing customers and partners.
But, Microsoft certainly did not panic, and has meanwhile rather spent time on figuring out how it can parlay its desktop supremacy (with an estimated 400 million Office users worldwide) into attracting enterprise applications users, and possibly changing some enterprise applications paradigms. Microsoft operating systems and desktop products have traditionally defined the user experience for most types of applications (with some challenges coming from the simplicity and intuitiveness of Web browser and portals). But, from the vendor's perspective, there is much more to Office integration than the several simple scenarios enabled by Duet and Snap. As Office evolves into a system that supports deeper and contextual business intelligence (BI), workflow, search, document management, and enhanced collaboration through products like Microsoft SharePoint, Microsoft has come up with a composite architecture that quite exceeds the one of Duet. It builds on the long-espoused idea of providing users with more integrated and contextual working environment (see What Do Users Want and Need? ). Perhaps the best example is the successful Microsoft Dynamics CRM 4.0 product that features native Outlook UI and its accompanying, instantly familiar experience. Indeed, anyone who wants to see what comprehensive integration between a business management application and Office looks like, should check out the user experience of Microsoft Dynamics CRM, where the entire application "lives inside" of Microsoft Outlook. For more information, see War Looms in the On-demand CRM Market (and Beyond)—But Will You Profit from It?.

This would be the best embodiment of Microsoft's vision of connecting people across a company with the business processes and information they need to be successful within the context of the productivity tools they use every day. The idea is now is to determine how to extend similar capabilities and the same (or at least a similar) "look-and-feel" across all the ERP product lines. There is at least some virtual convergence of diverse product lines (if not necessarily the convergence at the server side). To that end, Microsoft touts "simplification" and "minimalism" as the guiding principles of evolving its applications and making them modern, in terms of user experience, runtime infrastructure, and design time tools. On the user experience side, the vendor has tailored the user experience to roles (thereby trying to reduce the user experience footprint per-role, as will be described later on). On the runtime infrastructure side, it has added several Microsoft technologies, ranging from reporting via analysis to portal capabilities. By doing so, the Microsoft Dynamics team has been able to get rid of a bunch of arcane code in its existing runtime environments that had duplicative middleware, since all Dynamics ERP products' portal presentation layers are now native in SharePoint, with reporting being in native Microsoft SQL Server Reporting Services (SSRS). The idea behind this was not just a simple case of substitution, but actually a reduction in code or abstractions that Microsoft had to maintain, and also the democratization of access to the data and business logic.

When it comes to design time, Microsoft Dynamics developers have been religious about keeping the development metadata driven. This was to mitigate the traditional difficulties within competitive development environments when it comes to enabling the extensibility of their products (e.g., adding entities, adding a couple of fields, relating these relationships, adding some form, writing some logic, exposing the underlying business logic as a Web service, creating a Really Simple Syndication [RSS] feed out of it, etc). Conversely, Microsoft touts its metadata driven modeling tools as a key to how to achieve and maintain simplicity (which is the key driver for the partners' productivity too) for the most complex of customization tasks, while still adding new runtime capability like workflows, process, role-tailored user experience, etc.
Such new easily deployed and reasonably priced packages are aimed at helping customers improve the situation they face today. On average 85 percent of employees do not have direct access to critical information, such as data on customers, costs, orders, and schedules, contained in their ERP application. Microsoft argues that many users want to work exclusively in one Office environment or the other, rather than in pesky proprietary ERP screens. To that end, in March 2007, during the Microsoft Convergence 2007 user conference, Microsoft announced the upcoming availability of a new offering that should help customers further extend the power, insights, and process control of their Microsoft Dynamics ERP applications to most of their employees via familiar business productivity tools in the Microsoft Office system. The new Office-based client is intended to make the ERP capabilities available to a vast majority of employees, in comparison to customarily only extending this to those employees who have purchased ERP seats.

This new package, was somewhat awkwardly named (compared to Duet) as Microsoft Dynamics Client for Microsoft Office and SharePoint Server (MOSS), and contains a collection of up to 12 self-service applications that are built into the Microsoft Office release and SharePoint products and technologies. It also has a license for the recently released Office SharePoint Server 2007. These applications, such as Time and Attendance for Microsoft Dynamics GP, Project Time and Expense for Microsoft Dynamics SL, Microsoft Dynamics Snap Business Data Lookup for Microsoft Dynamics AX, and FRx WebPort and DrillDown Viewer, are expected to simplify access to business information and help connect employees more closely with their company's business processes. Also included in this new offering are licensing rights for customers or industry partners to build their own Office Business Applications (OBA), a new category of programs where Microsoft Office becomes the front-end for accessing the back-end ERP functionality of Microsoft Dynamics. For more information, see Microsoft's Underlying Platform Parts for Enterprise Applications: Somewhat Explained.

This new package has been priced to facilitate companywide deployment, as the price for Microsoft Dynamics Client for Microsoft Office and Windows SharePoint Services is $195 (USD) per user and Microsoft Dynamics Client for Microsoft Office and SharePoint Server is $395 (USD) per user. Microsoft Dynamics Client for Microsoft Office is available to Microsoft Dynamics Business Ready Licensing Advanced Management customers for Microsoft Dynamics GP 10.0, Microsoft Dynamics AX 2009, Microsoft Dynamics NAV 2009 and Microsoft Dynamics SL 7.

The Web services calls from the Office Add-On are relayed into the SAP environment, which also occurs within the Duet Extensions through the service bundling component. The engine on the client loads assemblies and metadata from the cache and interprets the metadata descriptions of applications to execute service calls, execute business logic, and construct and display the UI screen based on metadata, and interact with host software. The runtime engine uses an Outlook services library (using the standard programming features of Outlook) to integrate the following features and services:

* Action pane. The Duet action pane will mimic the behavior of the Office programmable task pane.
* Toolbar buttons. Custom buttons can be added to the application-level toolbar, and these buttons will trigger the execution of metadata-based actions.
* Context menu items. Custom context menu items can be added to folder and item context menus to trigger the execution of metadata-based actions.
* Outlook events. Selected standard Outlook events and behaviors are extended to automatically activate metadata-defined actions.
* Custom calendar views. Outlook tabbed forms and action panes are defined via metadata.
* Contact management. Additional tabs are added to contact objects for server-maintained data.

As for the security issues, the challenge Duet faces with authentication is that authentication needs to be separated from the authentication within the system. For authentication within the system, Duet reuses the authentication of the local user in the Microsoft Windows environment. This is generally implemented using Windows NT LAN (Local Area Network) Manager or Microsoft Active Directory, which most users are familiar with. Within Duet, SAP security experts have developed a module that is able to take the user token from the Windows environment and map it to the proper SAP user. In doing so, Duet is able to issue a single sign-on ticket enabling the client to communicate in a with the web services on the SAP side in a secure manner.

Once authentication is secured, standard SAP guidelines and principles take effect and the access is granted based on authorization profiles associated with the user in the underlying SAP system. For example, each profile is associated with a only a few of the cost centers that exist in the underlying system. A user can have access only to his or her own personal information based on service scenarios, while a manager is granted access only to his or her organizational unit within the entire system, and so on.
The Recent Duet Uptake

In any case, Duet's highly involved collaborative architecture that has shown the major "pains and gains" of SOA. (For more information, see SOA from a Management Perspective ). And it has resulted in a commercial product that is unequivocally priced (approximately, $125 [USD] per user, though this price does not include Microsoft Office and SAP licenses, but only for Duet functionality), that is sold and supported under no uncertain terms. With the most recent Duet 1.5 release, some drawbacks of Duet 1.0 have also been addressed, such as the number of supported languages, which has been extended to 16: Simplified Chinese, Czech, Danish, Dutch, Finnish, Italian, Korean, Polish, Russian, Swedish, Hungarian, Norwegian, and Traditional Chinese. These are in addition to English, German, French, Japanese, Spanish, and Portuguese in Duet 1.0. A few more scenarios were added too (e.g., recruitment management, travel management, purchasing management, workflow approvals and reports and analytics), some of which run within a Excel UI screen too (as opposed to only within Outlook in the Duet 1.0 scenarios). One should imagine the inclusion of data from other back-end systems beside those of SAP, down the track.

In fact, the success of over 400,000 sold Duet licenses within 18 months has "shocked and awed" many competitors. The responses were numerous, as competitors began to trot out their own, comparable products. IBM cited its Project Harmony that features the integration of Lotus Notes and IBM Workplace (formerly Lotus Workplace) to SAP (and to many more SAP product releases than Duet), Google touted its no-brainer on-demand Google Enterprise applications, many other vendors said that they also have the Office-based (or Office-like) interface. Others flouted their Asynchronous JavaScript and XML (AJAX) programming. Adobe/Macromedia Flex or simply an Internet browser also flagged their products with their familiar and intuitive interfaces (ironically, MSN Hotmail was one of the best deployments of AJAX).

In a particularly peculiar position was Microsoft, which certainly could not complain about royalties from 400,000 deployments (or at least acknowledgements) of Office, Exchange or Windows Server. However, the Microsoft Dynamics business applications group and the accompanying partner ecosystem probably didn't share the same enthusiasm, by any respect. To appease these constituencies, Microsoft released Microsoft Dynamics Snap applications n mid-2006. Microsoft Dynamics Snap, which, beside UI familiarity and simplicity for users, also provided in-context business data lookup in Microsoft Office programs. At the time, Microsoft pointed out that Dynamics Snap was a "shared source" initiative, because the vendor wanted to encourage its partners to build and customize these solutions for their customers, either for specific roles and verticals or to contribute in helping Microsoft build more solutions that enhance productivity and empower information workers. Microsoft emphasized its approach of doing this in a community environment, by distributing the Snap programs under a shared source license to enable people from other companies to modify and extend the programs at no charge. Since then, there have been reported over 18,000 downloads of Snap along with nearly 1,500 individual developers and companies that have joined the Dynamics shared source community. Although this continues to be a great way for Microsoft to understand the dynamics of a Web 2.0-style community (social networks) environment as it applies to business management software, there has been confusion about licensing to customers and what other products customer need to make use of the MS Dynamics Snap.
Even the developers from SAP Labs often express their love for the idea of mash-ups, which, according to Webopedia, is a term derived from the hip-hop music practice of mixing songs together. Mash-ups refer to a new breed of Web-based applications created (unfortunately) by hackers and programmers (typically on a volunteer basis) to mix at least two different services from disparate, and even competing, Web sites. A mash-up, for example, could overlay traffic data from one source on the Internet over maps from Yahoo, Microsoft, Google, or any content provider. Creating a mash-up from multiple sources into one dynamic entity is considered by many to represent the promise of the Web service standard and of on-demand computing (see SaaS-ing the Manufacturing Opportunity ). However, this business model has yet to create viable intellectual property and revenue streams for participants (given the dynamic nature of new product releases and versions), and especially in terms of a structured support and maintenance, which seems to be well spelled out in case of Duet.

The metadata repository stores metadata, authorizes access, and enforces the consistency of stored data, whereby the metadata storage component is a relational database built on top of Microsoft SQL Express 2005. This metadata describes objects that are exposed within Microsoft Office and their related UIs and associated actions, and is being pulled by the client, based on the user and his or her role(s) within the organization. The Microsoft Exchange handle, on the other had provides an application-friendly and user-friendly view of messages in Microsoft Exchange. It addresses the conversion of standardized messages from the backend server into Outlook objects, such as IPM.Note. The handler provides an independent layer to different versions and formats of messages, so that calling components do not have to address the versions and formats of Office objects or command messages for the client add-on. The Exchange handler provides interfaces to the most important objects within Microsoft Office, including e-mail (IPM.Note), e-mail attachments, the calendar, tasks, and contacts.

Last but not least, the service bundling component hides the implementation details and distributes incoming calls to Duet-specific Web services or SAP ESA services, or any combination thereof. The criteria that determine which component will be used during implementation is based on the method that can best support the respective use cases within the application. The service bundling component also implements a method to resolve any Duet-specific IDs toward SAP item IDs where necessary. It is anticipated that the vast majority of these services will be executed synchronously for functionality, such as data validation and displaying information in action panes. In case of asynchronous[2] calls, the service bundling component will always reply with an acknowledgment confirmation and then route the reply through the Exchange handler back to the client. An example of such an asynchronous call can be found in team management when requesting all organization contacts for a given user.

In addition to these components, Duet Extensions also include a number of so-called "pluggable services" that interact with existing technology to enable user roles, authentication, security, and reporting, and provide a set of tools for configuration and customization. The pluggable services enable integration with preexisting technologies and provide functionality, such as user roles, authentication, security, and reporting. Since these capabilities are not Duet-specific, customers should be able to deploy any of these services from different vendors that support these standardized interfaces. It should also be possible to reuse existing solutions already installed on site.

Apparently, Duet Extensions can handle all communication between the client and the underlying SAP ERP system, because Duet Extension can gather the context and define the objects that are exposed to the user. Thus, those extensions invoke the relevant underlying SAP ESA services to talk to the underlying applications within the SAP ERP environment. As described previously in some cases, the responses may be handled asynchronously. To accomplish this, Duet Extensions transmit the data back to the local client through the Exchange handler, which completes a simple round trip of data from the UI within an action pane to the SAP ERP system and back.
The metadata that is available on the client resides within Duet Extensions, whose server also acts as a consolidation engine. Most businesses have an IT landscape using a number of different SAP systems, such as an SAP BW, SAP ERP, SAP CRM, SAP SCM (Supply Chain Management), or any number of non-SAP solutions. The Duet Extensions server unites one or more of these backend systems, by taking the metadata from various underlying systems and combining them based on the user and the user's role within the organization, and pushing it down to the client. As the users might not always be online, Duet must be careful in the way it communicates information back to the client, and additional queuing and caching may be required in the Extensions. The data is communicated from SAP ERP into the Exchange handler, which properly formats the information into an extensible markup language (XML) document (or a format that the client can then understand).

If a report is needed, information needs to be converted into a hypertext markup language (HTML)-based email, maybe with some kind of attachment. It also requires flagging the report with specific metadata that is not visible to the end user, but is rather attached to the e-mail body. This enables certain kinds of processes once it reaches the client environment. The client then interprets the metadata and dynamically combines it into the UI screen before presenting the notification of the report to the user (e.g., the final budget status notification). The rules gathered from the back-end system are converted into metadata that the client can understand, and the gap between the two systems is bridged. Because Duet is role sensitive, information presented and executions available to the end user depend on the user's role within the organization (whether the user is an employee or a manager, for example).

The Role of Microsoft Office Add-On

Further, the Microsoft Office Add-On enables communication between the local Microsoft Office client with the Duet Extensions and the SAP system through a metadata portal and storage interface. In other words, the Office Add-On, also known as the Duet Client, represents the Office screen add-ons based on metadata, since it uses the master data for drop-down menus or business rules and then triggers activities in the principal SAP system through either synchronous or asynchronous Web services calls. Metadata descriptions of the various applications are interpreted through the engine, which supports integration with various kinds of host software. The engine also provides Outlook integration, personalization, Excel integration, InfoPath (recently renamed into Windows Workflow Foundation [WF]) integration, and metadata-defined forms. Duet also supports SAP Business Workflows through Microsoft Outlook.

In order to illustrate how data is routed through the Duet architecture, one needs to understand that a typical Microsoft Office user often creates status reports of one kind or another. Using Duet, this process is accelerated since the Office interface already shows which reports an information worker can subscribe to, and offers templates for creating new ones (e.g., a budget report needs to be delivered every Monday morning at 9 a.m., or the project manager wants an alert only after the project has reached 80 percent of total budget consumption). All of these kinds of activities can be done using the local client, in which case it is Microsoft Office combined with Duet.

The Client or Office Add-On is responsible for representing the UI, based on metadata and other kinds of desktop information. For this purpose, the Client/Add-On is separated into three major parts: 1) runtime engine; 2) cashing mechanism; and 3) output queue.
The runtime engine interprets metadata in order to understand which business object is being exposed (a budget report, leave request or time entry, for example). Through these exposed objects, the Office Add-On is able to create subclasses of the existing objects within Microsoft Office. For instance, a "time entry" would then be treated as a subclass of an "appointment" object, and these classes would be exposed through the UI within the action pane environment. In addition to describing objects, the metadata also describes the UI screen and actions that can be triggered from within the user screen. This additional metadata, available on the client side, includes both generalized personalization data and some master data. The generalized personalization data, for example, determines which fields become available in the action pane, whereas the master data, for example, determines which project's budget is being assessed or the default status report profile. The engine's metadata form definition component is the primary method used to customize Duet forms and dialogs, whereby administrator users, using a metadata definition, can customize the action pane, custom dialogs, or Outlook custom forms. This level of customization also enables easy text replacement and user screen fields localization.

The caching mechanism is responsible for maintaining the proper metadata on the client machine, and is based on the user's role and supplies the functionality to store a user's metadata based on user role and data instances. It also stores metadata in a secure manner, and provides access to metadata when disconnected from the Duet server. Furthermore, the cache includes deployment capabilities that deliver application assemblies proactively to a user's machine. Last but not least, the cache provides offline data retrieval for the Duet by switching between the offline store or to the online Duet server when accessing data by using hints from either metadata parameters or other configuration information. The cache component also provides the first-time provisioning and deployment of reference data, reference data expiration refresh rules, and local data storage. In summary, the caching component ensures that metadata, master data, and additional files and objects are kept available locally and are up-to-date. The component is able to store this data on the local client without the need to continuously synchronize and resynchronize with the backend SAP ESA services. And by inserting a validity period into that, Duet can always keep the data cache up-to-date with regards to changes from the back-office system. It is not so much a push for updated information, but rather a pull from it, which should also speed up the end-to-end communication by preloading some of the data that the underlying system will request.

The third component of the Client, the output queue, provides the functionality to enable users to initiate actions while being offline, which are then invoked whenever a connection becomes available. The output queue component is invoked when a user triggers an activity, such as saving a time entry. It then takes the selected business object and triggers activities in the underlying SAP ERP system through either synchronous, or asynchronous Web services calls, which then come into the SAP environment within the Duet Extensions, through the abovementioned service bundling component. This component allows the Duet to compose multiple underlying Web services into a single one for, say, performance improvement, or for using the result of a first call for a second call.
Queued actions are serviced as soon as possible. If online, these calls are serviced in short time intervals; if off-line, the calls are stored for invocation later. Logically, the output queue is used only for asynchronous calls, and to support this functionality, the output queue provides interfaces to be able to "flush the queue" when the backend server is available. Calls made by the output queue to the service bundling component in the backend system will generally respond synchronously with acknowledge confirmation. Duet supports the deployment of applications to the client machine as complete units containing the metadata, assemblies, additional required client components, and reference data required to execute the application. This will occur automatically through a deployment mechanism and includes upgrade control in the form of versioning.

The relationship between the two software powerhouses, Microsoft and SAP, has been intriguing to put it mildly, at least since Microsoft's entry into the enterprise applications arena in late 2000 (see Microsoft 'The Great' Poised to Conquer Mid-market, Once and Again ). While the relationship has been depicted by many through a myriad of antonyms, such as "on-off", "hot-cold", or "love-hate", currently, it can best be described as "mutually civil". One can even find some uncanny similarities between the two, such as the occasional involvement in intellectual property lawsuits (whether as plaintiffs or defendants) or through the relatively recent, almost coinciding departures of technological visionaries, Satya Nadella and Shai Agassi, respectively (although Nadella was merely transferred within Microsoft, to the search and ad group that will hope to fend off Google's undeniable threat).

Microsoft and SAP then entered a "strange bedfellows" or co-opetion phase in their relationship, by dallying in business applications. Acting like two high-profile on-again, off-again celebrities, the two were dismissive about questions from the press and analysts about the inevitable competition this partnership would create (i.e., responding "We do target different sizes of companies"). Nonetheless, this stance become moot owing to SAP's forays into small business via SAP Business One and Microsoft's propping up of Microsoft Dynamics AX, as an upper mid-market solution. Then came a perceived snub by SAP for opting for Java 2 Enterprise Edition (J2EE) as a primary development environment for its infrastructure and development platform (while there is, nonetheless, some lesser valuable interface options for the counterpart Microsoft .NET Framework environment). However, SAP's move was quite logical given the still lingering perception of Java's better fit for larger enterprises (see Understand J2EE and .NET Environments Before You Choose ).

Any hard feelings between SAP and Microsoft were short lived, as we found out in 2004 when the two were engaged in secret (and startling) merger talks, which was quickly put ad acta before the news broke (whether for good remains to be seen). For most of that year, both vendors had to spend time explaining their separate forays into developing next-generation, service oriented architecture (SOA)-enabled products. Then 2005 seemed to be the year of bliss, where the two expressed mutual respect, and even worked jointly on a commercially available product featuring best of both worlds. Specifically, SAP and Microsoft joined together to leverage the openness of the SAP NetWeaver and Enterprise Service Architecture (ESA) blueprint (see Multipurpose SAP NetWeaver ) with the .NET-based architecture of Microsoft Office desktop applications suite (see Subtle [or Not-so-subtle] Nuances of Microsoft .NET Enablement ). The result was the joint product code-named Project Mendocino (the name of a town halfway between the companies' respective US headquarters) that promised to deliver familiar Microsoft Office desktop management and productivity tools as the façade for the heavy-duty lifting processes of SAP's enterprise applications. In other words, Project Mendocino extended and automated selected business processes from SAP ERP (Enterprise Resource Planning) through the familiar Microsoft Office user interface (UI), by providing role-relevant displays of information while retaining SAP applications' process context and the necessary collaboration and analytic tools.
Portal and other SAP entry points, such as SAP Web Dynpro or the recently unveiled NetWeaver Business Client, (formerly known as Project Muse), which is still needed for power users to gain full access to more advanced SAP business applications and processes. However, for casual information workers that require quick access to simple repetitive processes, such as billable time entry, leave request, or budget monitoring, Project Mendocino came in handy, because it eliminated the reliance on power users and business application experts. At the same time, it also connected business process applications with commonly used productivity applications more seamlessly. The product's capabilities included personalization, object synchronization, report distribution, alerts or notifications, a form-based approval process, and offline functionality. Through these capabilities employees and managers had the potential to realize greater efficiency and flexibility within a number of self-service processes. Other potential benefits revolved around higher productivity, better decision-making, audit traceability and transparency, and faster user adoption.

More information on the initial product's processes, capabilities, and benefit can be found in Major Vendors Adapting to User Requirements and in the book Enterprise SOA: Designing IT for Business Innovation, by Dan Woods and Thomas Mattern (2006 O'Reilly Media). For now, it suffices to say that Project Mendocino initially enabled information workers to perform tasks, such as time management, budget monitoring, organization management, and leave management via their desktops, using features like extended application menus, an SAP-specific smart panel, and business analytics delivered via Microsoft Excel, smart business documents in Microsoft Word, and synchronization Microsoft Outlook between Microsoft Exchange Server and SAP ERP processes.

Both Microsoft and SAP pledged to sell and support the product, which was first released to fifty pilot customers in late 2005 before it was made generally available (GA) in mid-2006 with its official name: Duet. At the time critics were quick to note that the product covered only a handful of simple business processes and that it was more "eye candy" than an "order winner". However, they did see that the product would also be a decisive factor for prospective customers to implement the entire SAP ERP suite (or, for existing SAP users to migrate to its latest release). Critics also expressed caveats of necessary technological prerequisites and hidden costs for Duet. Namely, the client machine runs on Microsoft Windows XP with Microsoft Office 2003 installed, while the Duet hub (which will be detailed later in this report) requires Microsoft Windows Server 2003 or higher and Microsoft Exchange Server 2003 or higher, including Microsoft Active Directory 2000 (however, there are no additional installation, software, or hardware requirements for existing Microsoft Exchange Server landscapes). Moreover, on the SAP side, users have to be on SAP ERP 2004 (including NetWeaver) or higher, while some most recent Duet implementations require additional SAP modules, such as Employee Self-Service, SAP CRM (Customer Relationship Management) 4.0, SAP SRM (Supplier Relationship Management) 5.0, or SAP BW (Business Warehouse) 3.5. The early product release also ran only in English and within Outlook (as opposed to Word or Excel).
More Than Meets the Eye

In addition to disseminating useful SAP data among knowledge workers (outside of its traditionally limited power-user dispatch list), Duet has been crucial for being a "proof of concept" model illustrating the potential development and adoption of composite applications, especially when the result of a joint collaboration between two software giants and market influencers.

Indeed, Duet is one of the first examples of a tangible SOA-based composite application product. While several tools use SOA conceptually, in ways that are sometimes hard to grasp, this tool is based on consuming services in concrete ways that benefits almost every information worker. Duet showed how SOA can be applied to the user experience through familiar desktop applications, and for some users, it will deliver functionality that supersedes the need to work directly with any line-of-business (functional department) or back-office enterprise applications. By exposing functionality and giving even the most casual users an easier way to update data that normally resides only in the back-office system, Duet embraced the innovative potential of SOA services. It exposes features from underlying ERP systems in new ways that create more value. And these services can be used together, even though they were probably written for a system that was designed before SOA was someone's figment of imagination.

This fulfills one of SAP's short-term goals for ESA (SAP's variant of the SOA blueprint) adoption—to create simple services (software components, if you will) that work on top of legacy applications already used by organizations. In the future, the entire stack which encompasses ERP, CRM, and all other SAP Business Suite solutions will eventually evolve to use business objects as their underlying application. Instead of having a rigid and unwieldy monolithic set of applications, SAP is creating a collection of business objects that can be applied in more flexible ways. By late 2007, there will be more services to choose from than the ones used to support Duet, since ESA follows the SOA format of "model once, run anywhere". Namely, instead of hard-coding multiple solutions that apply to different domains, ESA employs business objects or services that are modeled in a way that allows them to handle different solutions. Duet is just one of many client-side solutions that ESA will enable.

To understand how Duet is in tune with SOA, it is important to become familiar with the new stack defined by SAP ESA, and to understand what a composite application is. Webopedia defines a composite application as an application that consists of more than one type of service delivered from an SOA environment. It can range from functionality to entire applications. Services are generated through "local" application logic that controls how services interact with each other. For more information, see Understanding SOA, Web Services, BPM, and BPEL.

As a composite application, Duet overlaps with nearly every part of the new SOA stack:

*

User screens. Duet uses the familiar Microsoft Office desktop interface, which is achieved not by hard-coding the UI, but through backend modeling and deploying it to the client.
*

Process orchestration. Duet uses a communications hub referred to as the Duet Extensions to route data to and within the ERP system.
*

Process integration. Using the aforementioned extensions, Duet translates data from Microsoft Office applications such as Excel into a format that is easily understood by existing ERP tools and their respective enterprise services.
*

Process workflow. All of the usual workflow processes within SAP ERP take place within the context of Microsoft Office's desktop tools.
*

Distributed data. The ability to cache data for working online or offline also plays an important part in the functionality.

Other applications being created by SAP will use different parts of the stack to enable different solutions. However, other services created for Duet should indirectly benefit all SAP ESA users by increasing the total pool of objects in the SAP Enterprise Services Repository. Also, every service and application being created for Duet is designed so they can be used by other applications within the ESA environment. For instance, timesheet entry services are part of the Cross Application Time Sheet (CATS) feature that will be used by many applications that rely on timesheet recording and account assignment.

The Duet Architecture Outlined

Despite seemingly simple processes that Duet enables, the product exemplifies how serious an undertaking a commercially available composite application can be. When the goals of Project Mendocino (now Duet) were first formulated, it reportedly[1] became clear that two very different architectures needed to be brought together. On the one side was the ubiquitous client application, which required local data storage, while on the other side was the proverbially complex SAP ERP environment. The different technologies in this case reportedly made it quite easy to select Web services as the interface technology, since both camps added standards-based Web services support in their last releases. However, in this case, simply connecting these two worlds using Web services did not offer a comprehensive enough solution. Namely, the goals required more extensibility, because SAP wanted to enable a model-driven environment on the client side, which would allow Duet to push additional screens and updates to the user without the need to continuously run through an installation and reinstallation whenever business needs changed.

On top of that, Microsoft Office currently works in online as well as offline modes. This capability had to be maintained in Duet as well, since users had to be able to trigger activities while being offline which would later have to be automatically resynchronized once their machines went back online. At the time, Microsoft and SAP also realized that the involved disparate system components (i.e., Microsoft Exchange Servers, Microsoft Office, and SAP ERP systems) are of such a high value to customers that massively updating those environments (and exposing the existing system landscape to any unnecessary disruption) would be unacceptable. SAP and Microsoft weighed these requirements carefully and realized that there was a the need for a communications hub that would sit in the middle of the two existing environments and "mediate" communication and processes. The hub collects various configurations from the back-end system, determines the objects that should be exposed, and decides which activities the user can trigger and how all of that ties together within the user screen. The communications hub is also referred to as the Duet Extensions, which are connected with the Microsoft Office client and the SAP ERP system. The result is that there are three primary parts to Duet's architecture: 1) the Duet Extensions; 2) the Microsoft Office Add-On; and 3) SAP ERP foundation.

The Role of Duet Extensions (the Hub)

The Duet Extensions are implemented in the Microsoft .NET Framework and use the J2EE technology. They act as a hub between the client side and the SAP ERP systems on the server side and enable these two to talk with each other. They also include the application description in the form of metadata (or "data about data") and cater the metadata to the client side. The major components of the Duet Extensions include 1) metadata repository interface and storage; 2) Microsoft Exchange handler; and 3) service bundling.