Outright disclaimer: I have picked on Project Roles Puzzler from EnterpriseGeeks great thought-provoking podcast and continued on. If you do not know about what I am saying then first check out
eGeek Podcast and then
Solution Architect vs BPX before starting this blog.
In the podcast roundtable a number of interesting points were brought up and later Vijay blogged about his thoughts on Solution Architect vis-a-vis BPX role. I do not want to get in the debate as to whether these two roles are complementary or same or even two sides of the same coin. But Jon Reed did mention in the podcast that the BPX role as being envangelised by SAP and not seen much of market traction yet. In the podcast the other point that came up is Solution Architect role varies depending on the project size and scope (how many modules / business process areas). Also the role needs more of Functional expertise over Technical expertise (assuming there is a Technical Architect role in the project / company).
There was one more important point made by Leonardo reminding us of the Y-path brought out by SAP some time back (most of us have forgotten probably). One thing that came out from the podcast is what path is available for most of us SAP Functional and Technical developers / configurators as we grow in our organisation. Ed did bring out the obvious choice - Project Manager role and how that is not really something that the true "developers" want to move into. Well its not different on the Functional consultants side also though I have to admit most of my colleagues have moved on to the "other obvious side" with time and its a challenge for me even now not to move over to delivery / project management.
One thing that was coming out of the discussion is that Solution Architect role in context of a company i.e. an internal role. While this is very true at the same time from the Consulting / System Integrators perspective there is need for suitable role corresponding to that. They may go by same title or something else but the core role requirements remains focussed on developing a solution using package application (assuming SAP) with minimal amount of technical enhancements and bolt-ons to plugin the white spaces.
From SI / Consulting company perspective Architect kind of roles focused on business process areas (like Plan to Produce, Order to Cash, Hire to Retire) is definitely required. In my experience they go by different names Lead Consultant / Subject Matter Expert. In fact specialisation by Industry is vital as Architect role requires knowledge of the industry-specific nuances in the business processes. For example Statistical Forecasting based Demand Management may make sense for commodity like product lines like Pharma, Chemicals(not specialty chemicals) but more of Collaborative Forecasting is the order of the day in case of Consumer Electronics, FMCG type of industries. Its important for the Architect to bring in this industry perspective because he/she does need to play an important role in another area - Change Management. In fact the Architect is expected to pitch in developing business case for a particular solution / new projects.
Whether the Solution Architect matures from a Business Analyst or Configurator role is immaterial. As a Solution Architect he/she needs to have the "right" mix of SAP Functional knowledge (read SPRO Config), Industry-specific Business Process knowledge (not Process Modeling and Composition as highlighted in BPX role) and of course fair amount of technical knowledge to be able to design enhancements or more importantly make the decision to go for a bolt-on application. Of course in today's rapidly changing environment which is seeing lot of innovation even in classic enterprise applications it is important for Solution Architect to have a fair amount of technical expertise. Being Technically savvy need not be being "Geek" but nimble enough to explore and try out new technology shifts. To give an example playing with Enterprise Services to understand how to use them in context with the application, Process Modeling to understand how to break down your business process requirements in Visual Composer and build up a composite application, concept of Business Rules Management etc. All this with the aim of staying with innovation curve so that when the application is main-stream you can build and implement a solution and not get left behind.
However as the title suggests at core he/she is "Solution" focused not just "Technology" focused. The role requires starting from business processes that makes the company successful and competitive amongst its peer group, benchmark these processes to industry best practices and then derive an IT Solution using suite of functionalities available in the package application. While an ideal IT "Solution" would not require any enhancement (as the package application has functionalities covering the industry best practicies) - that is clearly not the case and the Architect needs to identify the white spaces within the package application and plug them with enhancements (if possible) or consider bolt-ons.
To me this is the role and responsibility of a SAP Solution Architect. Depending on the company (size and breadth) you can have variants where Process Architects focus purely on the business process, change management / training, Technical Architects focus on the technology platform and overall IT strategy but Solution Architects do have their roles and responsibilities cut out in the middle path.
