bp alm arch design v6

8/11/2019 BP ALM Arch Design V6

1/18

Application Lifecycle ManagementArchitecture Design in SAP Solution Manager


2/18

2012 SAP AG. All rights reserved.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP

BusinessObjects Explorer, StreamWork, SAP HANA, and other SAP

products and services mentioned herein as well as their respective

logos are trademarks or registered trademarks of SAP AG in Germanyand other countries.

Business Objects and the Business Objects logo, BusinessObjects,

Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and

other Business Objects products and services mentioned herein as

well as their respective logos are trademarks or registered trademarks

of Business Objects Software Ltd. Business Objects is an SAP

company.

Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL

Anywhere, and other Sybase products and services mentioned herein

as well as their respective logos are trademarks or registered

trademarks of Sybase Inc. Sybase is an SAP company.

Crossgate, m@gic EDDY, B2B 360, and B2B 360 Services are

registered trademarks of Crossgate AG in Germany and other

countries. Crossgate is an SAP company.

All other product and service names mentioned are the trademarks of

their respective companies. Data contained in this document serves

informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materialsare provided by SAP AG and its affiliated companies ("SAP Group")

for informational purposes only, without representation or warranty of

any kind, and SAP Group shall not be liable for errors or omissions

with respect to the materials. The only warranties for SAP Group

products and services are those that are set forth in the express

warranty statements accompanying such products and services, if

any. Nothing herein should be construed as constituting an additional

warranty.

www.sap.com

TABLE OF CONTENTS

1.0 Introduction ................................................................................................................................................ 3

2.0 Business Processes .................................................................................................................................. 4

2.1 Definitions of Business Scenario, Process and Step .................................................................................. 4

2.2 Business Process Design ............................................................................................................................ 42.2.1 Definition of end-to-end processes ........................................................................................................... 42.2.2 Definition of end-to-end business scenarios based on modular business processes .............................. 5

2.3 Business process variants ........................................................................................................................... 72.3.1 Variants on scenario, process and process step level....................................................................... 7

2.1.2 Use of Shortcuts in ALM ........................................................................................................................ 92.3 Business Process Assignments ................................................................................................................ 103.0 Usages ...................................................................................................................................................... 12

3.1 One project as single source of truth .................................................................................................... 12

3.2 Solution as single source of truth ......................................................................................................... 13

3.3 Template as single source of truth ........................................................................................................ 15

4.0 Sources for business process information .......................................................................................... 17

4.1 Content migration by upload .................................................................................................................. 174.2 Reverse Business Process Documentation ......................................................................................... 17


3/18

ALM Architecture Design

3

1.0 Introduction

SAP Solution Manager is positioned as an Application Management Platform for SAP centric solutions.

The major focus of SAP Solution Manager is on solution operation and optimization. It also functions as acollaborative infrastructure between the customer and SAP. This includes remote support as well ascollaborative scenarios between the customer operation and the SAP service organizations.

Apart from solution operation, SAP Solution Manager also provides an infrastructure platform for overallapplication management: from requirement/change request management, through design, build, test, deploy,and operation/optimization, with a major focus on change control.

Depending on the scope of the SAP Solution Manager processes being implemented and depending on thestructure of the company, the SAP Solution Manager can be an easy setup or an implementation project byitself.

The following content describes best practice cases for solution documentation in the SAP Solution ManagerApplication Lifecycle Management (ALM). This includes references to test capabilities, Business ProcessMonitoring, and Change Request Management (ChaRM).


4/18


4

2.0 Business Processes

Proper business process design and appropriate grouping into scenarios are key decisions when startingALM in SAP Solution Manager. When choosing the wrong design, reusability is impaired. This affects thefuture use of content for purposes like Test Management or Business Process Monitoring.Business processes are organized in business scenarios.

2.1 Defini t ions o f Bu siness Scenario, Process and StepSAP Solution Manager allows designing business processes within three levels. Below you will find thedefinition of how the levels shall be modelled in order to guarantee the best integration within SAP SolutionManager ALM capabilities.

Abusiness process stepis most commonly related to a transaction, a background job, a web UI or

similar system activities. Sometimes it makes sense to also document some activities within the

