SAP-Centric Draft Target Architecture: Washington State Shared Central Services (Ofm, Ga, Dop, Ost)
SAP-Centric Draft Target Architecture: Washington State Shared Central Services (Ofm, Ga, Dop, Ost)
June 2008
How could SAP modules be used to implement the key patterns in the target architecture?
Mandatory and optional Becoming an Internal ASP Supporting different sized agencies Broker for standardized data Migration from the 950 byte record Reporting from a near real-time data warehouse UI Options
Architectural Evaluation
Human Scale Loose Coupling Reuse Gradual Migration
How ERP?
Sep 2008
SOA
Goal
Get the benefits of SAPs integrated ERP functionality while retaining as many of the benefits of an SOA style architecture as possible.
Human Scale Applications Loose Coupling Reuse Gradual Migration
9
Functional Focus
We focused on the following functions as candidates for implementation in SAP:
GL AR Cost Allocation Time Reporting Labor Distribution Procurement
Rough Coverage
10
R/3
Client / Server ABAP/4
PM HR IS WF
AM
QM
PS
11
Purchasing
APPurchasing
Inventory
MM - Materials Management
13
Purchasing
Inventory
MM - Materials Management
16
Approaches Considered
Single Instance Implementation
Implement all SAP modules in the same instance of SAP. The standard approach.
18
Message Bus
19
20
Message Bus
ERP Instance
22
23
GL
AR
AP
FA
CO Controlling
Sales SAP Data Distribution SAP Internal Services Pricing ARSales & Dist BI/BW
MM - Materials Management
Purchasing
APPurchasing
Inventory
HR Human Resources
Org. Management Personnel Admin Recruitment Recruitment Development Management Personnel Time Payroll Training & Events
26
27
28
Partitioning by Agency
AR Module Agency 1 - AR
Agency 2 - AR
Agency 3 - AR
Agency 4 - AR
29
Partitioning by Agency
Each SAP module has some way of partitioning data and functionality in a module so that each agency appears to have its own logical application. For example:
Financials Data can be partitioned by Company Code Purchasing Data can be partitioned by Purchasing Group
Each virtual application can be configured independently using a configuration templates. Some aspects of the data and functionality are easier if they are enterprise-wide and are not easily customizable by agency, e.g., the COA. To bring on a new agency to an optional application, e.g. from setup to production, might typically take about three months.
30
32
With this architecture you can offer some medium level options:
ASP systems for medium agencies or even large agencies who have modest needs in an area (such as inventory) Government source some of the systems to allow local implementation with standard interfaces
33
Agency 2 - AR
Agency 4 - AR
34
35
36
37
38
39
40
The HR Mapping
AFRS Agency Code Agency Code + Program Index Agency Code + Master Index Agency + Fund + Approp. Index Agency + Org Index GL Code + Sub Object GL Code + Major Grp. / Source Agency + Allocation Code SAP Business Area Functional Area Cost Object Fund Cost Center GL Account GL Account Special Ledger Filed Allocation
41
The HR Mapping
SAP fields are too small to include the full codes plus the agency code to ensure uniqueness for optional codes. Using index codes to overcome this space limitation makes reporting difficult.
42
43
44
SAPs BI Module
The SAP Business Intelligence Module is a series of dimensional data marts populated by a ETL mechanism (Extract, Transform, Load). For each sub module implemented there will be a hypercube set up for standard and ad hoc reporting. You can add your own hypercubes and populate them with data from external applications.
46
Architectural Options
You could create hypercubes in SAP for all your custom applications reporting needs. This would effectively mean that SAP would be your data warehouse vendor. You publish out a subset of the SAP data and into a custom central services data warehouse.
47
48
SOA infrastructure
Party Identity Party Master Data Nomenclature Business Rules WorkFlow IVRS
Shared Services
Each instance of SAP has its own set of services including
Correspondence Management Document Management Authentication and Authorization
These were designed for the internal use of the SAP modules and are tightly integrated with those modules. They are not intended for use by external applications.
51
PromoteReuse IncrementalMigration
52
Human Scale
SAP is a large complicated app. The more modules, the larger and more complex it becomes. Upgrades to SAP are applied to the entire instance. Customizations to SAP functionality need to have careful impact analysis and testing protocols.
53
Loose Coupling
Use of the iDoc-based publish and subscribe interfaces allows SAP as a whole to interact to non-SAP applications through the bus in a loosely coupled way. The individual SAP modules are tightly coupled. It is possible to switch off parts of SAP functionality and replace it with iDoc based interfaces to an alternative application.
54
Shared Services
SAP services can only be practically shared within an instance of SAP. They are not designed for use by non-SAP applications. You still need to develop a parallel set of shared services for your non-SAP applications. SAP functionality is hard to invoke as a service. It might be possible to custom code a web service to access SAP data but in practice this will not be easy.
55
Gradual Migration
You can switch on SAP modules one at a time. For optional applications, e.g. AR, you can migrate agencies one at a time. Depending on what has to change in the COA you could potentially run SAP and AFRS concurrently, bringing on agencies one at time. If the COA changes, a big bang implementation becomes more likely.
56
Leveraging HRMS
HRMS interfaces only to the SAP GL system. Currently this is through an iDoc interface. If you installed SAP financials it would interface directly to the GL data base. Typically organizations retain a separate instance of SAP for HR for security reasons. Functionally HR will be the same. You could potentially leverage some of the SAP experience in DOP, and user experience in the agencies HR areas.
57
58