Enterprise architecture frameworks

IT architecture takes a prominant role when you integrate technology from more than one vendor. Sven Feurer from SAP has an intertesting article on the evolving role of the enterprise architect part 1 and part 2. He quotes McKinsey’s Investors Opinion Survey, June 2000, which asks 138 CIOs pertinent questions about enterprise architecture.

The three most relevant frameworks identified by the survey are:

• The Open Group Architecture Framework (TOGAF) (chosen by 54%)
• The Zachman Framework for Enterprise Architecture (chosen by 35%)
• The Gartner Enterprise Architecture Framework (chosen by 29%)

We are currently skilling up on TOGAF 8, which offers a widely supported, open framework that can scale to accommodate diverse customer specific requirements.

Enterprise architecture must be defined by the customer. Solution vendors can't do it. The definition should be pragmatic and aspirational rather than legalistic.

Let's say you find a proven, packaged solution that meets your needs. The only alternatives are custom development or a much worse fit. Don't let a great architectural vision stand in your way. Make sure the governance component allows exemptions for compelling business reasons.

Microsoft Reporting Services and SAP BI

Stephan Stoltze from Microsoft has an interesting Microsoft perspective on the options available to access SAP BI data using Microsoft products - Microsoft Business Intelligence on SAP Netweaver Data.

The default scenario for SAP BI users is to utilise SAP products like Bex Analyser and Enterprise Portal to administer BI and query data. However, Microsoft also provide some very powerful analysis and reporting tools. As Excel 2007 becomes more adept at handling OLAP data (and has features to publish it to a SharePoint portal), the case for a multi-vendor BI solution is more apparent.

The three proposed scenarios using Microsoft products are:

1. Embrace BW



Use reporting as a client tool for SAP BW. Microsoft .NetProvider for SAP NetWeaverBusiness Intelligence to expose the data using an XML/A interface to BW. This option has the least issues, providing a comprehensive solution with SAP security. See the presentation for tips and tricks.

2. Extract raw SAP BW data

Purchase SAP Open Hub Service (OHS) and extract the data into a Microsoft data mart for reporting. This is meant to perform better, but requires purchase of an OHS license from SAP. I would also think there is considerably more effort to implement it, as you are effectively building and integrating two distinct BI solutions.

3. Extract raw ERP data - no SAP BW

Here the data is extracted directly from tables in the SAP transactional system into the Microsoft data mart. There are few advantages to this option. It is not supported by SAP, you have no SAP security and you lose out on all the predelivered SAP business content and it breaks the cardinal rule about not accessing SAP tables direclty.

If you need Microsoft's analysis tools, most scenarios would support option 1 as the clear choice.

Thin, Fat, Rich, Thick and Smart Clients

When you set out to build an application in .NET that leverages SAP as its data store you have several approaches for architecting the front end.

Thick Client (aka Rich or Fat Clients)
Windows applications before the advent of the internet. Thick clients come with a setup.exe file that unpacks and installs the application.

Thin Client
Web pages in a browser, controlled by one or more web application servers in the middle layer, and typically additional servers at the back end for databases or LOB applications like SAP.

Smart Client
Thick clients that leverage network access to install and update themselves, and make use of other networked resources like web services. They are not stand alone applications and always form part of a larger distributed solution.


Microsoft has an excellent architecture and design guide that explains when and how to use smart clients.

Connecting an InfoPath form to a SAP web service

Anne Tarnoruder from SAP and Dudu Benabou from Microsoft explain how to link an InfoPath form to a SAP web service in this presentation.

Microsoft / SAP relationship

Here are some interesting points from a presentation by SAP's Franklin Herbas in 2005:

• 60% of SAP solutions run on Microsoft servers
• More than 90% of desktops use Windows and Office
• Microsoft Windows is the only platform that supports all SAP products
• Microsoft is one of our biggest partners: “Microsoft is 95% partner and 5% competitor.” (H. Kagermann)
  

Exception handling for SAP web services

Andre Fischer (again) writes about exception handling for Web services based on Business APIs (BAPI) using Visual Studio 2005.

Debug a web service call

Andre Fischer writes on SDN about how to debug an ABAP web service call from Visual Studio:

When developing .NET based Web services clients using Visual Studio that call Web services in SAP NetWeaver .NET developers would like to be able to debug inside SAP. In my blog I would like to point .NET developers to the fact that SAP NetWeaver offers the option of external debugging to perform this task. Feb. 7, 2007

