Reasoning for Duet Enterprise in addition to SAP NetWeaver Gateway

With the release of Gateway 2.0 as addition to the SAP NetWeaver stack, the question is justifiable whether this on itself is sufficient for SAP / Microsoft interoperability. Stated otherwise: ‘Do you need Duet Enterprise?’ The answer on that depends on your requirements, IT strategy, plans and situation. On level of desired application(s) functionalities as well as the Enterprise Architecture strategy, policy and plans in your company.

This blog is earlier published on SAP Community Network Blogs

Is Duet Enterprise required for SAP / Microsoft interoperability?

An answer to that question is: No, Duet Enterprise is not per se required, but it might be the wise decision. To make that decision, multiple aspects must be considered.

1. The extras Duet Enterprise brings to the table (compared to Gateway alone)
2. Your SAP / Microsoft roadmap and plans; multiple applications and a future-robust strategy, or just now for a single project?
3. Enterprise Architecture guidelines
4. Functional requirements
5. Limitations and implications of Duet Enterprise

Duet Enterprise extras to SAP Gateway for SAP / Microsoft interoperability

The extras fall into different categories.

Functional

• Standard SharePoint rendering of the imported SAP data through SharePoint Business Data webparts
• Standard CRUD+Q UI-process pattern on SAP data; for bidirectional data handling
• Support / hook into SharePoint Enterprise Search
• Collaboration workspace around SAP data entity: Customer, Product, Quote
• Integration of SAP workflow into SharePoint context
• Same for reporting: schedule + review SAP BW reports from SharePoint front-end

Connectivity

• Single Sign-On from SharePoint into SAP
• Propagation of SAP user authorizations into SharePoint roles + permissions
• Propagation of SAP data authorizations to SharePoint Search context, via construction of ACL’s on the External Data entities
• Transparant SharePoint (consumer) – SAP (provider) runtime connectivity via SharePoint BCS

Operations and lifecycle management

• End-2-end monitoring; starting from SharePoint, via SCL, upto SAP backend
• Audit trail per use case

Development

• Design tool for generation of BCS Model on basis of Gateway Model (itself generated via Gateway generation tools)
• Integration with SharePoint; Gateway is strict to provide standards-based access to SAP data, Duet Enterprise is also a first-class
  SharePoint-aware user.

Roadmap + ecosystem

• SAP and Microsoft have a roadmap outlined for Duet Enterprise
• Base functionality provided by Duet Enterprise
  product is augmented via the partner ecosystem (via Unite program)

Enterprise Architecture

The decision for Duet Enterprise implementation is not made in isolement. It must be considered and fit in the greater area of enterprise architecture. It is evident that Duet Enterprise only makes sense if your IT
landscape contains both SAP and Microsoft. But that alone is not sufficient to justify the purchase and implementation of the product Duet Enterprise. Does EA mandate usage of standards: interoperability protocols, products? And for
common-of-the-shelf products, prefer strategic suppliers Microsoft and SAP above third-party suppliers? These are just 2 examples of questions on which EA should make a thoughtful decision and statement, resulting in EA guidelines.

Functional requirements

The often required rationale for Duet Enterprise is actually a negativisme of the SAP (G)UI. So it is not so much that the decision is made for Microsoft / SharePoint, but more that it is decided against the 'detested' SAP user interface. But if the only motivation is to get rid of the SAP user interface and replace it by another, there are other possibilities. Build a custom user interface in SAP WebDynpro for instance.

Duet Enterprise starts to shine when you combine the powers of the SharePoint platform with the functionality of the SAP processing. Not merely rebuild the SAP user interface, but design and architect an improved user experience by integrating it within context of the information worker.

Limitations and implications of Duet Enterprise

Duet Enterprise is not a silver bullet for all SAP / Microsoft interoperability occassions. It has limitations, intended or as consequence of architectural desicisions. Also, implementation of Duet Enterprise has its costs.

Limitations of Duet Enterprise

• No support of REST protocol
• Limited to data-oriented, CRUD+Q service signatures
• Design-time tooling support only for inside-out approach; not for outside-in
• Full design-time tooling support only for flattened SAP data-structures
• Standard SharePoint rendering only for flattened data structures. This is actually a limitation of the standard SharePoint BCS UI controls. Rendering of complex data structures can be done via custom build SharePoint UI-controls (example: Working with complex SAP business entities in Duet Enterprise).

