Skip to Content
image image


Just the other day, I had this very interesting conversation with one of my client touchpoints. Having masked out the major details, here is the added piece of the entire approach that was taken more on a side-note on what the future direction needs to be on the Applicastructure front and the implications of Mendocino on Org.A. I found this to be the perfect ground with the client, who had a solid understanding of SAP’s ESA roadmap. And the discussions around “Mendocino” and “Applistructure” only solidified their conviction in leading the organization towards ESA. Read to understand the thought process behind the same.

The Thought process:

ORG.A is making a serious attempt to cut down on the number of technology platforms and application vendors making a move towards standardization to cut their entitlements costs and lowering TCO for applications that can be moved out of the ORG.A landscape. At the same time ORG.A wants applications, custom or standard that can be implemented, and used before the business strategy they were selected for is no longer relevant. Additional benefits being looked upon by ORG.A for Applistructure include the rapid reconfiguration and deployment, reusability of components, flexibility towards incorporation of business processes and cost savings through lower maintenance.

The concept of applistructure is the cornerstone of composite applications and represents a paradigm shift in the way applications have been built in the past. The future direction of ORG.A with its SAP NetWeaver initiatives is to effectively create a platform with SAP NetWeaver to create applications on top of applications agnostic of system landscape in a way to leverage existing applications functionality at a fraction of the cost of what it takes to build an application ground-up.

The key success factors:

The ORG.A Applistructure Program’s success will be based on the following considerations:

1. Reduced spend or TCO for applications that can be done away with (The legacy is more political than technical)

2. Allow for quick configurations & reduced timelines for implementation

3. Allow for quick enhancements

4. Allow ORG.A to leverage existing Infrastructure to the maximum

5. Lead the way for Integrated Applications

6. Agree for optimum integration functionality

ORG.A is looking at all the pre-built vertical and horizontal business processes within its current business system to plan its investment for the next five years. As seen in the earlier paper, ORG.A has been firm on laying down the groundwork to build such a platform that will change the way business processes will need to be enabled within. ORG.A is slowly moving away from the SAP “Product” paradigm to the SAP “Solution” paradigm. What ORG.A expects from SAP is not another bunch of cool products that will address its value-chain pain points, rather ORG.A is looking at SAP to provide pre-packaged business content that can be weaved at will for user groups to collaborate over the net. ORG.A’s objective with such an approach is to reduce TCO by lowering the cost of development and the increased usage of its existing infrastructure, in reduced timespans.

This increased usage of prebuilt business processes for ORG.A business applications see the logical lines between SAP application software and the Infrastructure blurring. This ultimately drives ORG.A to refer to this new breed of software as the “Applistructure” layer. Such an approach is seen by ORG.A as increase the degree of integration between the application and the Infrastructure layer.

The Skeptic within:

However, the strategic roadmap of ORG.A, though promising towards cost saving and crashed timelines, ORG.A will have issues in implementing the same. Some of the issues that may crop up during the implementation of this vision, which could make this initiative/Program no different from the standard Application development life-cycle which could be as follows:

Testing: ORG.A believes that Composite Applications will warrant significant time in building the services and metadata layer which will warrant development, testing, bug-fixing and performance tuning. The need for the Software logistics becomes increasingly important. Once the underlying components are in place, the development time may crash, but the time and effort investment in the above activities will remain constant.

Standards and Procedures: The need for carving out a scalable UM strategy is the key. Without a sound User management in place, the distribution of process ownership is just not possible. ORG.A is putting in the UM strategy in place calling it the “One-source” program which is aimed at using SAP HR as the source-of-truth” for user management. This goes a step above in EP UM for further logical segregations. “One-source” defines the source of truth for the user data from SAP HR.

Maintenance: Despite being propagated as the code-less approach towards process incorporations and real cool gui-design tools, these models work perfectly well in a lab or a COE (Center of Excellence). The situations encountered In the ORG.A real-time environment are entirely different and the issue resolutions or fixes transgressing over multiple layers making it practically impossible for ORG.A business users to pinpoint and fix issues or enhance them.

Enhancements: The Applistructure concept hazing out the boundaries of “products” and “projects” and the logical assimilation of these building blocks of processes and meta-modeling will warrant the need to incorporate further sub-processes into these pre-built content. This might remain consistent with the Applications enhancement timelines.