MS white paper: Integrating Office SharePoint Server 2007 and SAP

From the Microsoft SAP Global Alliance Technical Team blog:

The SharePoint Team published a new whitepaper Integrating Office SharePoint Server 2007 and SAP which describes the innovations in Microsoft Office SharePoint Server 2007 that make interoperability with SAP easier than ever. The paper explains the general business and technical challenges facing customers who want to bring the power of their SAP assets into the tools and places where information workers do most of their work. It then shows how Office SharePoint Server 2007 addresses those challenges and, finally, describes various interoperability options, from simply displaying SAP information in a portal page to creating complex business process solutions that incorporate SAP data.

SharePoint BDC and SAP

Share Point now has a Business Data Catalog for storing useful business information and making it easily available in customizable web parts. This is not to be confused with SAP BDC sessions, which are completely different. The Share Point BDC is just begging to be populated with data from your SAP system. There are two approaches, one of which is heresy if you come from a SAP background.

1. Use web services to access SAP data retrieval functions (correct)
2. Connect directly to the underlying SAP tables (so wrong!)

Option 2 is easier, more efficient and more elegant. However, it breaches the integrity of the SAP "data vault" model by ignoring the security and business logic programmed into the SAP interfaces.

We are going down the former path, exposing SAP master data to the Share Point BDC using the appropriate web services (and writing our own if none are available).

BizTalk Adapter for SAP

More correctly, the Microsoft BizTalk Adapter for mySAP Business Suite v2.0 SP1! This adapter integrates one or more SAP systems into a BizTalk scenario. To get it to work, you also need .NET Connector 1.0. It wont work with version 2.0...

Enterprise Services Workplace

The loss of the old SAP Interface Repository (IFR) was a pity for anyone wanting to know about BAPIs but who didn't have a SAP system to play on. A new list has appeared, although without the technical details of structures and fields. It is called the Enterprise Services Workplace. In case you haven't heard, what you once knew as RFCs, then BAPIs, then web services, are now called enterprise services...

SAP and Microsoft .NET interoperability

It may come as a surprise to know that a Microsoft team is resident in Waldorf, and a SAP team in Redmond. Microsoft actually run SAP as their own ERP system, so there is no doubt a lot of very interesting proprietary code in Redmond joining the two together.

The most famous output of this partnership is the new Duet product suite which anyone familiar to traditional SAP interfaces will be very excited about - seamless integration into Microsoft Outlook. For example, when you want to book holiday leave in Outlook, it connects to SAP HR to show how many days leave remain. If you complete the booking a leave request is automatically submitted for approval. Things like that have serious value, and it looks good too.

Duet leverages and enhances the relatively unknown Microsoft Office Information Bridge (IBF) to provide data on demand to the respective Office TaskPane. Unfortunately we have to wait until at least next year for the PDK that lets third parties develop in that technology.

We are also waiting for an updated .NET connector. The current SAP Connector for Microsoft .NET (NCO) version 2.0 only works with Visual Studio 2003. According to Rohr, Meigen and Fischer (p95), SAP "is considering" a plug-in for Visual Studio 2005. This would be called the Enterprise Services Explorer for .NET. Please comment if you know any more about dates for this. In the mean time, we are developing our own interoperability framework with store and forward capabilities and tightly bound controls.

Introduction

Welcome. My goal for this blog is to share insights I gain as my projects allow me to explore interoperability between SAP and other vendors' technologies.

My background is somewhat varied. I have been responsible for developments in numerous environments, from Z80 machine code to Sun Ada cross compiled onto a Motorolla single board computer. More recently I have been working in SAP ABAP, PHP, Ruby and Flash Actionscript. Development methodologies I've known include CSC’s Digital Systems Development Methodology (DSDM), C/SCS, SAP ASAP methodology, RUP, and now we're trialling a proprietary agile approach. I have a business degree from one continent and a masters in cognitive science from another, 10 years in Europe, 3 in the Philippines and now am back in Australia.

My responsibility for the architecture and SAP technical delivery of a major project relying on close collaboration between SAP ABAP and Microsoft .Net development teams gave me the impetus to start this blog. As part of the process we were closely exploring the relative merits of Microsoft SharePoint Portal versus SAP Enterprise Portal. It has been a fascinating journey, made very difficult by the small pool of people with in-depth knowledge of either technology. They both have a considerable gap between what you read you can do, and actually doing it.

As this blog develops, it will report on innovative solutions and technologies, always leveraging SAP data and transaction logic.