business process flow. The business process step is the most granular entity in business process

definition and is assigned to a system on which it is executed.

Abusiness processis a collection of business process steps, grouped according to a certain

criteria like business content or SAP modules combined to process chains.

A business scenario is a collection of business processes to be executed one by one resulting in

the execution of an operational procedure. Scenarios can be organized by business unit, SAP

module or other kinds of grouping (e.g. template-related).

2.2 Busin ess Process Design

In principle there are many ways on how business processes can be represented in SAP Solution Manager.However, the best ALM integration can be achieved by the end-to-end design of business processes.Therefore two ways can be chosen depending on how the organization and responsibilities are structuredand which requirements have been raised to business process handling in ALM.

However both presented design possibilities show the common disadvantage of general document repetitionon several occurrences. This has to be controlled manually by governance.

2.2.1 Definit ion o f end -to-end proc esses

In designing end-to-end business processes, you have to answer the question what end-to-end means foryour business unit(s). This difficulty shows up at the start of business process documentation, and is mostlyconnected to organizational aspects (responsibility, user access, organization of monitoring etc.). However,this is the most reusable business process modelfor documentation purposes, test capabilities, interfacedocumentation and Business Process Monitoring (see figure 2-1).

Figure 2-1: End-to-End Oriented Business Process Design


5/18


5

By using this model you arrange business process steps across different SAP Modules and products onwhich they are executed (see figure 2-2).It is recommended to use pref ixes in the business process hierarchylike 4.1 Detection StorageLocation to highlight the sequence of their execution. Beside the graphical representation this will guaranteethe direct reuse in test sequences for integration test.

It is recommended to use structure at t ributesor custom att r ibutes for documentswhen organizing thebusiness process documentation in relation to SAP modules, organization units or priorities (especially fortesting). This assignment will allow you to filter on the end-to-end structures and display the relevant content.The assigned attributes also help to report on these business processes by document searches.

Figure 2-2: Attribute assignment

Addressed customers:Customers focusing on project and test management especially for regression and integration testing.However, using this design all other ALM aspects can be covered easily as well. Please consider the

advantages and disadvantages of this design.

Advantages:This design allows clear visibility of end-to-end processesacross all applications and systems. It alsoprovides capabilities for very quick and uncomplicated creation of test plans which include the end-to-endbusiness process view without big corrections in the process flow.

Disadvantage- The Business process variants have to be represented by copied business processes. To avoid this

disadvantage you can alternatively model business process variants as shown in figure 2-4 forbusiness scenarios.

2.2.2 Defini t ion of end -to-end bu siness scenarios b ased on modu lar business pr ocesses

For all customers who organize their solution documentation along SAP modules (business processresponsibility, maintenance activities, projects) another business process model can be recommended. Inthis model you can combine modular built business processes (process flow within one SAP Module) to anend-to-end business scenario (see figure 2-3).

Figure 2-3: End to End Business Scenario


6/18


6

To do so, use the Graphic tab at scenario level to document the order in which the business processes are tobe executed. Alternatively the Business Process Blueprinting tool can be used to detailed represent the end-to-end flow within the business scenario (see figure 2-5).

All used business process variants are included into the same business scenario and represent the regionalor business unit specifics. By using structure attributes you can make visible which processes represent an

end to end scenario variant.

Figure 2-4 is showing the maximal number of business processes to cover the most important Order to Cashvariants collected under one business scenario. By using the attribute Scenario Variantyou can control thevisibility of the Order to Cash variants.

Figure 2-4: Business Scenario Variants

As shown in figure 2-5 the green arrowsconnect four business process steps from several modular businessprocesses into a business process chain. In this chain some business process steps are not involved (part ofblue line connectedprocesses). However, if you look at the modular process they play an important role tobuild an information flow within a modular business process. By using the attribute end-to-end test relevant

you can control the visibility of the end-to-end relevant business process steps in test environment.

Figure 2-5: Business Scenario Test Execution

Further recommended attributes could be:- Regional variants- Business units- SAP Module- Priority

It is recommended to use pref ixes in the business process hierarchyto highlight the sequence of their

execution. Beside the graphical representation this will guaranty the direct reuse in test sequences forintegration test.For more information about this business process design in ALM concept please refer to chapter 2.11.

