Skip to Content

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.  Let’s 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, let’s 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 Business Intelligence BI ABAP
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
EP Enterprise Portal EP 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 application’s processes through BI and are able to count on predictable results (kind of like all McDonald’s 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.

image

Now, the bridge is complete.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Scott Campbell
    Matt – I really do appreciate your series, but I’m still not buying why SAP is making the fridge go away. Yes I get that in an SOA world everything can be decomposed into services and that how these services work together is much more important than the sum of monolithic parts. But at the end of the day does it really help anyone understand things to pretend the components aren’t there? If anything I think obscuring them removes valuable context. In fact if “Usage Types are realized by installing and configuring a collection of software components” why can’t we still refer to the components? Aren’t customers smart enough to realize value comes in the way the components work together to realize usage types, variants and ultimately scenarios.

    You mentioned “capabilities, as seen in The Refrigerator view, are the most understandable groupings of technologies that most resembles the former product/component view.” Maybe we just need a new fridge made up of usage types instead of components to have another understandable view. At some point we have to drill into the variants and illustrate things.

    P.S. I guess I’ll have to rent HGttG to get Paul’s comment. Is that a Sam Rockwell reference?

    (0) 
    1. Matt Kangas Post author
      Hi Scott,

      Thanks for your post.  I’ll try to discuss this a little further…

      Why are the components going away?  Well, in a nutshell, they are no longer relevant as they are defined with dated boundaries.  Here, I will try an analogy with a typewriter.  The typewriter evolved first into a dedicated word processor and then again into a software program that (can be) part of an office productivity suite (platform?) of programs.  For example, now you can cut-and-paste between Microsoft Word, Microsoft Excel, Microsoft PowerPoint, etc.  At the end of the day, a document is pumped out, but a typewriter doesn’t nearly describe the capabilities anymore.

      When I was a freshman in college, I wrote all my papers on a typewriter.  By the time I was a senior, I did them all on a Mac.  Do we even talk about typewriters anymore?  Does anyone even still own one?  Has any context been removed? 

      Now, let me try to move this analogy to SAP NetWeaver.  For example, let’s take a look at SAP Business Information Warehouse (SAP BW).  Old timers view SAP BW as an ABAP based system whose frontend is deployed via SAPGUI for Windows.  However, BW has evolved significantly in the last two releases, so much so that the features are greatly expanded and are now based on the J2EE and Portal capabilities as well.  In addition, the new BI features also go beyond the traditional data warehouse with planning engines, information broadcasting, to Knowledge Management and Collaboration, role based business content across SAP NetWeaver and mySAP Business Suite apps, administrator cockpits, alert management, etc.  So, with SAP NetWeaver 2004s, the latest version of the Business Intelligence capabilities the component boundaries are really broken down.  If we take the old component view of it, it requires the old components of SAP BW, SAP EP including KMC (Knowledge Management and Collaboration), ABAP, J2EE, and the BI content add-on.  If all of these software components are mandatory for BI, what component would it be called now? 

      One of the biggest issues that I have with the fridge is that it is focused on management and it is not targeted at those who implement and administer systems.  It does not show how SAP NetWeaver is installed or deployed on physical servers.  This “shortcoming” is, in fact, one of the main theme lines of the blogs that I write.  I came from the implementation world – I was a SAP Basis Consultant for over five years before moving to Product Management – so I am acutely aware of this shortcoming, and I attempt to help out the systems folks who have the management types running to them after a conference with these fantastic new pictures (seems there’s a Dilbert comic strip somewhere in that last sentence).  The implementation view is the IT Scenarios and their variants.  There is, of course, a link between the implementation view and the technical installation/deployment view.

      There are also a couple of problems that quickly come to mind if the “refrigerator” were to represent Usage Types.  For one, this would not be entirely practical as Usage Types are only one of the 3 software unit groupings, the others are engines (such as liveCache, TREX, etc.) and clients (SAPGUI, etc.).  In addition, also consider that Usage Types can rely on other Usage Types – BI Java includes EP and AS-Java.

      Yes, I do believe that customers are smart enough to realize that the “value comes in the way the components work together to realize usage types, variants and ultimately scenarios.”  But, don’t you think that this is mainly a system admin’s view of the world?  This whole “new” view, terminology, etc. is to get business and IT talking the same language.  Then, yes, IT does install software components at the end.

      As far as Zaphod goes, well, I have grown my hair a bit longer than in my picture.  My esteemed colleague now thinks I look a lot like Zaphod (and act like him, too?).  See the picture of him at this site: http://hitchhikers.movies.go.com.

      (0) 
  2. Andy Heldt
    Excellent article, I liked the way you positioned the scenarios, variants and usage types.   I like the picture being painted but we need some reality checks as well.  Usage types are the tie back to the software products and release levels.  As companies implement various SAP business scenarios they will establish their NW infrastructure.  The usage types behind those scenarios will drive or determine what NW infrastructure is needed.  This is a really good thing because today SAP sends a very confusing message when a company needs to upgrade a business solution like SCM or CRM.  The current message is you must upgrade to the latest NW release.  That is the wrong message; the message needs to be…
    1) What business scenarios will be enabled?
    2) Then, what NW IT scenarios will be required to support those business scenarios?
    3) Then, what variant of the NW IT scenario is required?
    4) Lastly, what usage type supports that variant?
    Answering these questions will determine what NW products need to be installed or upgraded.

    Going back to the typewriter (as a BW old timer), I completely agree and understand what is happening with NetWeaver.  This is all really good stuff.  The part that is being missed is that there still is a BW, Portal, XI, etc. underneath, as independent products. The integration across NW capabilities is occurring but on various different time lines.  I don’t know that there is an analogy equivalent to what is happening with NW.   We have seen the convergence of capabilities across products before (for example MS Office integration) but here we are talking about changing what used to be a set of products that many thought of as applications into a platform that has a set of capabilities to be leverage by our business processes.  Ultimately, these NW capabilities will be exposed through other business solutions or processes being put into place (R/3, CRM, SCM, etc.).  In making the NW products disappear or go under the covers, there is a new set of issues to be dealt with.

    A robust SAP environment will have R/3 and one or more other business solutions like CRM, SCM, or x-apps.  The starting point is a NW stack on a release that supports all the business scenarios that are enabled.  The challenge going forward is how to evolve the NW stack as the CRM gets upgraded to provide a new business scenarios built on a new IT scenario with a usage type not supported by my current NW stack.  Here is a tremendous challenge; how to upgrade and evolve the NW stack in support of these new business capabilities while still supporting existing business scenarios.  If there are a number of applications running in portals, it is unlikely that you can just cut them over to a new portal release.  It is much more likely that multiple releases will need to co-exist with a migration plan to relocate the applications.  Similar to a Windows OS upgrade, if we expect every application will function correctly (may have some of the adapters in play) on the new release we are kidding ourselves; the infrastructure needs to account for this.  I have larger concerns with XI since it will continue to evolve into a critical component that simple can not fail or it takes down essential business processes.

    One of the main SAP selling points is NW and business process platform (BPP) will provide flexibility and adaptability to our business.  If managing NW upgrades becomes this monolithic task we have actually taken a step backward.  If we think about what it takes to execute a R/3 upgrade and now we are placing the NW stack under most business processes that will exist to provide process flexibility.  The management of the NW stack can not prevent or limit that flexibility or we have gained nothing.  In other words, changing usage types will force release management of the NW stack which is the new technology core of all the business processes, potentially more than just SAP.  I see the refrigerator being hidden when there needs to be a renewed confidence that it is an even more important part of evolving your company’s capabilities.

    These upgrades and roadmaps are not easy decisions especially when SAP is in the mist of realizing the vision which is a couple of releases away.  The series of bridge articles lays out the grand vision very nicely but we need more direction on how to cross the bridge.  Right now all the spans are not there yet and each span does not have the same design only the same goal…to get you to the other side.

    (0) 

Leave a Reply