Why your Enterprise Architects need to understand what is inside SAP

[OwenPettiford]

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”.