SAP Solution Architecting at the time of Digitalization : some thoughts

Much has been written about the changing role of CxOs' in the context of digital transformation and as a result we see a lot of focus on this subject. In the same context, the impact is no less on all other roles from a service provider perspective, the most critical among them is the solution architect. The architect has arguably the most impactful contribution to make in the journey for transformation.

In the pre-digital era i.e. in SAP context the pre–HANA days the product suite used to be much more stable, well defined and monolithic with less frequent changes and even less radical departure from the ongoing architectural paradigm. This is not to say there has not been complex architecture/landscape or complex developments on top of SAP, done by the clients and SI’s alike – the so called Z-developments. In fact it reached epidemic proportions with developments and change requests flooding the IT dept’s. But those were much less to do with a thoughtful architectural construct. That’s why we see so many “Back to Standard” initiatives today but that’s another topic.

But now we’re dealing with a different scenario – we’ve a continually changing technology landscape and so also the SAP product; At the same time, the need for survival for the business at the onslaught of digital disruption is greater than ever before. So the SAP solution architect role is now at the crossroads and the stakes have become very high for both the service providers and clients.   

So how does it affect architecting of SAP solution? How does a solution architect respond and what kind of shifts need to happen along the different elements of architecting ? Looking from the aspects of scope, competence, mindset, experience, motivation perspective following table provides some pointers as to how an architect role need to transform to be effective in the new reality. Though none of these are new, these are some of the aspects, I consider to be important from my experience or have gathered from other forces shaping the market.

 Note: For “Then” – I’m considering the period 2005-2015 and for ‘Now’ – 2015+

Let us look at these aspects in a bit more detail:

Scope & Context – today it’s no longer just about SAP/Business suite but beyond it. The SAP product strategy and architecture has undergone significant changes and is now more open, modular; where we can use services as in API's or extend the applications in cloud, or integrate a start up solution for a leading edge capability. So the architect need to be conversant with the larger ecosystem, trends and be able to make sense of it and propose solution for a relevant use case. In short we’re looking at a more open and larger scope beyond just SAP application even though the core can still remain firmly in SAP.

e.g. with respect to cloud, an architect needs to understand the accounts concept for a XaaS solution, like an extension of the landscape planning concept in an on premise solution.

The canvas in which an architect needs to operate is also different now. Earlier it was from idea or business requirements to implementation and benefit realization. Now the focus is more on a end to service or product and the need to seamlessly deploy over the entire life cycle.

Mindset – an underlying theme has emerged in terms of the mindset and expectation that we have as far as architecture is concerned. Earlier the provider mindset was dominant and the expectation was to follow the business strategy and translate it into a design/architecture. Now an architect needs to have an innovators' mindset - since the expectation is clear: be a disruptor to business and actively develop business & IT strategy. I’m seeing more such instances where we’re doing simultaneous business & IT transformation in SAP context a la “concurrent transformation”. 

Architectural Focus – The objective and purpose of the architectural construct was to deliver a SAP system which is stable over time and to achieve robustness, compliance, stability. There’s no denying that these aspects need no less attention today but the focus so to speak has shifted to a working architecture which can grow/morph over time. Suddenly imagination, creativity is being expected out of the architect which we could not have thought of in the context of traditional dreary SAP environment. A more open and modular architecture pattern is naturally pushing the architect to tap into the myriad possibilities that exist in the cloud, API’s, microservices etc. “Imagination is more important than knowledge” (Albert Einstein) may have been said about architecture of today. (taking the creative liberty of course!)

Motivation – If we look at the motivational aspect of what had been driving the organizations to embark on a SAP journey, we realize that primary factors were – integrated transaction `processing, standardization, breaking functional silos and promote enterprise wide integration & visibility, process harmonization, transition to process driven system from people dependent practices, planning & control and so on. In pursuing these goals companies were looking at best in class practices/Class A processes in the industry sector where they operated. Today the motivation is primarily due to the pressure to create new business models and using disruptive technologies to grow and harvest the network economy. In doing so companies are not just looking at their industry peers and leaders but asymmetrically to any application of technology which allows the business to leapfrog into the digitalized business.

Mode – Organizations have geared up for an operating model that can satisfy multi speed IT. Architecture is a key part of that operating construct. The architecture need to be segmented to different layers which cater to different set of business requirements, consumption and pace of change.SAP as a system of record has traditionally been treated as legacy architecture requiring less frequent changes. But that’s not true anymore and especially on the customer facing side, the solutions need to be delivered and consumed at a greater agility. By using API’s the core services are also becoming more amenable for fast moving design for extended services. The architect need to be able to put in place a design framework where different layers of the solution architecture can accommodate different quantum and pace of changes. Think of an on Premise S/4HANA core solution and extensions being built on HCP. This aspect is also closely linked with DevOps and continuous integration and delivery that was covered in ‘Scope” context.        

Type of engagement – Another important indication as to which way the wind is blowing can be understood from the type of engagements and projects that is coming up nowadays specifically in the context of SAP. Although may be counter intuitively, its coming out from recent data points that greenfield projects are disproportionately high among the total number of S/4HANA projects both ongoing and live; The fact remains that even a large part of that is a result of conscious decision to transform the “legacy SAP” environment. So it’s a natural reflection of the reality that SAP transformation type of engagements are the playground for the architects now and hence the architecture of “new” SAP vs “Old” SAP is the key topic of attention for the architect. We see an impact of this on the key capability of the architect also.

Key competence - We need not go into the details of the skills/expertise required for the SAP solution architect in the world of digital transformation. But at a high level, nowadays I see that having a long experience in SAP is not of any distinguishing value for an architect anymore. Rather it can be a drag. The key competence most sought after is - transformation and developing new business models.

Another feature of this shift is the weight attached to the architects’ ability to make sense of the technology deluge. In a traditional SAP world there have always been the functional vs. technical divide and outsiders had a loathing for this. An architect would have been expected to transcend these boundaries and needed to understand the business in a domain/industry..

But now, all that is just the baseline, given. When technological capability is changing so rapidly, an architect need to be a “technologist” too, to understand the technology, how it can best be used in the context of a client business and apply it into the solution architecture. I for one have not seen so many questions from SAP customers before – "we hear about xxxx and please tell us what we should do and how can we use it" ….