Skip to Content
Personal Insights

Solution Architect vs BPX

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?

You must be Logged on to comment or reply to a post.
  • Vijay,
    In reading your post, I was thinking the Solution Architect was closer to the “Enterprise Architect”.

    I come from the other direction, starting out as an Accountant, learning the functional side, moving to the technical side, and then moving back to the functional side.  I think to be successful you have to go both ways.

    Great question re: BPX/SDN.

    I too wonder if SAP really sees Visual Composer (which I love) for the Business Analyst…I used it as a technical person, and I could never really get it to work to do rough prototyping, as intended.

    Food for interesting thought…

    • Tammy, glad you liked the post. You sound like a person every SAP project would love to have – a great balance of functional and tech skills.

      VC as a business analyst tool has a few limitations. Unless there is a function module or join that already has the info you need, you cannot do everything you need to build a useful app. But it is a simple enough tool – and SAP deserves some kudos for keeping it simple.

  • For anyone who wants to listen to the podcast on enterprise geeks, here is the link

    Vijay, thanks for the clarification and the well thought out response. It is definitely important to talk about where the terms came from and where the roles evolved from to understand where we are going.

    Even if you are finding these roles to be one in the same currently, I do not believe these should be the same in the future. The two roles are close, but they should actually work together. I see a world where BPX focuses on realizing the improvement of business processes using a solution whereas the solution architect is the designer of the system to enable that solution. It is important for the Solution Architect to also understand from the BPX the future needs to ensure a proper solution/application is designed optimally for supportability and, very importantly, future scalability.

    Thanks again for the great, thought-provoking comments.


    • Ed, thanks for commenting – and getting this discussion started on You are right – just because they look similar now, is not a reason to assume they will always be similar. I am sceptical, but also very curious to see if they grow into two distinct roles in future.
  • I would put it a BPX as having 40% tech knowledge and 60 % Business knowledge.  By this what I mean is he need not know exact solution for a business initiative, but should at least know the technological limitation.
    But for a solution architect should have 60% tech knowledge and 40 % Business knowledge.  He should be able to produce a solution for a necessary business challenge / intiative.
    Any comments 
    • % divide could be great if we can measure – but since it is impossible to measure in this case – I think 60-40 mix will look too close to each other to differentiate. Would you agree?
      • Hi,

        I agree that a 60-40 divide or any quantitative number cannot be derived at, but at least the inclination for a solution architect is more towards technology while for that of a BPX is towards Business though not measurable.  What say? 

  • Hi Vijay,
    A very good and thought provoking blog. As you have mentioned in your blog, it is indeed difficult to find resources with both functional and technical knowledge to be able to play solution architect role. Most of the time, from my experience, a person with technical knowledge is expected to play this role with the support of functional team.


  • Vijay,
    **warning long response**
    As always, I am in eager listen mode to what you have to say, because it is backed by experience, intelligence, and thoroughness.
    In the case of this content I must smile(with chagrin) a bit because, although my name is quite clearly associated with the BPX community, and much to my shame I did not participate in the Enterprise Geeks Podcast live, I cannot help but think this is a bit of a rehashing of the same discussions we have had since BPX was created, as a community for people who approached solutions to business problems putting solution first and not Solutions (as in SAP software) or other Technology Solutions first.  If we look at all the “Geek Suit” discussion days of earlier days, this “vs” idea sets us back a bit and the smile is ironic.
    What is a SDN topic and what is a BPX topic?
    Who is a BPX?
    What is a SDN topic and what is a BPX topic?
    Who is a BPX?

    I evangelize SAP communities (re: advocate people’s business needs).  And often communities are self-identified, self-defined, self-formed, and if done right self-governed.
    Since there are at least 15,000 self-declared members of the BPX community (a small but not insignificant number) who identify themselves as BPX ONLY (in their community affinity on their SCN business card without being part of any other family of communities here), I cannot help but think that they DO exist. 
    On the other hand I believe that a community website that doesn’t evolve and serve it’s people isn’t functioning properly.
    I know that a great deal of care is given to investigating the self-perceived roles and personas of members of our site and I do believe you will see changes as that care translates into providing more appropriate services suited (no pun intended) to the populations that come here or who are invited to participate here.
    Your input into that persona conversation is always welcome.

    • Marilyn, thanks for chimming in. And it might be an interesting followup with enterprise geeks or jonerp and get your valuable input out there.

      I agree – a lot of this is a rehash. I think it happened because BPX did not take off the way we all thought it would, and hence a relook at fundamental aspects is then a predictable effect.

      In current community size, 15000 is miniscule – and I am sure SCN team is thinking hard on how to get BPX to the next level

        • Actually BPX has over 1/2 million registered users.  Those are folks who choose to mark BPX as a community they belong to as marked in their business cards and as they have registered.  Many of those folks also choose to be part of SDN, Business Objects, University Alliances.  I referred to folks that have no affinity with any other of our communities and choose NOT to be members of those and declare themselves exclusively BPX community members.
  • Vijay,

    good blog post. I am a big believer in what the BPX community is doing overall – though there is plenty more to be done clearly. I see that as a bigger discussion Marilyn has covered well in her post.

    Since it’s Friday and work needs to wind down for me at some point here for me to find a weekend, I’m going to limit my comment specifically to the point you raised with Enterprise Geeks about whether Solution Architect, is the only such BPX role needed?

    That’s clearly your observation on customer sites currently, and to me, that carries a lot of weight, because buyers/users have the final say on what gives them value.

    However, just as Ed was talking about how Solution Architect gives technical folks a BPX type role to aspire to, I believe there should be a similar role to aspire to on the functional side. In truth, many technical and functional SAP roles are going to require some BPX flavored skills, which is why what is happening in this community is so important.

    But in terms of Solution Architect, I consider that the first “pure” BPX role to have gained traction in SAP client sites, with a close nod to Enterprise Architect, which I see as different for reasons I explained in the podcast.

    Solution Architects tend to rise up from the technical side – they acquire functional know how as well but have technical roots. Even so, I see it as a BPX role – however, I believe there is a need for a functional liaison to that Solution Architect – one title for that could be Process Expert. Ed notes similarly in his comment: “The two roles are close, but they should actually work together.”

    This person might have a combo of SAP functional skills, process modeling and web collaboration skills, enough SAP tech skills to talk intelligently with someone like Ed, and maybe eventually NetWeaver BPM/BRM skills. Does this role exist today? No. Maybe it never will = after all, all functional SAP types are going to have to acquire some of these skills.

    Customers, as we know, will have the final say, but I’ll be surprised if we don’t see some type of SAP Process Expert role emerge at some point, only because functional SAP skills are so often siloed, and I see an emerging need for broader process know-how.

    Let the market decide is always a good principle for the final say in these roles, but whether or not such a pure role ever emerges, there’s no doubt in my mind that those SAP functionals who acquire some flavors of those skills are going to be in a better career position going forward, which to me is why BPX matters and is not just SAP’s hype. But how to make it stick and be relevant and engage functionals as well as SDN engaged technicals – that’s another long comment for another time.

  • I was pleasantly surprised to search in SCN Career Center and find that people actually are looking to hire SAP Business Process Expert !
    And guess what, I also saw Solution Architect jobs!

    Go BPX!

  • Hello Vijay,
    Thanks for this blog , will help to re-think and re-evaulate. Btw, as per the any Architecture group, at high-level following are the roles  in any of the organizations ( my understanding):
    Enterprise Architects- resposnible for enterprise wide architecting
    Solution Architects- Project wise solution architecting
    Technical Architects- Expert in any of the technical domain
    Then Developers, Managers and Domain experts.

    Can we say the BPX bridges the gap between Domain/Process Architects with Technical Architects ? i.e Process expertise with technical insight ??
    but can we compare BPX with Solution Architects- I think no .

    Anyways good discussion

    Regards, Krish

  • it’s kind of simple…IMHO

    BPXer is a generalist who knows a little bit about everything, but is a real specialist in one thing or a go-to person if something is not working and no one knows how to fix it…more like a plumber than an architect…and we all need plumbers, don’t we?

  • This is a good discussion. I like it. I am a great fan of Business Process Expert forum. Business Process Expertise is beyond technology, but technology is required to run Business Process more effeciently.

    This forum is more about getting the business process (more functional) folks together so that they can relate to each others experience, though it has not got to the level where it is intended to get to.

    I don’t agree that functional guys cannot pick up technology skills. I have many examples of  people who have done this.

    When it comes to more complex industry based solutions business process – functional expertise is very important

    But loved this blog, should be added to the career area also



    • Thanks for taking time to comment, Muthu.

      I just want to clarify – I did not say functional guys cannot pick up technology skills. Of course they can. What I said was that in my experience, more technical guys pickup functional skills than the other way around. If your experience is that this is not true – I respect that.

      • Vijay,
        No issues, given your project experience you should be correct. But in few areas the other way works significantly well. But given that we work in technology company, the population is skewed towards more technical people acquiring the functional /business process expertise as they gain experience. The best part with SAP is, that is the uniqueness, a combination of business process expertise and the technical knowledge wins.
        Kudos for this blog and hopefully we can have more adoption of SAP BPX, which should be the go to place for every customer or business user to understand how business problems get solved with innovative technical innovation and solutions