Building the Bridge – Part IV
In Building the Bridge – Part III, I talked about selecting business processes off of the IT menu with IT Scenario Variants. Here, in the final installment, we will see how that helps out the IT department who has to implement SAP NetWeaver
Part IV Usage Types
Now that an IT Scenario Variant has been selected, we are getting very close to what the IT personnel actually need to install. In other words, at some point IT Scenarios actually require software on hosts. This used to be components, but as I mentioned in Part III, the component view of SAP NetWeaver is being replaced. Components are a historical term that imply a monolithic structure of a system and are not entirely compatible with the actual integrated platform of SAP NetWeaver. In fact key capabilities, as seen in The Refrigerator view, are the most understandable groupings of technologies that most resembles the former product/component view. Components, however, do not really describe what a service architecture can provide. The ultimate service architecture throughout a landscape, for example, can be a set of process engines that are waiting around to be put to use (kind of like a food court at a mall). In this case, the definition of system is very blurry and intentionally abstract does it really matter what systems the engines reside on if the processes are eventually combined (and abstracted) into a higher level composite application?
Or (back to food), you get your entrée from the Chinese restaurant in the food court and dessert at the cookie place at the end its still a meal. Lets say the meal, then, is cashew chicken and a chocolate chip cookie. The cookie and the chicken are services ordered off of the menu of service providers. The overall business process is the meal lunch eaten by a user. The lunch cashew chicken and a chocolate chip cookie is a composite business process made up of individual services ordered and combined to make the process. The different vendors in the food court provide menus according to the demands of the users.
But something has to be installed somewhere.
Enter Usage Types. A Usage Type represents a logical view of the SAP NetWeaver Technology platform. A Usage Type determines the role which a SAP NetWeaver system plays in a landscape and the intended purpose of a system. Usage Types are realized by installing and configuring a collection of software components. Usage Types may also be built on and/or leverage other Usage Types.
Or, lets visit our food court again. The vendors in the food court all use the same ingredients and hardware (ovens, grills, etc.). It is the way they combine the ingredients that create unique dishes. Dough can be used to make both cookies and pizza.
Usage Types are where there is the biggest relationship to the former components. But, since Usage Types are a pre-determined and configured collection of software components, they encompass more than components provided by themselves. The relationship between components and Usage Types is illustrated in the following table:
|Former component name||SAP NetWeaver 2004s Usage Type||Usage Type abbreviation||Required Stacks|
|BW + Web AS||BI Java Componets||BI Java||Java|
|Web AS + certain Java comp.||Development Infrastructure||DI||Java|
|Web AS||Mobile Infrastructure||MI||ABAP+Java|
|XI + Web AS||Process Integration (XI)||PI||ABAP+Java|
|Web AS||Application Server ABAP||AS ABAP||ABAP|
|Web AS||Application Server Java||AS Java||Java|
Some technical rules about Usage Types:
- A usage type can share a system with other usage types
- A usage type can be run separately in different systems (so interfaces between usage types must work locally as well as remotely)
- It is recommended that all usage types belonging to one system or one IT Scenario to be on the same SP-Stack level
- By definition, a usage type is not an installable unit (rather a collection and configuration of installable software units)
Usage Types allow developers to treat SAP NetWeaver as a service platform when developing an application, for example, they just have to require that Usage Type BI is present. Once they require this, they can send the applications processes through BI and are able to count on predictable results (kind of like all McDonalds having the same menu everywhere a BigMac here is the same as a BigMac there). It abstracts technical system information from application development.
Now we can finally tie it all together since it is application developers who create IT Scenario Variants. Once a scenario variant is chosen, the IT department can look into the guides to find out what Usage Types are necessary to fulfill the order.
Both the relationship between IT Scenarios and software components, as well as IT Scenarios and Usage Types, is many-to-many. IT scenarios may span several Usage Types which each may reside on different systems. However, by relating the underlying software components (and configuration) to Usage Types, we ensure that the correct technologies are chosen when implementing IT Scenarios.
The following diagram gives a simplified overview of how the new concepts fit together in the landscape.
Now, the bridge is complete.