Costs of Duet Enterprise

The costs fall apart in different categories:

• Recurring license costs
• One-time deployment and installation effort
• Training of IT operations, architects and developers (for all: SAP and Microsoft)
• Optional (but recommended for any except a simple SAP landscape): dedicated SAP Gateway application server
• Duet Enterprise design time requires presence of SAP Enterprise Service Repository (ESR)

Conclusion

The decision for the implementation of Duet Enterprise must be made in perspective of the business requirements and middle-term enterprise architecture. If SAP / SharePoint policy is a fundamental part of the [future] business application and IT landscape, Duet Enterprise might very well be the sensible decision. Better as realizing + maintaining an own SAP / Microsoft interop layer (no matter how smart your IT people are, they will on longer term never win it from the sheer combination of SAP + Microsoft product team). And also better as purchasing + implementing third party products. That will result in more shattering in your IT landscape, while you must assure yourself of the continuity of the product and its supplier. Again here the combination SAP + Microsoft gives on the longer run more trust as that of smaller although dedicated suppliers.

Participating in Duet Enterprise Ramp-Up / Rapid Deployment Program

This blog is earlier published on SAP Community Network Blogs

In May this year, TopForce applied as IT partner together with an end-user organization for participating in the Duet Enterprise Ramp-Up. Rationale for both organizations to participate in this Rapid Deployment Program is to gain in an early stadium insights and practical experience on the potential and added value of Duet Enterprise.

Our mutual application was accepted by the RDP Program in June. As one of the first activities, both organizations each sent 2 to 3 employees for Duet Enterprise training. Actually this was a requisite for RDP participation. The 5-days training addressed both the infra/operations aspects of Duet Enterprise in the SAP and Microsoft landscapes [3 days], and the development approach in the SAP and Microsoft development suites [2 days].

After this first introduction to the Duet Enterprise product, we received access to the software bits and accompanying documentation. The last mostly in draft versions, understandable as the product is still in Ramp-Up.

Reasons for participating

The mission of TopForce is to deliver the concept of High Performance Workplace for our customers. In essence this means that we aim for ease of use in the daily workspace of the employees, thereby abstracting the nifty details of the total backbone IT landscape. As our background comes from SAP consultancy, at a lot of our customers SAP is [part of] the business back-end. In our HPW vision, one of the means to achieve a pleasant employee workplace is operating the SAP back-end via a SharePoint based front-end (Unlock the value of SAP business processes within a SharePoint based HPW). We defined a conceptual integration architecture for this SAP-backend / MS-frontend interoperability. The architecture is validated via multiple interoperability technologies and products; e.g. WCF to BAPI WebServices, WCF LOB Adapter, Sitrion. Drawback in all was that we still had to develop a lot of the interoperability plumbing ourselves, most noticeable the support for Single Sign-On. Duet Enterprise now promises to be a good (best?) additional alternative for enabling SAP / MS interoperability.

Our partner shares this same goal, but also has a clear additional target. In the recent history several projects have emerged in which SAP / Microsoft integration might be subject for business and IT architectural decision making, and/or in which SAP / Microsoft integration is concrete realized in some aspects. As the role of both SAP as Microsoft server landscapes is gaining importance at this end-user organization, they have the need for consistent design guidance on when and how to achieve SAP / Microsoft interoperability. Duet Enterprise is participated in this context as an important integration technology to consider.

Project team

Our RDP project team consists of the following roles / persons:

From the end-user organization

1. Project lead
2. SAP solution architect
3. Microsoft solution architect
4. SAP business analyst
5. SAP infra/operations
6. SharePoint infra/operations
7. SharePoint developer
8. SAP NetWeaver solution architect / consultant

From TopForce as IT partner

1. SAP / SharePoint interoperability consultant (my participation in this Ramp-Up)
2. ABAP developer [only temporarily required]

From the combined SAP / Microsoft RDP support team

1. SAP NetWeaver consultant [from SAP AG]
2. SharePoint consultant [from Microsoft Services]
3. Whenever applicable, supplemented with SAP and Microsoft consultants with varying expertise’s; dependent on nature of discussions and encountered issues

Validation approach and activities

