If I go back 20 years when SAP had 2 products (R/2 and R/3) with a few industry solutions, it was probably appropriate for Enterprise Architects to consider SAP as a black box that provided some functional components.

If we roll forward 10 years, SAP had extended its product suite to include other applications (CRM, SRM, SCM, BW, Portal, PI, MDM etc). At this point, I would already argue that Enterprise Architects should have started to consider SAP as multiple products, considering each one in turn to see where it was to be used within their enterprise together with the pros and cons of SAP pre-integration between components vs a truly decoupled model. Many did, but some still considered SAP as one black box. Some of this was due to the fact that although SAP now had several functional / technical components, most of the time SAP had a recommended way to fit them all together, with integration being “taken care of by SAP”, so even if you wanted saw SAP up, you were often battling against SAP architects who wanted to follow “best practice”

Roll forward another 10 years to today and SAP has expanded it offering beyond the expectations of most people (me included). Based round the 5 pillars of Applications, Analytics, Mobile, Cloud and Database/Technology we now have a portfolio of applications / technology that is massive. Below is a summary of some of the key products (sorry if I missed your favourite) :-

  • Applications
    • Business Suite (ERP, CRM, SRM, PLM, BW)
    • SAP Smart Business Applications
    • Fiori
    • Business One
    • Cloud Connector
    • Hybris
  • Analytics
    • Business Objects (Webi, Crystal, Explorer, Analysis, Dashbaords, Design Studio etc)
    • Lumira Server (HANA)
  • Mobile
    • SAP Mobile Platform 3.0
    • SAP Afaria
    • SQL Anywhere
    • Syclo
  • Cloud
    • Success Factors
    • Ariba
    • Finance On Demand
    • Customer On Demand
    • Business One
    • Business By Design
    • Travel and Expense Management on Demand
    • HANA Cloud Platform (Portal, SAP Mobile Platform Cloud Edition, Cloud Integration, Gateway as a Service, Java and XS applications)
    • HANA Enterprise Cloud
    • HANA as Infrastructure
  • Database and Technology
    • HANA
    • NetWeaver Process Orchestration (BPM, BRM and PI)
    • NetWeaver Gateway and Gateway Productivity Accelerators (inc Microsoft)
    • SAP UI5
    • Personas
    • Data Services
    • Single Sign On / Identity Management
    • Governance Risk and Compliance

The point I want to make is 3 fold :-

The first is that SAP can’t be evaluated as a black box any more as with such a product range, you may choose to use SAP in one area and not in another.

The second and more important change, is that there is no longer only one way to solve a business problem using SAP software. The most obvious choice is between on premise and cloud, where the offering for different business solutions are not the same code base in many cases e.g HCM vs SuccessFactors. However these overlaps exist throughout the SAP portfolio, so it is important that an Enterprise Architect is fully educated in the capabilities of each solution and how it could fit into their bigger picture.

Finally it is a changing landscape with new capability and products being added almost daily. SAP development have (mostly) moved to Agile development methods which means that the code base is enhanced in smaller incremental parts. This is great for the cadence of development of new features (we get them quicker) but can make the Architects job harder as 7.3b might have a killer feature that was not in 7.3a (just an example).

So strangely as SAP gets easier to implement, it gets harder for Enterprise Architects to understand and put in to a “box”.

To report this post you need to login first.

4 Comments

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

  1. Andy Silvey

    Hi Owen,

    very nice summary and point.

    I especially agree where you say,

    ‘The second and more important change, is that there is no longer only one way to solve a business problem using SAP software….  it is important that an Enterprise Architect is fully educated in the capabilities of each solution and how it could fit into their bigger picture. ‘,

    and the same point is discussed in the Introduction to the NetWeaver Architecture Category.

    This is one of the beauties of SAP Architecture, there is no one size fits all right answer, Architecture decisions are influenced amongst other things by:         

         . short and long term strategy         

         . short and long term goals         

         . budgets         

         . demand

    and it is often the case that what is right for one company is not right for another.

    And you’re right, the architect needs to know about everything in the SAP Portfolio, what works well with what and why and how to glue it all together.

    Best regards,

    Andy.

    p.s. thanks for the tags

    (0) 
  2. Tom Van Doorslaer

    Hi Owen,

    I entirely agree that Architects (not just enterprise architects, but software, technical and project architects as well) need to stop looking at SAP as a black box.

    Even more so, I vote to get rid of the faulty term “SAP” in it’s entirety.

    You see, many managers, veterans and architects still think of SAP as the “ERP solution”, whilst “SAP software packages” include a much broader range of solutions. (as you listed)

    So instead of talking about “SAP”, I always talk about “an SAP software package”, or I use the dedicated name of the package where possible.

    Cheers!

    (0) 
  3. Jose Francisco Osorio

    Great post!

    It is absolutely essential to know the specific details of what components of SAP are being leveraged in any given implementation that touches SAP. The interesting part is that typically one has to marshall the discreet resources and SMEs (there are usually several) in order to fully understand not just the components, but the type of data and processes they employ in order to architect the optimal integration methods. (think 5 blind men touching an elephant)

    Add to that your point “as SAP gets easier to implement, it gets harder for Enterprise Architects to understand and put in to a “box”.

    This is fast becoming an Agile world and it’s important that EAs keep abreast of the developments in SAP and the interoperability between its components. Perhaps part of reason why “SAP” bacame a catch-all phrase is that it was easier than to refer to to individual modules (What’s ECC? Is that SAP?) and risk confusion. Time to change all that.

    Thanks again!

    (0) 
    1. Owen Pettiford Post author

      Jose,

      I am glad you liked the post.

      With S/4HANA it is now more important than ever that EA understand the capabilities of SAP.

      Owen

      (0) 

Leave a Reply