New roles in our projects
I would like to start a discussion on the new roles in our SAP projects. With the roles I explicitly mean the content-roles like developers, architects and module consultants. In this post nothing about project managers or account managers, sorry, maybe next time.
Why new roles? With E-SOA things are going to change, not only on the SAP content or project goals but also on the essential roles that you and your colleagues want to fulfil in a E-SOA play.
Let’s first have a look at the ‘old-days’.
This is the way I see it, and please share your ideas in a comment to this post, we all have to grow into solution architects. We cannot live on islands anymore, if we want to deliver the best solution to our customer (and of course we do want that) we will have to make sure that these new roles are available in the project team.
A business process expert is more than just a module consultant. The business process comes first and the module is only the tool to realize the customers wishes. As the BPX is very well capable of understanding the architecture, he/she will advise the architect from a business perspective how the enterprise architecture will have to look like.
The software architect is supported by the BPX with a clear and well described functional design on the customer requirements. In fact they will both deliver the input for the specifications after a discussion on the best solution. From the development perspective the software architect will advise the architect on the enterprise architecture. So, besides the development skills that a software architect quite obviously needs to have, he/she must also be capable in setting out the direction of the solution that will best fulfil the customer requirements.
Why new roles? With E-SOA things are going to change, not only on the SAP content or project goals but also on the essential roles that you and your colleagues want to fulfil in a E-SOA play.
Let’s first have a look at the ‘old-days’.
There is an architect, a module consultant and a developer and - hopefully - they work together towards the best solution for the customer. But as we all know, it is very well possible that all three roles live on separate islands. Despite this a proper solution for the customer will be delivered, but if it is the best … I don't know.
Now with E-SOA and the changing world that business is demanding more flexibility and speed from IT, roles will have to change. A close collaboration to start with.
Now with E-SOA and the changing world that business is demanding more flexibility and speed from IT, roles will have to change. A close collaboration to start with.
This is the way I see it, and please share your ideas in a comment to this post, we all have to grow into solution architects. We cannot live on islands anymore, if we want to deliver the best solution to our customer (and of course we do want that) we will have to make sure that these new roles are available in the project team.
A business process expert is more than just a module consultant. The business process comes first and the module is only the tool to realize the customers wishes. As the BPX is very well capable of understanding the architecture, he/she will advise the architect from a business perspective how the enterprise architecture will have to look like.
The software architect is supported by the BPX with a clear and well described functional design on the customer requirements. In fact they will both deliver the input for the specifications after a discussion on the best solution. From the development perspective the software architect will advise the architect on the enterprise architecture. So, besides the development skills that a software architect quite obviously needs to have, he/she must also be capable in setting out the direction of the solution that will best fulfil the customer requirements.
Comments
Do you think this view will change our business as a consulting-firm?
Personally, I think that most of our customers have seen the value of having in-house module-consultants, and they hired them. Most of our customers have the knowledge in house to evaluate their processes, and a view on how SAP can fulfill their needs. They just need to realize it. So if module consultants want to keep an edge, they'll have to look into architecture, and look over their module-borders and become a BPX. For the architects, and developpers, it becomes more and more clear that they should have basic knowledge of each others' fields.
Most of our customers do not have extensive architectural or development knowledge in house. This makes the market for us developpers the coming three years a nice place to be, but only if we know how to use, link and unlock the different process-enablers. Just knowing plain ABAP is not enough anymore.
Keep up the good work of posting all your nice thoughts... Even if you start your new challenge...!
Good luck Twan and if you have any basis questions, you know where to find me.
Joris van de Vis
I also strongly feel that the "techies" need to gain more knowledge on business processes and a little customer intimacy (I like that, hmmm) will not do any harm. But how do you see me as a basis consultant in your new roles?
Any ideas on that?
Gr.
Joris
There will be a major role in the future for you as basis consultant.
The coming landscape of SAP is all about placing the end-user in the middle. He has to run his business process and is not interested in the underlaying systems. As basis consultant and software architect we have to make sure that all systems that are required to support the process are seamlessly integrated.
With all the possibilities that the SAP NetWeaver suite provide us there will be enough work for you and me in the future.
Twan
I agree that a lot of things will change in the E-SOA era. In order to tell where current SAP professionals should evolve into, I think you should be more precise in what you exactly mean with "solution architect", "architect", "business process expert", etc. Is "solution architecture" a subset of "architecture"? Where do you position "enterprise architecture"? Etc.
Architecture (and also solution architecture) has a very broad scope and since the world - also the SAP world - is getting more and more complicated, you can not get away anymore with statements like "SAP consultants need to be solution architects". It is just too vague.
SAP implementions will slowly fade away in the future and be superseeded by "process improvement" and "IT consolidations" projects in which SAP - but more and more also nonSAP components - will play a role. Translating business context (business directions, constraints, policies) into business process requirements and IT requirements on one hand and translating IT requirements into IT solutions on the other is getting more and more critical. This is what we call "architecture".
"Enterprise architecture" addresses the translation of business context into business process requirements and IT requirements. Enterprise architects do their work with the help of business consultants (consulting services) that have large sector specific knowledge and know the particular organization quite well.
"Solution architecture" addresses the translation of IT requirements into IT solutions. In the SAP and (E)SOA world, the possible IT solutions are not limited to SAP R/3 anymore: it is SAP, nonSAP, SAP ecosystem, A2A, B2B, BPP componenten, legacy, etc. As far as I am concerned, "solution architecture" needs to be further split up into more than one role, because its scope is too broad to be covered by one. I foresee four types of solution architects - in SAP-centric process improvement projects:
1) Solution architects that - at high level - select the right IT platforms (SAP, legacy, Oracle Fusion, etc.) for the IT requirements at stake. Solution architects of this type are supported and inputed by enterprise architects and business consultant with sector knowledge and expertise of the organization.
2) Solution architects that select the right functional SAP components for the IT requirement - as far as the mySAP Business Suite and the SAP ecosystem is concerned.
3) Business Process Platform (NetWeaver) solution architects.
4) SAP SOI solution architects.
So for me as a SAP consultant: what type of solution architect should I become? You tell me! ;-)
I think - in the bottom line - the four different type of solution architects should stay in their boxes. I do not believe in e.g. a BPP architect (like myself) that all of a sudden starts to be involved in business process discussions with a customer. Forget it; they (the BPP architects) just do not have the expertise; moreover, they have their hands full with their own specialism which is getting more complicated by the day. And it is not necessary neither because we have other people to do the business process stuff.
Where does that leave our SAP module consultants? They should indeed evolve into solution architects, but limit themselves to the mySAP functional platform components including the SAP ecosystem (solution architect type 2 in my story). They should heavily liaise with solution architects of type 1, enterprise architects and business consultant to do their job properly because they (the SAP module consultant) often lack the real sector specific business knowledge: they do know SAP but they don't really know the business. They should be aware that they have to climb the stack towards the business process level firstly since their current work will be more and more rightshored and secondly because E-SOA is not any longer about best practises but next practises in which business process improvement is key.
And where is SAP AG's business process expert (bpx)? I think it is a combination of the enterprise architect + business consultancy + solution architect type 1 and 2. Not really something to combine into one role I would say and certainly not a role our average SAP module consultant is catered for today. Simply because the letter hardly has sector specific business expertise.
In other words, Twan: I support the direction that you describe in your blog completely, but I would like to see sharper defitions in terms like "architecture", "software architect" en "bpx". Since I think we will get many different roles to cover the whole spectrum of work that makes up the SAP implementation of tomorrow, it is not only important to describe these roles precisely but also their interactions. The SAP implementation in the E-SOA era more and more means (business & IT) teamwork.
Something for our article? ;-)
Looking forward to your reaction.
Rik