Skip to Content
Unless things have changed in the past few years, the core of the blueprinting process is still identification of the transactions that a customer will use and the tailoring of these transactions within the permitted bounds. If a brand-new SAP customer is really really committed to an implementation of Enterprise SOA, how will the blueprinting process be different for such a customer? It would seem that a transaction-oriented blueprinting approach is essentially inimical to an Enterprise SOA approach, inasmuch as the former relies on a predetermined dicing of business functionality into “transactions” delivered with stovepipe apps – the antithesis of Enterprise SOA cross-app tapestry. If this has been discussed anywhere in the various SDN locales by SAP staff or others (particularly the former), I apologize for missing it. But not having seen anything on this specific question, I’m wondering if SAP strategists have given it any thought.

To report this post you need to login first.


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

  1. Owen Pettiford
    I am not sure that the transaction analysis of a traditional implementation is so against the ethos of ESOA.

    It really depends of if you are taking an End to End view of these transactions instead of a module by module approach. If you take the End to End approach AND don’t have the start and end of your process at the SAP boundary the transactions can give you a good idea of the services you require. You then need to consider if the capabilities of ESOA can help a process step(s) and if it can you can service enable it.

    I think the key is having Solution Architects that a) understand the end to end solution and b) understand the raw capability of ESOA.

    1. David Halitsky
      If a new customer is attracted to SAP because of SAP’s commitment to ES(O)A, and this new customer gets an “installation guide” which stresses transactional blueprinting with no mention of ES(O)A as a formal part of this process, the customer may well feel like saying “Wazzup with THAT?”  The customer might expect, for example, some cross-reference of transactions to the growing list of SAP-delivered services, so that informed decisions could be made concerning adoption of a particular transaction combo or its ES(O)A equivalent.
  2. Former Member
    David, I was glad to see your posting, and hope it generates some good discussion and tips. I ran across your blog as I was trying to research some advice on rethinking the old BPML/blueprint approach in terms of the Enterprise Portal.

    I work on the project team for the PA State System of Higher Education. We are implementing the Campus Management (student information system) module of SAP via the enterprise portal.  However, when we created our blueprint and began realization we were using the old ASAP methodology centered on the development of the Business Process Master List (i.e., SAP transactions).

    I come from a custom application background, having worked as a testing/training/documentation consultant for the past 10 years, so I guess I may have an advantage in not being wed to the SAP way of implementation.  On the other hand, I now find myself with a BPML and a list of BPPs, along with a methodology of developing the doc and training materials that are inadequate to the task.
    From the perspective of testing, training, and documentation, I am in the process of retooling our BPML/BPP matrixes and trying to develop an iView-based approach more suited to delivery of functionality via the portal.
    Any suggestions or advice from folks who have implemented via the portal would be much appreciated!

    1. Former Member
      Lisa, try the composite application approach as opposed to traditional application development.

      In the composite approach, your application architecture will be SOA compliant, the role of business analysts will be increase with composition tools like GP, VC, CAF. Your processes will be highly configurable and flexible. The amount of code to software enable your processes will be reduced.

      The latest Netweaver is the composition platform to use to software enable innovative business processes (the ones that make your organizstion unique) as opposed to traditional core transactional processes in backends like R/3.

    2. Former Member
      I know that it isn’t widely published yet, but SAP already introduced new Enterprise architecture framework to help you get an holistic view of the enterprise and lay down the right principles, constraints, standards and blueprints togather with migration plan. we also have experience enterprise architects that can help you with the framwork.


      Natty Gur

  3. Former Member
    SAP would want the customers to upgrade to the latest mySAP ERP to get access to the Enterprises Services. Then SAP would want the customers to upgrade to the latest Netweaver in order to leverage thoses services and manage them through  the composite processes or application the customer would build on top of those services.

    That’s quite a stretch but heck, why not? In between Netweaver can still be used independently of the latest my SAP ERP (with R/3 for example) as a composition platform tapping into web services and BAPIs to build composite processes and applications for innovative business processes.

    1. David Halitsky
      Andre – Mantras are fine in their own way but if I want to drive from Nashville to somewhere I havent’ been before, I’d prefer a detailed road-map to an inspirational message.  SAP’s road-maps may be the best in the business, but that doesn’t mean they can’t be significantly improved (as I’m trying to show in my current blog posts on the notion of a “Diachronic Metadata Repository.)  If you have the right kind of road-map, you not only know where the good roads are, but also where the roads haven’t been built yet … and it’s knowing where the roads haven’t yet been built that permit customers to take the most intelligent advantage of SAP’s new ESOA service capabilities.
      1. Former Member
        sure David. how can i not agree. and in this case (SAP eSOA and Enterprise Services), it’s like a new wild wide west. most of it hasn’t been discovered yet and if you know how to get to California first, you’ll make gold even if SAP makes it there first ๐Ÿ™‚
  4. David Halitsky
    Hi Lisa –

    Glad to hear from someone who understands how inadequately the current conversion process-models relate the blueprinting part of a conversion to the documentation and training parts.

    If I were at post 13 instead of post 3 in my current blog on a conversion process-model based on the notion of a “Diachronic Metadata Repository” (DMDR), you would already be able to see how a DMDR provides an adequate technical foundation and framework for what I call “WDY2” documenation and training (WDY2 = “What you did, what you’ll do.”

    But let me give you the 25-words-or-less drill.

    If you have a completed blueprint, then you have a hierarchical representation of SAP “ToBe” business functionality. If your business re-engineers have done any kind of a reasonable job, then somewhere someone has a document which shows how units of SAP “ToBe” business functionality” maps back to your original “AsIs” business functionality. This AsIs<>ToBe map is the most important tool at your disposal for developing documentation and training materials and approaches that are guaranteed to work because …


    In particular, suppose you take all your legacy training and documentation material and put it out on the web organized according to the natural hierarchy of functionality in your legacy system. Then since you have map from the units of legacy AsIS business functionality to the units of SAP ToBe business functionality, you can develop a very slick cross-referenced “jump tool” whereby a web tool takes people directly from a piece of AsIS legacy documentation or training material forward to the corresponding piece(s) of ToBe SAP documentation or training material (and vice-versa.)

    This is the natural way folks learn anything – it’s why there are English-French and French-English dictionaries on the web. So believe me – the fact that the big systems integrators have not realized what’s needed is no reason not to try the approach I’m suggesting – in fact, it’s the best reason TO try it.

    Anyway, thanks again for taking the time to respond and I wish you the best of luck. Back in 1979, I got into this business designing and helping to write a Student Information System (SIS) to tell the Dean of one of NYU’s largest graduate schools which graduate programs were productive and non-productive so that he could cut them before NY State did. Such SIS’s are great natural habitats for “cohort studies”, whose results are typically very surprising.


Leave a Reply