Putting it all together
Oh how life as an SAP professional has changed.
During my career I’ve seen such big changes in the SAP products. Now that might sound like I’ve already had a really long career and am looking forward to my retirement. But no, nothing of that. I’m only working in SAP technologies for about 7 years, but still, there’s been massive changes in those years.
It was never easy to know everything about SAP, but there where days when it used to be relatively easy. You had a database, an application server and a client. Dead easy.
Oh sure, you needed multiple functional consultants with knowledge on MM, PM, FI etc… Next to that, you needed some BC guys that took care of infrastructure and system administration. You also needed developers that knew ABAP and nothing else. Some enterprises even had SAP architects, although they were mainly on the functional side to make sure projects fit together. Communication with other parties went through IDOCs and there was little or no integration with other software components. This seems like light years ago, (yes I know a lightyear is actually measurement of distance) but I was on a project with such a setup only 6 years ago… Incredible
Obviously, things have changed and SAP started to introduce extra components like CRM and SRM. They also realised after many years, that their SAPGui was actually an ugly piece of greyscaled screendesign dating from the windows 3.1 era. So they welcomed frameworks such as the portal and the business client, along with some new UI technologies like WebDynpro and BSP.
For the functional profiles, nothing really changed. New functional profiles emerged on CRM and on SRM, and some may have had to learn a thing or two about BDOCs, SRM integration and cross system setup. But in general, their lives didn’t change much. Mind you, they already had plenty of work anyway.
Developers however, had to acquire extra skillsets. If you didn’t know WebDynpro or BSP, your use was very limited. Everything was going to the web. End-users didn’t want to see the SAPGui anymore, because if they did, they would simply go on strike. The best way to have users not accept your project, was by mentioning that it ran on SAP.
Now imagine the impact these changes had on the BC guys. They suddenly had to support a growing infrastructure, administer multiple software components, interconnect the components, expose the UI services and so much more sapadmin stuff of which I know nothing about.
It didn’t stop there. As business requirements for IT continued to sprawn, so did the solutions from SAP. It was becoming increasingly difficult as an SAP professional to keep up to date and keep the overview.
As a technical profile, you now also need knowledge on SOA, SOAP, Rules management, Process management and so much more. The functional profiles also had to start thinking abut processes instead of transactions, much more than they were used to. I don’t even want to imagine how the sprawning of components impacts the sapadmin .
A project no longer existed out of 3 functionals, 2 developers and a BC guy. No, you need at least 3 functional profiles, 3 developers, an integration expert, 2 BC guys, and ome business analyst able to work with the rules manager and the process modelers. Preferably, you also had an architect to guarantee the interoperability across projects and components.
The mill keeps on turning and the landscape continues to grow more complex, up to the point that mere mortals no longer understand what the hell the portfolio is all about. As a customer with little knowledge on SAP, it’s nearly impossible to select the components needed for the success of your projects.
Luckily, there are many good SAP professionals that can help you in selecting the necessary components and guide your project in the right directions. Where in the past, you mainly had functional architects, you now also see that Software architects start to emerge. The guys and girls that know the insides of your components and also know how they work together.
SAP is no longer the only core enterprise software component (as if it ever was) and it has to work together with other applications and technologies. Knowing your Service Oriented Architecture and how it fits in with all the frameworks and technologies has become a must.
We are already witnessing the future today with the coming of Social Enterprises, Mobile technologies and Gamification in the enterprise. Whereas today, we are still focusing on the internals of our enterprise software and the business logic, tomorrow, we will also have to focus on community input, on employee interaction and satisfaction, on reporting over increasingly growing datasets. All of that might be happening in the cloud.
As a functional profile, you’ll have to learn about Social Media, about Process orchestration, about gamification techniques. Developers will have to continue increasing their skill sets with other technologies and API’s. The sapadmin will have to learn how to manage all of his components in virtual locations and connect them, secure them and expose them.
End users will no longer be working uniquely via desktop or web, but also via Mobile devices and even unaware by sensor input. Certainly, this will be too much for any one man or woman to handle on his/her own. (If there ever was someone that could manage it all)
Businesses will need people that are capable of connecting the dots. People that know how social media can feed your marketing tool and act as collaboration spaces for your employees. People that integrate gaming techniques in the business processes which will feed the business logic with input. People that can seamlessly interconnect the business rules with game mechanics, processes with BPM, Social API’s with internal Service Bus’,…
Business will require a new breed of architects and a new approach to projects.
You can no longer separate the functional aspect from the infrastructure or the software aspects. You have to be able to connect it all together. It doesn’t necessarily mean that you have a deep expertise on everything, but at least you have to know enough fundamentals so you can talk with the expert in the same language.
In a way, It’s always been like that. Only now, you have a lot more experts to talk to.
All pictures are self drawn and are an abstraction of reality. Reality is much more complex and you’ll notice that I haven’t even put BI, MDM, SUP, ABC and Hullapalooza in there. It’s quite possible that my chronological sequence is not completely reflecting the facts either. Also, the figures I’m using are an abstraction based on nothing else but the number of birds sitting on the electricity wire outside my window. I’m not describing the entire landscape, but I’m trying to prove a point on what challenges lie ahead for us, SAP professionals.
Still, I am convinced that someone will point out that I forgot their favourite SAP software component 🙂