The potential of Duet Enterprise is twofold. On one side it delivers directly usable out-of-the-box functionalities, customizable in some degrees to your situation. Second to that, and this is where it strongly differentiates from the original DUET proposition, it provides a SAP / SharePoint interoperability foundation. Although the first is certainly interesting, our main combined focus for now is evaluating Duet Enterprise for the added value on interoperability plumping aspects. This validation is done by means of a real-life custom-developed application. The following activities are executed by the RDP team:

• Attend the Duet Enterprise training to get acquainted with the infra and development aspects
• Install and configure Duet Enterprise in the SAP NetWeaver 7.02 and SharePoint 2010 landscape
• Derive and define the Software Architecture Design for the selected real-life application
• Discuss the Software Architecture Design with RDP consultants, from SAP AG and Microsoft Corp.
• Model, compose and [only] where required custom-develop the interoperability + integration between SAP backend environment, and SharePoint 2010 based front-end
• Derive and define the Design Guide for SAP / Microsoft integration decision making at business and IT architecture level

Where do we stand / Results so far

In this near-end phase of the Ramp-Up program, approaching the General Availability of Duet Enterprise, it is not viable to go into product details. This will be addressed later, after the successful conclusion of our Ramp-Up participation.

Results and findings that I can share now are:

• Getting acquainted with the design and development approach for Duet Enterprise application has an initial steep learning curve. Mind you, this will be less after General Availability when the accompanying documentation will be more complete and mature.
• Installation and configuration of Duet Enterprise takes its time. This is mainly due the complexity of any typical SAP landscape anno 2010 (aka ECC, NetWeaver, Solution Manager, SLD, ESS and MSS, …), and not so much to direct back to Duet Enterprise specifically. On SharePoint 2010 side the work is much less, although also here it depends on the characteristics (complexities) of the SharePoint farm.
• This RDP project is an evidence for the added value of a mixed SAP / Microsoft development team (Build Your Interoperability Team as 1 of the Steps HowTo begin with SAP / MS interoperability)
• It pays out if the SAP and Microsoft solution architects are on a general level familiar with the ‘opposite’ platform stack. E.g. what’s the positioning of SAP PI versus Microsoft BizTalk; what is the concept and support of SAP Enterprise Services;
• It pays out to have at least one team member aboard that has knowledge and practical experience on the SAP / MS interoperability area; knowledge of both technology stacks, interoperability technologies and approaches.
• And final remark: SAP / MS interoperability is and remains interesting stuff; from business and IT architectural point of views…

Duet Enterprise is approaching the General Availability date. If you are considering its application for SAP / Microsoft interoperability, I like to share ideas and actions.

Proud - Top 1 Contributor on SAP / .NET Interoperability Expert Forum

I really don't like to brag on my achievements. When however you receive as a 'Microsoftie' the positive acknowledgement from the SAP community on your contributions, this simple deserves to be proud of. So with humble modesty, I include a screenshot of today's status on the SAP Community Network Expert Forum on SAP NetWeaver .NET Technologies:

Microsoft Services has no concrete advice or guidelines on when to apply SharePoint versus SAP Enterprise Portal within a customer situation

At the last Microsoft Application Platform congress, Harry Tolsma gave a presentation on 'Optimizing your SAP-based business processes with the Microsoft Application Platform' (audio, slides). At the end of his talk, a question popped up from the audience on whether Microsoft has a decision matrix when to utilize MOSS, and when to hold on to SAP Enterprise Portal. At that moment, Harry could not give a conclusive answer on whether such a matrix is available at Microsoft Services. A time later I asked him whether he had more news on this.

The answer is that Microsoft Services does not have a concrete generic decision matrix and guidelines. The rationale is that each customer situation is specific, and requires a custom analysis and tuned advice. I intend to agree with this idea. With an important addition: for larger enterprises their specific customized advice and guidelines ought to be applicable across the entire enterprise, and should therefore be integrated within the enterprise referential architecture.
Reuse and application of the architectural guidelines and decisions is possible within the enterprise for unlocking and integrating of various SAP business functionalities and processes. My advice is to mandate this.

The blog of Kristian Kalsing contains 2 interesting posts related to the subject: ‘SharePoint versus NetWeaver Portal‘ and ‘EP/MOSS portal technology strategies’.

Tags: SAP NetWeaver Microsoft SharePoint integration interoperability architecture guidelines roadmap