Overdependence on SAP: Leaning towards applistructure and Increased usage of the same within ORG.A will see too much dependence on SAP as their solutions move up the technology stack from infrastructure middleware to (partially) encompass the applications layer. From SAP’s perspective, this will tend to insulate them somewhat from the forces of product standardization and commoditization, but ORG.A will become increasingly dependent on the applistructure functionality provided by SAP.

ORG.A’s decision: No doubt, the dependence of ORG.A is now being tilted towards SAP. And while deciding on the feasibility of using applistructure for business logic, ORG.A needs to weigh the benefits against the associated increased dependency on a single vendor. The key question then becomes – are reduced implementation timelines & development costs truly low? If the answer is yes, then the level of increased dependence on SAP is not significantly greater than when using other type of packaged application software, using applistructure functionality will be a viable alternative in many situations.

The road ahead with a wait and watch approach:

ORG.A users rely heavily on Microsoft Office. SAP acknowledges that a large number — probably most — of its mySAP customers have Microsoft Windows and Office. With Office 2003 and the upcoming released, Microsoft added Web services hooks and other APIs that open up Outlook, Word, Excel, and SharePoint to intergrate with third-party applications. The meeting point for ORG.A and SAP comes is from a few facts:

– First, most of the SAP installations have users who rely heavily on Microsoft Office.

– Second, Rather than creating a custom client, SAP can use the Windows front end. An integration of the same will certainly be welcome for ORG.A, but the absence of the same is not a show-stopper.

– Third, ORG.A views this strategic move by SAP to reduce Microsoft to desktop applications, and not interfere in its plans beyond that.

This way, everybody is happy. Microsoft doesn’t have to face the applistructure onslaught unleashed by SAP, and SAP now getting a new breed of Microsoft user base to tap into. And with Mendocino, it seems to be a win-win situation for both, at least in the short run.

From a technology standpoint for ORG.A, Mendocino, as the technology framework, would allow ORG.A mySAP users to gain access to data that is managed by the mySAP enterprise suite once the upgrades are complete, and to work on SAP processes from within their Microsoft Office applications, rather than from SAP clients. This will allow ORG.A users to address the issues around ad hoc business processes that today a big problem area internally. ORG.A needs to see a human workflow engine integrated with the enterprise portal for straight through processing for all its future applications built using CAF.

This problem area has led ORG.A to explore areas of developing custom java workflow, human workflow engines and ORG.A is now towing with Mendocino to see if the issue can be resolved using this framework. Aligning with SAP ideas, ORG.A is targeting application areas like time management, budget monitoring, human resources Org.Anization management, and leave management, projects that may be low on the direct business impact, but are high-impact nonetheless.

The other key issue on the enterprise portal front for ORG.A, if ORG.A is to design its future xApps in line with its business requirements, Content Management is an area that falls short of expectations. Having moved its way with BroadVision in the past, ORG.A is in a dilemma to move mission critical applications onto SAP Enterprise portal.

Despite Mendocino being a boon on other areas, these areas are of the “must-have” category for ORG.A when compared to the “nice-to-haves’ being offered via Mendocino. Mendocino supposedly incorporates a server-side framework that manages communications with Office clients and translates interesting events into actions within the mySAP suite. The server-side framework runs on the SAP NetWeaver platform and employs asynchronous event management using Web services. Again, comparing SE80 of the ABAP world to the SAP NetWeaver Developer Studio of the Java world with the Microsoft Visual Studio tools, Mendocino is to include a plug-in to deliver information from SAP R/3 to me made available to MS users.

ORG.A clearly sees Mendocino as a move by SAP to restrict Microsoft to the desktop users in SAP accounts, thereby clearly demarking areas for both to operate by taking on the application layer, the middleware and the backend space to itself. Maybe new ideas on the anvil with ACC on the cards with IBM? Who knows? Microsoft intends to develop a version of Mendocino for its own Microsoft Business Solutions that will use the .NET platform instead of NetWeaver, which leaves room enough for discussions on the alliance ties between Microsoft and SAP.

The POC approach in the future:

Aligning ORG.A POC roadmap on Mendocino with SAP’s roadmap, let us take a quick look at the POC details with Mendcino within ORG.A:

Outlook POC at ORG.A with Human Workflow: From a business-case standpoint, this POC would revolve around the Meeting Management features extended to the leave management system within ORG.A. With Mendocino, ORG.A is looking at a pilot Outlook POC that will provide objects that expand the standard Outlook objects like tasks, meeting requests, email, and contacts to add information fields and features. For example, Microsoft’s standard calendar entry does not have an entry for holidays & time-outs built in. Even if it were, all it would do is trigger an out-of-office reply. The Mendocino pilot within ORG.A plans to have a new meeting request object that would contain the entry for a holiday and other information managed within the mySAP applications.