Modular Process Flow

End-to-End Process Flow


7/18


7

Addressed customers:Customers organized according to SAP modules focusing on document management, project documentationand test management for regression/integration testing and module test. Please consider the advantagesand disadvantages of this design.

Advantages:

This design allows clear visibility of end-to-end scenariosacross all applications and systems based onmodular designed business processes. It provides also capabilities for the quick and uncomplicated creationof test plans which include the end-to-end scenario view based on test relevance attributes.Scenario variants can be represented within the same scenario and differentiated by attributes.

Disadvantages- Maintenance of attributes might cause high efforts.

2.3 Busin ess proc ess variants

Because of different organizational units, master data or locations the flow of business process can differ orhave different ways to execute steps/transactions within the same business process flow. The followingchapter describes how SAP Solution Manager can help to reflect all necessary and required variations.

2.3.1 Variants on scenario, process and process step levelIn general there are three main possibilities how to represent variants in SAP Solution Manager:

- Repl icat ion m ethod: for this methode.g. the business process will berepeated in the business processhierarchy as a copy and changed onthe copied occurrence (Figure 2-6).This method is meaningful for differentbusiness process variants running ondifferent system landscapes. Duringthe copy creation all already existing

technical assignments will be copiedinto the occurrence while thedocuments shall be referenced (thisdecision will be made on copy optionpopup during the copy of the businessprocess). This will help to keep allchanges in already existing documentation up to date. Beside the advantages to decouple from theorigin process, the method brings some difficulties in document handling. One of the biggest appearsduring the ALM cycle while new documents will be added to the origin business process or to itscopies. In case the document describes the relevant occurrence behaviour, no further activities arenecessary. However once a new document has to appear on all occurrences the assignments haveto be done manually. In case the addition was done to the origin business process or its steps youcan use Compare & Adjust functionality to populate it to all copied business processes. However,

due to the fact that the originality of a business process is not clearly visible, the activity has to bemost likely outsourced to organizational governance.

Please be informed that the use of so called Short Cutsto avoid the replication is not part of thebest practice. It leads to complex cross refferences and missing granularity which is needed for testmanagement (especially Business Process Change Analyzer).Once the Short Custs are used it isrecommended to disbandthem with the option Refer to Docuents.

This method can be adapted to scenario or process level.

Figure 2-6: Replication method


8/18


8

- Accum ulat ion method:especially for consolidatedsystem landscapes (one centralclient for all subsidiaries andcountries) the accumulation is a

good alternative. In this methodthe business process variantsare cumulated as much aspossible and include all variantsof steps within one process(Figure 2-7). Decentralizedsystem landscapes can alsoprofit from this method byassigning the same transactioncode at the business processstep level multiple times but with

different logical component or byrepeating the step and representing thus

the variance information about how the flow is executed.

There can be some disadvantages especially when a separation of those processes is required dueto organizational needs.

This method can be adapted to scenario or process level.

- Executable variants: as ofSupport Package 06 thepossibility of documentingexecutable variants wasintroduced (Figure 2-8). It allows

creating as many executablevariants for a transaction asrequired. This new functionalitysimplifies the representation ofthe cumulated businessprocesses. The difference is thatthe various ways of executing atransaction can be nowassigned to one business process stepwithout the necessity to repeat the step several times in the process flow. All executable variants aresharing the same business process-, configuration- and development documentation. This simplifiesthe documentation activities as all relevant transactional variants relevant for a business process arecumulated at one place. The difference is made in their relevancy in test management. For every

executable variant it is possible to create TBOM information (please refer to Test Management bestpractice document) and assign it as test object to test case description(s). This fact allows detectingvery precise results from Business Process Change Analyzer.

As described above the choice of the method is strongly connected to the system landscape situation. Thereplication and accumulation method can be used to reflect different scenario or process variants while thelast possibility is restricted just to transaction assignments at step level.

Figure 2-8: Executable variants

Figure 2-7 Accumulation method


9/18


9

2.1.2 Use of Shortcuts in ALMThe idea of shortcuts is to prevent repetitions of the same entities like business process or steps which areused several times in different process or scenario contexts (see Figure 2-9: Short cuts). However this leadsto some disadvantages:

- the business process/step represents the same variant in all its occurrenceso The same transaction variantso The same documentation and technical assignments (specifications, developments, IMG

and test cases)o The same TBOM informationo No possibility to assign additional occurrence specific information

- Restricted filterability within the project (SOLAR0X) and reporting transaction SOLAR_EVAL- Very restricted re-usability in other projects- Increased response time while creating test plans

Due to these restrictions, the usage of shortcuts can be justrecommended for the here described use case1: One Project as single

source of truth.

However, the functionality of shortcuts can be used for building initiallythe business process hierarchy for solution documentation or testmanagement purposes. Therefore the business processes can becopied from one scenario into another one as shortcut. Once the originsare basically documented the shortcuts shall be disbanded especiallywhen the business process hierarchy will be used for best practice usecases 2-4. Figure 2-9: Shortcut


10/18


10

2.3 Business Process Assignm entsTo document business processes in SAP Solution Manager you can combine business process flow withdescriptive documents and technical assignments. Please find here a list of possible objects which can helpto describe business processes more detailed:

Documentation: on the project documentation tab you mostly assign business process descriptionsor design documents like functional specifications or business process flow documents.

Transactions: the assignment of transaction information to the business process steps determines

which transaction(s) will be used to perform a certain business process step in the managed system.

This information is usually defined during the blueprint stage, and is reused for testing, business

process monitoring, business process change analysis and other functions.

TBOMs. Are directly linked to transactions for which they were created and are used to detect the

test scope based on Business Process Change Analyzer results.

Configuration Objects: all objects assigned to the configuration tab of a business process step which

are necessary to make the step runnable in the business process context. Additional documents

describing the purpose can be also assigned here.

Development Objects: all custom code objects like reports, user exits or BAdIs are documented asan assignment ofthe developed object tothe business process/step for which the custom code was

created. Additionally, technical documentation for the modifications and extensions can be assigned

and connected to the development object directly.

Test Case Descriptions: The testing descriptions fora business process step are assigned to

appropriate structures (using the test object results in a transaction assigned to the business process

step). During the creation of a test plan, thetest case descriptionscan be selected and brought into

the test scope as a test case (together with assigned transactions). For integration tests which

include several steps or even several processes the assigned test case descriptions can be re-used

within a test sequence to define tests of a process flow or an end-to-end scenario

Training Materials: The training documents, which describe how a transaction is to be used by end

users in the context of the business process, can be assigned to the business process step on thetraining tab. These documents can be used to create learning maps and distribute them to end user

groups.

End User Groups: To document which business process step is used by which group, predefined

end user groups can be assigned. This assignment can be used as a filtering criterion for learning

map creation.

Example for possible assignments

There are several important rules for documenting business processes. By following these rules, you enablethe integration between different functionalities in SAP Solution Manager (Testing, BPCA, Business Processand Interface Monitoring and others).

The lower the level of the information, the better. This means that the more granular a document is, the

better it is suited for reuse.

Use of a common final status value like Finishedfor all document types (documents). As a status

schema can be assigned to one or different document types, it is recommended that all status

schemata end with the same common final status value.

Reuse of documents by links. In order to decrease the number of documents, you can link already

existing documents to different business process steps (basic documentation). Additional documents

describing the differences can be assigned to the occurrence selectively.

Documentation of business processes by technical objects. It is recommended to document business

processes by focussing on technical object assignments (IMG, Reports, Authorization Roles and so on)

instead of descriptive documents.


11/18


11

Business Process Step Example: Create purchasing scheduling agreement(transaction ME31L)

General Documentation Tab: contains documents describing the design of transaction ME31L(incase template management was used, functional specification oradditional documentation)

Project Doc umentat ion Tab: project related documentation for ME31LTransaction Tab: assigned transaction ME31L, their variants and relevant TBOMsConf igurat ion Tab: document describing the configuration needed for transaction

ME31L(Configuration objects and descriptions, AuthorizationRoles)

Development Tab: All developments needed to run the transaction ME31L(Technicalspecifications, development forms)

Test Case Tab: Test case descriptions. All types of functional tests can berepresented by different document types. Additionally, test datadocuments can be assigned at business process level.

