0% found this document useful (0 votes)
46 views58 pages

SAP-Centric Draft Target Architecture: Washington State Shared Central Services (Ofm, Ga, Dop, Ost)

The document discusses a proposed SAP-centric target architecture for central services shared by Washington State agencies. Key points include: - Implementing core SAP modules like financials, sales, procurement in a single SAP instance to take advantage of integration while retaining some service-oriented architecture principles. - Potentially running HR in a separate SAP instance for security and data isolation, interfacing with the main instance. - Configuring SAP to allow each agency to have logical "virtual applications" partitioned by organization while standardizing common data. - Transitioning in phases from current architectures to the target architecture over time.
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
46 views58 pages

SAP-Centric Draft Target Architecture: Washington State Shared Central Services (Ofm, Ga, Dop, Ost)

The document discusses a proposed SAP-centric target architecture for central services shared by Washington State agencies. Key points include: - Implementing core SAP modules like financials, sales, procurement in a single SAP instance to take advantage of integration while retaining some service-oriented architecture principles. - Potentially running HR in a separate SAP instance for security and data isolation, interfacing with the main instance. - Configuring SAP to allow each agency to have logical "virtual applications" partitioned by organization while standardizing common data. - Transitioning in phases from current architectures to the target architecture over time.
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 58

SAP-Centric Draft Target Architecture

Washington State Shared Central Services (OFM, GA, DOP, OST)

June 2008

What Well Cover Today


Context - Where we are in the application architecture design process. What is the SAP-Centric Application Architecture?
Scope of functionality considered for SAP Our design process

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

Review of the SAP-centric draft architecture diagram Questions

Process for Designing an Architecture


Design Alternate Target Architectures

Roadmap Enterprise Architecture Project Context

How ERP?

Sep 2008

SOA Style Target Architecture

Build, Rent or Buy


Each application on the SOA target Architecture is a logical partitioning of business functionality, communicating through messages over the bus. In theory any one of them could be
Built in-house Purchased as a package (COTS) Rented as a software service (SaaS)

Distributed Update Architecture


Updates are forwarded to a bus Interested apps subscribe, and thereby maintain current information

SOA

Big Database Architecture


Goal is to achieve integration by getting all information in one database / one big integrated application Form based Three tier Client Server

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

Single Instance Implementation


SD MM PP FI CO

R/3
Client / Server ABAP/4
PM HR IS WF

AM

QM

PS

11

The Basic Instance Of SAP


FI Finance GL AR AP FA SD Sales & Distribution Sales SAP Data Distribution SAP Internal Services Pricing ARSales & Dist Project Accounting Internal Orders Profitability Analysis
12

CO Controlling Cost Center

Purchasing

APPurchasing

Inventory

MM - Materials Management

The Basic Instance Of SAP


Any instance of SAP will include the core SAP services these modules. Sub module functionality is switched on during configuration.

13

Candidate ERP Instance Of SAP


FI Finance GL AR AP FA SD Sales & Distribution Sales SAP Data Distribution SAP Internal Services Pricing ARSales & Dist BI/BW APPurchasing Internal Orders Profitability Analysis
14

CO Controlling Cost Center Project Accounting

Purchasing

Inventory

MM - Materials Management

Candidate ERP Instance Of SAP


In this configuration
GL / AR and AP are activated in the financial module Cost Center is required for financial reporting. Project Accounting will be required to support Labor Distribution. The BI/BW warehouse module is implemented although this may not be required if analytical reporting is performed in a custom warehouse.
15

NetWeaver and iDocs


NetWeaver is the architecture on which SAP is developed. It allows SAP to interact with external applications on a publish subscribe basis. iDocs is the XML based message standard.

16

Publish / Subscribe vs. Request / Reply


iDocs use a Publish / Subscribe paradigm to communicate with external applications. In general SAP is not set up to present its functionality as a reusable service invoked using Request/Reply messages.
17

Approaches Considered
Single Instance Implementation
Implement all SAP modules in the same instance of SAP. The standard approach.

Multiple Instance Implementation


Implement each SAP Module in its own instance of SAP.

18

Multiple Instance Model

Message Bus

19

Problems with the multiple instance model


Each instance needs a stub implementation of GL and CO to house the COA. All SAPs shared services are replicated in each instance. Each instances security data would need to be provisioned from a master to present a single sign on view to the user. Adds complexities to the testing environment as each instance needs a Production / QA and Development Box. Adds complexity to the configuration, administration, support and licensing of the product. Some applications are so tightly coupled that it would be impractical to implement them in separate instances, e.g., GL and Controller. There are better approaches to swapping out a module if that become necessary.

20

Problems with the multiple instance model


In summary SAP was not designed for implementation in this way. Wrapping each instance only gives the illusion of decoupling. In practice SAP would still be a single, tightly coupled application.
21

The Exception - HRMS


HRMS Instance

Message Bus

ERP Instance
22

The Exception - HRMS


