I work for IBM, and like many of you in the consulting business - I get to wear many hats, and usually multiple hats concurrently. My primary client facing role is Program management - where we partner with a client to deliver a large piece of functionality, and this usually involves running several concurrent project teams delivering parts of the solution, and an integration team keeping it all together for one grand solution at the end. Since I get to run big projects in this job, I also get some opportunities to try out having different roles in my team to see what works and what does not.
Yesterday night - I listened to an excellent Enterprise geeks podcast on roles in SAP project. Jon, Leo, Ed and Tom were discussing BPX and Solution Architect roles for part of that discussion. I commented on that, and Ed asked me to clarify my opinion. I started to type a reply there, and then decided on moving it here, with the intention that we get a broader discussion going.
The term BPX is fairly recent. In true SAP tradition, anything that originates from SAP should have "Business" in the beginning - Business Suite, Business Server Pages, etc - so I think it is fair to assume some one at SAP must have coined BPX. I immedeately took a liking for the concept - and with the support of my management, I actively promoted it at every opportunity I got.
The term Solution Architect is a bit older, and did not come from SAP - and I know of plenty of non-SAP projects that have such a role. In fact, I am pretty sure this role started in non-SAP world. Now - I am not aware of a crisp definition of a Solution Architect. If you search on internet, you can see some definitions - some too narrow, and some so wide that it made me wonder if Superman actually was a Solution Architect.
From a career perspective, most people like to have their seniority reflected some how in their job titles. For people who fancy a traditional career path in SAP - this usually progresses from developer/functional team member to team lead to project lead to program manager/director. Different companies have different names for these roles - but they are kind of similar.
However, not every one wants to be a manager - some techies actually feel terribly insulted if they are refered to as manager :). And hence arose a need for a path like Developer - senior developer- very senior developer - very very senior developer :). Now of course - the moment you see "developer" it implies some one is doing coding. The very very senior developer probably does not see value in coding himself/herself. Instead, their time is better spent in designing, trouble shooting, planning etc, So people needed a title to represent this function - and it had to be similar to the title "Manager" in stature. "Architect" fits that need to a T.
Of course, where is the fun in life if we stopped at Architect? So we further classified - and hence Architects come in many forms and names - Development Architects, Solution Architects, Enterprise Architects etc. I ran into a company recently that further makes a distinction between Architect and Senior Architect.
Now - SAP being all about Business Applications, most SAP techies need to know the business side of the world to some detail. However, in search of efficieny - most companies created a sharp divide that led to technical and functional people having separate skillsets. It also happened that most managers came from the functional side. After one or two projects in SAP - both types realize that no good solution can be made without knowing the other side of the coin. But since there is very little organized training to bridge this gap - people have to do this on their own. To make this more difficult - SAP changes roughly every full moon, and you are always in catchup mode 🙂
With this background - let us compare the roles of BPX and Solution Architect. Somehow, there seems to be an impression that BPX comes from a primarily functional side, and picked up tech stuff along the way , where as Solution Architects come from the other end. From my own experience, I don't think this is the case at all.
Here is why I think so
In the context of companies that primarily run on SAP, how does the business process get described and visualized? More often than not - it is described as how the business flows happen in SAP. It is "not" done in abstract business terms. I have seen a couple of exceptions along the way, but primarily - most business users think in terms of the screens/reports they use or need, and their flow. So to enhance this business process, an intimate knowledge of SAP is needed, and not just business knowledge. And in principle - the BPX and Solution Architect essentially go through the same thought process to solve the issues, or enhance the process.
As a percentage of people I know in SAP world - I have seen many more technical people pickup the functional knowledge along the way, than the number of functional people who take up technical stuff. As concrete examples - I know several developers who understand pricing extremely well, but I don't know many functional guys who can write a BAdI without handholding. Similarly, look at who use SAP's business friendly BPX tools - Visual Composer, CE, etc. Most of them are techies. This makes me believe that the skillset of Solution Architects and BPXers are identical.
Web 2.0 knowledge is also considered essential for BPX. Guess what - Solution Architects, the folks who come from technical side apparently, took to it like a labrador retriever (ok, or duck) to water. So there is no disparity there either.
Bottom line - in my opinion, these two roles are identical from what I have seen. I have never once been successful in convincing a client that I need a BPX in my team, but the same clients readily agree to having a Solution Architect. My purpose for that role - some one who brings technology and business together to find the best solution - is served. So I no longer try to have a BPX in my team, I just use the term Solution Architect for the same purpose.
All that being said - it is not easy to find this skillset in big volumes. People like to specialize, and that is how the SAP market developed . Most times you try to recruit a Solution Architect, you will probably get a bunch of very technical people, who don't seem to have a sufficient grasp on the business. Occassionally, we also get lucky and find a great functional person who is tech savvy. Either person adequately serves the purpose for the critical role. And so far, I have never seen any one who asked me to him/her the title BPX.
And one last thing - does SAP really see sufficient value in having a separate BPX section on SCN?