The POC would need to have the expanded calendar entry object will allow an entry marked as “holiday” to trigger an approval process in mySAP’s human resource management module automatically. Ideally for ORG.A, this approval engine should be very similar to what ORG.A users get to see in the Ariba Spend management suite – especially Ariba Buyer 8.x. If this is not to be made available by SAP Enterprise Portal, the POC would link the custom workflow engine embedded into the Enterprise Portal to do the job and completely avoid the HCM module completely on the weblosw front, rather have it at the Enterprise Portal layer. This could mean an integration exercise with Flow-Brix or any other human workflow engine. Based on this workflow, the additional contextual information provided by the new objects would need to be integrated with HCM for automation across the Outlook and the mySAP enterprise applications.

Extended Office Integration POC3 (beyond POC1 & POC2): From a POC business case perspective, the aim is to extend the POC around unification into this POC. With Unification, the POC revolved around linking up the BW3.5 & R/3 4.7 pilot for the business users to play around with the Customer Master data from R/3 and the reports from BW to get additional information across to the user with the drag-and-relate-concept. (Since the usefulness of a Unification POC is still being debated within ORG.A business users, the production plans on the POC have been put on hold within ORG.A, instead this saw the resources being diverted to POCs around the Visual Composer to render this functionality on EP). This was the first POC done by ORG.A in this area. Let us refer to this as POC1. Now, lets take a quick detour to understand what POC1 & POC 2 were about.

POC 1 got extended to POC 2, which predominantly saw the integration between Sharepoint server and enterprise portal, with the Sharepoint layer on top of Enterprise Portal. Specific iViews from the POC saw the generation of business packages for publishing in the Portal Content Portfolio. These iViews were called from the Sharepoint server to have ORG.A POC users test out the layer of an existing sharepoint-server based web-application getting extended from the SAP EP layer below.

POC 2 aimed to extend the Original Sharepoint server – EP Integration POC. SAP Enterprise Portal should be viewed as a Java-based portal framework, instead as a product, which is designed to provide a hosting environment for “portlets” called iViews. Simply put, an IView is the SAP Portal equivalent of a SharePoint web-part. The iViews provide business-level views of information in the back-end SAP R/3 system. A number of IViews usually interact on a page, exchanging data to provide the user with a business application. The SAP Portal additionally deals with the concepts of “Pages” and “Roles”. The page hosts hosts IViews, and provides the required layout, personalization and communication back-end for the IViews. A role associates pages with users. Note that a role is not a permission setting, but simply shows or hides the navigation to a particular page depending on the user’s membership in the role.

The ORG.A POC2 was to display SAP Portal iViews within SharePoint to operate in an environment where the SAP Portal is already installed and operating. The POC was designed to solution does not replace the SAP Enterprise Portal and does not replace Sharepoint server. POC 3 is to meant to extend SharePoint as the primary interface extending to Mendocino, which in turn communicates with EP iViews via web parts.

The POC work the ORG.A would want to see Mendocino expose information from mySAP into Office applications in parallel to POC 1 & POC 2. The Customer master data would need to be pulled in from SAP R/3 and the reports corresponding to the customer data would need to be linked up from the enterprise portal extending the POC on Visual Composer.

Now, with POC 3, SAP R/3 needs to provide contextual information in Microsoft Office task panes and build a live-data bridge linking Excel to key mySAP data. Along wth Microsoft Office Word smart documents linking up the SharePoint Portal Server, SharePoint Services, and InfoPath XML forms, the objective of this POC will be a new integrated version of Microsoft’s Information Bridge Framework (IBF), a Web services framework that links Office to back-office applications, to Integrate Microsoft Office with SAP. Mendocino is to allow the use of either Windows 2003 Active Directory or mySAP Enterprise Portal single sign-on functionality. Sounds just awesome.


This blog presents just one an approach an organization can take with SAP NetWeaver in the near future. What came out as the outcome of the discussion was not on talks that hovered around the esoteric and sublime, but the immediate deliverables were nailed with much more conviction in laying down a blueprint with the SAP NetWeaver platform and a road ahead for ESA, the details of which, I will share as an experience with another client in my next blog.

And yes, if you are a smoker, quit it now. Cold turkey. It’s so easy….I have done it so many times before.

image image

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply