Or in other words what does a Post-Modern ERP strategy look like?
Blog by Tim Main – IBM Information Management and ERP – Technical Director
17th July 2017
Executive Summary – The Question?
A number of months ago I was asked by one of my experienced and senior colleagues in the IBM SAP Implementation and solutions technical community the question what might “A Post-Modern ERP Solution Landscape” look like?
This followed a similar prior question from the CIO of a significant European Pharmaceutical concern and the recent DSAG SAP CIO Investment Study of 269 German speaking CIO’s from November 2016-January 2017.
Where ~ 50-60+ % of these CIO’s essentially identified increased strategic IT investments in Digital Innovation as a key priority, whilst up to 50% did not currently consider SAP S/4 as an alternative to their existing often customized and broadly deployed SAP Business Suite / ERP deployments.
Consequently linking back to my prior blogs in this area, I decided to explore what a “Post -Modern ERP Landscape” may look like leveraging an open API / Microservices architectural integration construct that seeks to “Innovate with new + integrate + leverage existing” ERP Systems of Record applications scenario.
It maybe suggested by some ERP vendors that a migration, upgrade and/or remediation of prior customized, business process aligned SAP Business Suite functionality onto SAP S/4 Enterprise Management is linked as a prerequisite to the ability of an Enterprise to Digitally Innovate.
Recently Philip Howard, Information Management, Research Director at Bloor Research has published a paper looking at the Myths of SAP HANA which can be found here.
From my point of view, and likely more importantly from the view of a number of Enterprise Client Chief Enterprise / IT Strategy Architects I have spoken to, we simply don’t see this firm or direct linkage, in fact the reverse seems to be true in an Open Source / Open Enabled Digital Innovation world.
Where the focus is correctly on enabling the integration of new front office Digital Innovation IT solutions (enhanced Systems of Engagement, Systems of Insight, Systems of Innovation) vs remediation of prior Systems of Record / ERP solution investments.
If we accept this fundamental strategic assumption, we can then go on to consider a number of the “layers of the cake” in terms of Business Innovation into IT technology strategy and prerequisite capabilities.
The Resulting Strategy – High Level Strategy – May look something like?
This also links back to my prior analysis of “Factory IT” and Innovation IT” following a Harvard Business Review (HBR) – Business into IT Strategy Review Paper in 2008/9, where this is now more commonly referred to by IT analysts like Gartner and/or Forrester as “Bi-Modal or Dual Speed IT”.
Further details on “The Layers of the Cake”
From my point of view one of the most important and strategic aspects of an effectively implemented API / Microservices strategy is to enable, deploy and govern a layer that acts as a layer of graphene or graphite, gearing and lubrication between the rapid pace of innovation and change demanded by the business of Innovation IT.
Whilst pragmatically recognizing that Factory IT needs to operate at very different speeds from a change and release perspective whilst still communicating and passing data between these two layers effectively.
A “Back to the Future” IBM SOA Solutions for SAP from 2008
Whilst researching in preparation for this blog I was repeatedly drawn back to a prior IBM SAP SOA Client White paper at Viessmann that describes SOA (Services Orientated Architecture) solution enablement to complement the Clients prior and significant SAP Business Suite / ERP investments.
This paper essentially described the principles of a flexible IBM SOA enabled front office application integration/s strategy for client and channel facing and line of business applications, helping Viessmann to deliver increased business flexibility and enhanced customer service and productivity to support the needs of a growing business.
Being a firm believer in “Back to the Future” Scenario’s within the IT Industry, I was very naturally happy to look back for a proof point to then look forward again.
The summary paper describing this project can be found at
In its simplest terms this case seemed to cover a number of the key aspects for a client to consider in a “Post Modern-ERP Scenario”.
However this said, I’m often then challenged by existing EAI (Enterprise Application Integration) teams on the question “but we already have a deployed and working ESB, why do we need an “Inner Ring / Outer Ring” hybrid API / ESB architecture” which I’ve attempted to explain in the following two diagrams.
The fist diagram comes from an excellent “Integration Throughout and Beyond the Enterprise” IBM Redbook that can be found here.
Figure 1.1 and Figure 1.2 in particular nice summarizes the differences in the prior SOA focus and the SOA + API Economy focus.
Additionally, in the following diagram after reviewing and consuming the API for Dummies Wiley book that can be found here, I’ve attempted to summarize the differences and positioning of this dual ring API / Microservices and ESB / EAI enabled strategy.
Then I have pulled together a couple of diagrams (on the basis a picture is worth a 1,000 words) that consider the key factors from both a business and technical point of view on the positioning of API enabled Microservices vs ESB enabled Enterprise Application Integration (EAI) as follows, whilst a little busy they are both self-explanatory.
The Wikipedia description of Microservices seems to nicely summarize the combination of loosely coupled, fine grained services to enable agile and flexible development initiatives combined with “re-factoring” and/or re-facing of existing systems into the post-modern ERP world.
“In a Microservices architecture, services should be fine-grained and the protocols should be lightweight. The benefit of decomposing an application into different smaller services is that it improves modularity and makes the application easier to understand, develop and test. It also parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently. It also allows the architecture of an individual service to emerge through continuous refactoring.Microservices-based architectures enable continuous delivery and deployment.”
Recently the University of Manchester has been doing some very innovative work looking at the layered properties of Graphene for water filtration this work as described and summarised in a recent BBC Science & Environment item on the 3rd April 2017.
For me this provided a nice analogy of what we are seeking to securely do with an API / Microservices IT architecture where we have “Inner / Outer Ring” layers of the business and application integration cake that enable loosely coupled clusters of fine grained “SOA” like services to work.
Where solutions like IBM’s API Connect provide proven secure “appliance based” strategies for the outer ring whilst integrating and safely filtering / passing fine grade API’s enabled data to and from with the clients existing inner ring ESB.
This diagram below attempts to summarize the differences in nature between an API / Microservices appliance and a typical ESB for Enterprise Application Integration (EAI).
And from a business into technology point of view in terms of grouping, use case alignment.
Then we simply need to layer in capabilities in the new “Two Triangles” worlds of SQL schema before and SQL schema after “Big and little data” and we have a foundation from which to build.
Supporting Data Management and Information Management Strategies.
In my prior blogs I’ve described the supporting “Two Triangles” (SQL Schema before and SQL Schema after) data worlds that needs to be developed in parallel with a viable API / Microservices strategy, this is very important to avoid the API / Microservices enabled business solutions becoming “islands of information” that are isolated from each other.
Where a critical objective of an API / Microservices economy is to leverage information insights for strategic and competitive advantage including both prescriptive and predictive analytics in addition to the more common descriptive analytics.
At the risk of a slightly longer Blog item, this architectural approach is summarized and described below, where the “Insight into Action” activities maybe both API / Microservices enabled and linked to aligned cognitive / intelligent business process optimization tools and IT capabilities.
Inhibitors and Enablers
In this diagram, I’ve attempted to summarize the key enablers and inhibitors for a successful API / Microservices deployment strategy:
Critical Success Factors
Understanding that ultimately a successful API / Microservices strategy starts with the business digital innovation agenda and strategy and then flows down into the enabling IT capabilities, whilst initially bottom up API / Microservices projects are a way to start small and scale fast, ultimately it will require a top level down strategic investment led strategy.
Also I would refer readers to an excellent IBM Institute of Business Value study that looks at Innovation in an API Economy which can be found here.
Open Source and Standards driven eneblement and business process optimization
In my view for an API / Microservices strategy and economy to succeed it requires a clear and long term commitment to Open Source Solutions and the definition of Open / Published API / SOA messaging formats and standards.
IBM has a very significant and clear track record in this area, including in recent times the Open Source enablement and contributions made by NODE-Red in the IoT (Internet of Things) area, which was the subject of a prior blog item.
Conversely any ERP vendors who attempt to impose aggressive license terms and conditions that essentially prevent the enablement of a successful API / Microservices economy through the application of “indirect access” license terms and conditions will likely become increasingly isolated islands in time.
Which takes back in a full circle to the beginning of this blog, what does a “Post Modern ERP Application” look like in a world where the ability to Digitally innovate and successfully integrate traditional Systems of Record / ERP systems with innovative Systems of Innovation, Insight and Engagement becomes and critical “business survival and differentiating strategic IT capability”
Sources of further information that are referenced or were researched for this blog include:
Understanding there is a very broad and deep pool of information sources in this area, consequently my principle challenge for this Blog was what to leave out vs not what to include.
For example, I left out a pool of material on Client SOA / API maturity capability analysis and step wise development that was very interesting and critical for most clients, in addition to IBM’s Data First Method, whilst understanding Rome was not built in a day.
IBM’s API Connect Overview can be found here:
..and further technical details here:
IBM Redbook – Getting Started with IBM API Connect: Concepts and Architecture Guide
APIs for Dummies – Claus T Jenson
Plus, a recent demonstration of integrating simulated data from a back-office ERP system with Weather data to dynamically re-route deliveries to from ACME Co to Retail pharmacies and distributors leveraging “Strong Loop” capabilities:
The Evolution of the API Economy – IBM Institute of Business Value
IBM Redbook – Integration Throughout and Beyond the Enterprise
The prior Viessmann IBM White Paper re SAP and IBM SOA Solution Enablement
White Paper – IBM SOA Foundation: providing what you need to get started with SOA, 2005.
Wikipedia Entry re Microservices
Finally as an example IBM Watson IoT architectural point of view (pass the curser over the various ABB’s) in the landscape which combines integration and information building blocks.
The opinions within this blog are the authors, they do not represent a formal IBM corporate point of view, copyrights are respected and/or sources referenced.