Often runs in a separate instance for security reasons so the data can be isolated at the server and data base level. Other than GL it has few interfaces to other SAP modules. DOPs current HRMS implementation already follows the multiple instance pattern.
Interface to GL (AFRS) using GAP interfaces. Stub version of GL to hold the COA.

23

Candidate HR Instance Of SAP


FI Finance SD Sales & Distribution

GL

AR

AP

FA

CO Controlling

Sales SAP Data Distribution SAP Internal Services Pricing ARSales & Dist BI/BW
MM - Materials Management

Cost Center Project Accounting Internal Orders Profitability Analysis

Purchasing

APPurchasing

Inventory

HR Human Resources
Org. Management Personnel Admin Recruitment Recruitment Development Management Personnel Time Payroll Training & Events

Candidate HR Instance Of SAP


In this configuration
The HR module is added the basic instance. With sufficient functions activated to run payroll, time reporting and recruiting. Partial implementations of GL and the controlling modules are required to hold the COA data structures for the GL interface, and project work breakdown structures for time reporting. Labor distribution would be performed in the ERP instance. Interaction between the instances would be performed using iDoc messages via the bus. The BI/BW warehouse module is implemented although this may not be required if analytical reporting is performed in a custom warehouse.
25

Target Architecture Patterns


Mandatory and Optional Becoming an internal ASP Supporting different sized agencies Broker for standardizable data Where is the 950 byte record? Reporting from a near real-time dimensional model UI options

26

Mandatory and Optional


This is one of the key decisions in this architecture, and it comes in three flavors:
Whichapplicationsaremandatory? Whatpartsofthecodingblockare mandatory? Whichidentifiersandcodesmustbe consistent?

27

Color coding we use on the Target Architecture

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

Becoming an Internal ASP


ASP (Application Service Provider) is a business model for companies like Salesforce.com where they host applications on a subscription model. The central services group should conceive of some of their applications as being shared in the ASP model.
31

Becoming an Internal ASP


In general SAP is not set up to be deployed as ASP software. SAP (and other ERP packages) has the ability to present custom implementations to different clients (agencies). This is part of being an ASP. SAP is not set up to monitor and bill users for use of the software on a per use basis. OFM would have to:
Change and simplify their billing model (e.g., per seat) Customize SAP to add this billing capability.

32

Supporting Different Sized Agencies


Currently you have two models:
Large agencies have their own systems and ship you the results for consolidated reporting (a few in very summarized fashion) Small agencies have outsourced to us the whole function (including data entry)

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

Supporting Different Sized Agencies


A typical implementation of a new company on an existing instance of, say, the AR module is three months. This would be an install that requires no code customization. There will be a limit to how basic an implementation can be. In SAP this is called a baseline configuration.
AR Module Agency 1 - AR Configuration Template1 (Medium)

Agency 2 - AR

Agency 3 - AR Configuration Template 2 (Small)

Agency 4 - AR

34

Broker for Standardizable Data


There are some sets of data for which you might not be the system of record, but the State might be implicitly expecting you to be a steward for at least the standard, and/or knowing where the data is:
Forecast data GIS

35

Broker for Standardizable Data


SAP is currently not a likely candidate for this type of operational data. However the data warehouse and business reporting architecture will affect this.

36

The 950 byte record?

37

Sketch first stage transition

38

Sketch end state

39

Mapping the existing CoA to SAP


The gradual migration of agency systems using this approach requires a mapping.

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

Agency + Proj + Sub Proj + Phase Special Ledger - Project

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

Possible SAP GL Configurations


Single COA Solution
These would have to be mapped to unique SAP 10 digit account numbers. To accommodate the agency-specific codes, each agency would have to map to a separate block of codes. SAP groups would then have to be set up to combine codes under a common parent Sub Objects under Objects and so on to allow rollup reporting to the various levels.

43

Possible SAP GL Configurations


Multiple COA Solution
Each agency has its own COA. Essentially its own GL. The consistency of the state-mandated coding levels would be established procedurally. Financial records would be consolidated in
The BI/BW (SAP Data Warehouse) reporting module, and state-wide financial reporting is done from there. Use the Consolidation Module to provide statewide financial reports.

Neither of these is a trivial implementation option.

44

Reporting from a near real-time dimensional model


By feeding the data warehouse from the bus you can have near real-time reporting in the warehouse. The dimensional design allows non technical users make complex analytical queries across multiple data marts. This would be the enterprise view of data from all the central service agencies applications.
45

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

User Interface Options


UIs will continue to be tied to applications. In the longer term UIs will be built as composites from many applications.

48

User Interface Options


SAPs functionality is accessed primarily through its application screens. SAP was not really designed with the type of request reply services that would be usable in a composite UI. Where SAP has a web based user interface those interfaces could potentially be included in an enterprise portal.
49

The Shared Services


Security
Authentication Authorization

SOA infrastructure
Party Identity Party Master Data Nomenclature Business Rules WorkFlow IVRS

Correspondence and Document Management Composite Applications


50

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

Our Guiding Principles re: Architectural Design


HumanScale LooseCoupling

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

SAP Centric Target Architecture

58

You might also like