In the last blog, we took a peek into the business requirements of a Shop Floor execution system. In this one, we take a peek into carving an ESA roadmap and fitting the SFE into the overall scheme of things. The objective of this blog is not to create the implementation details, rather, it is to provide a way forward to put together the grand scheme of things.
The Solution Vision
The end goal is to create a Composite Application for the Manufacturing division to provide a business solution for the entire Demand-to-make process, that integrates seamlessly with SAP R/3 and SFE, extended to monitoring via black-berries using MI in the future (for QC moved goods), provides reports on exceptions in the supply chain using BI Alerting with BI3.5 that pulls in data from mySAPERP 2004 leading to executive dashboards with Analytics.
Technical Overview of the SFE
The SFE Architecture is an n-layered architecture. The Client layer is the entry layer to SFE. The client can be a Java stand-alone application or a web-based application or the enterprise portal. The next layer is the Web Server layer. This layer enables a web-based client to interact with the SFE engine. This layer is not used with the stand-alone application. Rather the stand-alone uses RMI/IIOP mechanism to connect to the SFE layer. The third layer is the Application Server layer. The rules engine and its related tools and components are embedded into this layer. This could be an IBM WebSphere, an iPlanet or any other application server.
All the features of the application server are utilized extensively by the SFE engine during the execution of a process. The last layer is the Database Server layer. In this layer SFE engine stores all the rules related information and also may optionally host the business data. Alternatively the database layer could be replaced by Enterprise Application Systems (SAP, PeopleSoft, Siebel, BaaN, etc.) layer or added to the existing database layer. Database access with the MS SQL Server 2000 is enabled using the SFEs Data Access component. Currently, the SFE system is deployed on an IBM webspehere server with MSSQL as the database layer.
Deploying the J2EE application on the Web Application Server & front-ending with the Enterprise Portal
Since we are laying down the ESA roadmap for in this environment, the SFE has to be deployed on the WAS 6.40 server to be frontended with an EP6SP12 layer. As the WAS 6.40 renders compliance to deployment of EAR files, the key points become generating the J2EE components, assembling the application and deploying the same onto WAS 6.40. Once the SFE has been deployed onto WAS, the next step is to take the relevant APIs that need form the core methods that will need to be exposed as web services.
With the SFE Applications key functionalities that have been exposed as APIs, we will need to create a layer of stateless session beans on top of the APIs if the SFEs application have Enterprise Beans like session beans or Entity Beans, and as Stateful session beans cannot be exposed as a webservice.(the choses techincal architecture within the organization, however, many choices exist). As the SFE does not have any stateful session beans, one could use this architecture. In case of stateful session beans, wrap them with stateless session beans. Once these beans have been created, one would need to take these stateless session beans and generate web services out of them and publish them onto the local UDDI server that comes bundled along with WAS. (The corporate security policies come in here)
We now have two choices:
a. Call these web services through enterprise portal as JSP/JSPDynpage iViews
b. Call the web services through enterprise portal as webdynpro iViews
The decision is bound by the long-term roadmap that we will be laying down as part of the ESA roadmap. Since there could be a need of exposing key application functionality such as viewing the finished goods moved to QC at random for evaluation via the SFE, one may recommend the web dynrpo route for future integration via Mobile infrastructure as well to provide an interoperable and a device-independent solution. The processing may become interactive in the future. So,Option b makes sense.
The Business Process Adherence Model
Post data transfer, now that we have ported the SFE application onto the SAP NetWeaver Platform, it is ready for immediate usage with Enterprise Portal as the front end. While this goes on, let us now focus on moving this to the next level. For the Business users today, nothing has changed except the front-end, which is now Enterprise Portals. The SFE still gathers data though interfaces offline.
The Composite Application Way forward is to have the SFE embedded as part of the business process Demand to make, of which only the manufacturing execution resides outside of the processes being taken on forward within SAP. The ESA roadmap aims at setting a set of Guided procedures to streamline the supply-chain planning and execution.
So, the base for the ESA roadmap becomes the following seven phases:
Phase 1: Aggregate processes and information
Phase 2: Deploying of the SFE application onto WAS 6.40 with EP6
Phase 3: Turning transactions into web services governed by roles
Phase 4: Creating the Composite Application
Phase 5: Fitting it into the end-to-end process
Phase 6: Move forward with Analytics
Phase 7: Address other key process chains
A Case for XI 3.0
The road-map would include a POC of XI 3.0 predominantly with IDOC and JDBC adapters to have this in place to have an integrated solution for the complete solution. Again, while the POC is on, it is business as usual. The POC can run with canned data. As the need for XI 3.0 gets extended within the business where the need for integration is greater than the SFE-ERP Integration, this would be moved to the Go-Live zone.
The case for an XI POC becomes stronger when the Composite Application would entail the need to have a workflow. Calling of SAP Workflow through XI ccBPM via ABAP configuration to showcase the ccBPM capabilities of triggering a human workflow solution from XI ( which doesnt exist in the SFE case today). And if the system landscape of the customer is dominated by SAP applications, this becomes a good case in point approach with XI 3.0 leading to replacement of other EAI tools. If a human workflow has to be brought in at the Enterprise Portals later, then a 3rd party human workflow engine may need to be configured or an approval engine may need tobe built. The Ad-hoc KM workflow will not work here (one hopes to see it get going in the version 7)
The Blueprint for an xApps with CAF 2.0 on the path to ESA
The Solution Architect view now needs to have the project team break the Business functionally into the following areas:
a. User roles (The business roles that will be addressing various parts of the process)
b. Different User interfaces (Role-specific iViews for different Business Users)
c. Processes (The procedures that the business users will have to guide though)
d. Services (The Operations that need to be carried out)
e. Objects (The raw functionality from ERP & SFE)
f. Underlying systems (SFE & mySAPERP 2004)
The process flow can now be detailed out for the CAF modeling as follows: (a sample process):
With SFE, the key users are the operator, QC, SFE Controller, SFE IT Operator, MRP Controller, so on and so forth. The process steps in the above process chain become the candidates for web services/enterprise services. As this process link of MES, that is outside of SAP, this organization cannot leverage the enterprise services of SAP that will be existing/being built for SAP transactions. This helps a Solution Architect to convince customers to transform as much of their business processes with SAP applications leading to lowering of TCO (read let SAP do the dirty job of creating the enterprise services and the client saves the cost)
As the direction with the Visual Composer is fairly ambitious, the code for the Web Dynpros will be generated by VC as well. That being the case, it makes sense to go the webdynpro route once again. The base is anyways the SAP NetWeaver Developer Studio with the CAF plug-in. And with the framework, as Solution Architects, one can lead the customer towards the path of modeling & designing applications based on patters, instead of coding. And with the SFE fitting into the process chain for a Composite application that addresses demand-to-make, this wholistic view now helps us address the entire supply chain.
The process steps for the QC & the Operator in the diagram above clearly lay down the activities they perform on a day to day basis. This gets pruned from a role and workset perspective. User specific iViews for the SFE through Enterprise portal now enable the SFE to follow a set of guided procedures for these workers to perform their functions in a better way. And now the extension towards Analytics can be thought about.
The need for a Unification server, BI alerting via portals, Adobe forms, AII and Mobile Infrastructure – all may find a place here in this supply chain solution. The point is NOT to make a technical solution out of this one, rather, the Solution Architect needs to figure out what fits in and when. The objective has to be business driven. The SFE has to provide the existing functionality with more ease of use. Speed is the essence.
The above is only a sneak-peek into the role a Solution Architect ought to perform. Again, there could be a better approach. In the last blog, we covered the business process. In this one, we look a high-level look at the technicals and the road-map. The TCO and benefits are there everywhere for all to see. The challenge today lies in crafting a solution. There are so many facets and depth of matter that a Solution Architect needs to get into, its difficult to get it all in one blog. Thanks for reading this & I look forward to your comments and suggestion. Obviously, there is no end to the depth a Solution Architect could get into, it is more a choice that is available. The same Solution can be extended to other process cycles – we will take them one by one. Watch this space for more on the Solutioning front.