Training Materials: All kinds of training documents which will be made available to endusers (simulations, presentations)

The following table gives a proposal which document types might be required to document businessprocesses. It highlights also the place where the documentation should be assigned.

Figure 2-10: Document types

The document types mentioned above are examples. Different document types can be created to suitdifferent requirements.


12/18


13/18


13

o Systems are following different maintenance cycles.You can use several maintenance projects for Change Request Management purposes andrefer them to the central documentation project. The type of this central documentationproject is not relevant.

You can bundle changes to a bigger package, a release. Each release can be managed by a separate

implementation project while the documentation will be performed in the central documentation project.

Business Process Operations

In case business process and interface monitoring is required, relevant business processes (or their parts)can be copied into a solution where the monitoring setup can be specified. Here document assignments liketechnical specification are not relevant and will be not considered.

3.2 Solution as single source of truth

This alternative is most suitable if you have simple system landscape with synchronized maintenance cyclesfor all systems within your landscape. The solution documentation is extended by document versions whichwill be controlled by check out/in procedure between solution and maintenance project. A close integration toChange Request Management and Test Management is possible.

This use case can be proposed to all customers wanting to document their current productive environment.All products collected in this documentation are following the same maintenance cycle. The central storage isa solution connected with a maintenance project. In this maintenance project all planed maintenanceactivities will be documented and reflected in the solution (check out/in). Major releases can be representedby separate implementation/upgrade project(s). All relevant business processes will be selected from thesolution and extended by new content, if required.

Figure 3-2: Solution as single source of truth

Documentation Management:Version management between documents stored in the solution can be easily controlled by businessprocess check out/in mechanism. This means that all business processes which have to be changed in theappropriate maintenance cycle will be made changeable in the dedicated maintenance project. Here alldocuments are ready to be changed and will create a new version. This new version will get visible in thesolution after the maintenance cycle is closed and the business process has been checked in back into thesolution.

At the same time the same business processes can underlie the major release changes. These changes willbe documented in a separate project.

In this project(s) all documents are linked and synchronized between solution and the major release project.However when changing the documents in major release project, the documents will get copied. They create


14/18


14

a new basis for redesign descriptions and have to be merged when the major release project is finished andthe content is handed over to the solution.

Test Management:Test planning and execution can be performed based on a solution, maintenance or major release project.Checking out entire business processes from the solution into the maintenance project guarantees the

possibilities to test the maintenance cycle scope in separate test plans. At the same time the full functionalityrange is available also for major release projects where the new designed business processes and scenarioscan be tested.The solution can be used as a test scope provider, especially for integration or regression tests. Note that there-generation of existing test plans for solution is not supported. That means for each integration orregression test new test plans have to be created.

The integration of Business Process Change Analyzer is based on available TBOMs and is fully supported inproject(s) and the solution. The test scope detection and optimization can be performed based on all ALMcomponents.

Change Request Management:In case Change Request Management is used actively for maintenance, you have two possibilities to

represent it in SAP Solution Manager:

o All systems are following the same maintenance cycle.In this case the solution documentation can be stored centrally in a maintenance project.The same maintenance project shall be activated than for Change Request Management.

o Major release project(s) can activate their own task list collecting all changes and transportrequests separately.

The integration between Change Request Management and Documentation Management is very close in inboth cases.

Business Process Operations:

The operation activities are strongly connected with ALM activities and can be activated based on businessprocesses (or their parts) stored in the central solution. All changes done to these business processes aftermaintenance cycle close or after major release can be directly reflected in the business process andinterface monitoring.


15/18


15

3.3 Template as single source of truth

This alternative is most suitable if you have a central system landscape and roll-out plans. The solutiondocumentation is represented by a template project, roll out and/or major release projects and has a closeintegration to Change Request Management and Test Management.

This use case is based on the template documentation functionality in SAP Solution Manager. In thetemplate project you organize your business processes including assignments in form of so calledtemplates. These templates are the basement for future roll-out projects. Major releases can be representedby separate implementation/upgrade project(s). The business process documentation is taken over fromtemplate projects via scoping of the relevant templates. After a roll -out/major release, new information ofglobal relevance is rolled back into the template project. The solution is exclusively used for operations.Documentation updates after maintenance are directly done in the template project.

Figure 3-3: Template as single source or truth

Documentation Management:

All documents (except project documentation for the template project itself) will be linked directly to all roll-out/release projects. All updates on this documentation will be immediately visible in all projects containingthis document. Once the documentation has to be changed in the roll out/release projects the system createsa copy replacingthe original. It allows changes of the document content in a new version. Those newdocuments can be handled as additional roll out documentation. In case this new documentation is of globalrelevance, it should be synchronized back to the template project.

As there is a need to test new and unchanged functionality in parallel, for the test case descriptions a

different behaviour is designed. In case a template provides test case documents, a change in rollout/release project creates a new test case document in additionto the origin. The remaining origins are thenused for regression/integration testing.

Test Management:

Test activities can be planned and performed either based on template project or the roll out/releaseprojects. In addition to the standard capabilities, a specific template test plan can be predefined. It includestest packages, test sequences and tester assignments. To organize roll-out test activities, this template testplan can be used as a master copy for roll out/release projects. This accelerates the test preparationactivities.


16/18


16

Change Request Management:

Maintenance:The maintenance project provides the functionality to create an urgent and normal correction. Themaintenance projects can be created separately, as shown in the picture 3-3, beside the template project.Here all urgent and normal corrections are managed by the maintenance project, while the documentation

adjustments are directly performed in the template project.

Roll out/release:Change Request Management can be used for all roll out/release projects controlling transportation ofchanges trough the landscape. This control will be done by the project specific task list and phase switch.

Business Process Operations:

For business process and interface monitoring you can copy the monitoring or monitoring context relevantbusiness processes or steps from the template project to a solution. Depending on your organizational needsyou can build the monitoring relevant processes into one or several solutions. The copy of these relevantbusiness process/steps and interfaces only contains structure nodes and transactional assignments. This isthe foundation for business process and interfaces monitoring and will not consider other assignments like

documents, IMG objects or developments. Nevertheless after every major release, compare and adjustshould be performed between the template project and all solutions to guarantee the correctness ofmonitored objects.


17/18


17

4.0 Sources for business process informationThere are several ways how to get content for business processes into SAP Solution Manager for productiveuse. For all the customers interested in solution implementation the documentation of business processeswill be part of the implementation project. Thus the business processes will get documented during thisproject.To re-document business processes which are currently used you can use the two options described below.

4.1 Content migration by uploadThe business process upload is offering an interface to migrate business process information into SAPSolution Manager by business scenario, business process and step by e.g. excel or lotus notes upload.

Additionally it is possible to progressively enrich the business process structures by assignments oftransactions, business process documentation, configuration and developments as well as test cases andtraining materials.

Figure 4-1: Migration of already documented business processes

The uploaded content can be afterwards verified by Solution Documentation Assistant based onautomatically chosen statistic transactional checking rules. Using this simplified verification you just check ifthe transaction was executed in a specified time period in selected system. Note that this verification is notproviding statements if the transaction is executed in a specific business process context.

Please consider in this context the chapter about business process design.

Afterwards the fully documented business processes can be used in the ALM concept to document allchanges to them during operations, maintenance or for future projects.

4.2 Reverse Business Process DocumentationThe Reverse Business Process Documentation (RBPD) is a use case of Solution Documentation Assistantand provides a collection of business processes with pre-assigned precise checking roles and transactions.The business processes are ordered modularly in this RBPD content so after the RBPD analysis, the activelyused business processes have to be re-arranged in a separate re-documentation project as described inchapter 2.2 Business Process Design.

Figure 4-2: Business Process use detection by RBPD


18/18


18

In the re-documentation project the business process and transactional information can be additionallydocumented by using the upload interface for:

- Business process documentation- Configuration and development- Test cases

- Training materials

In addition the RBPD analysis also provides a range of not documented, but used transactions. Based onthis you can complete the documentation of business processes by adding additional process steps andassignment of technical objects like transactions.

Afterwards the fully documented business processes can be used in the ALM concept to document allchanges to them during operations, maintenance or for future projects.

bp alm arch design v6

Documents