Enterprise Geeks Podcast – Project Roles Puzzler


Are BPX and Solution Architect Roles a Myth?

Listen in with your Enterprise Geeks friends in this content gold episode where they host a roundtable discussion regarding IT Project Roles. This week, hosts Thomas and Ed are joined with experts and fellow eGheads Jon Reed of JonERP.com and Leonardo De Araujo of Beyond Technologies. The discussion aims to clarify traditional Functional and Technical roles as well as the newcomer roles of BPX and Solution Architect.

This episode was originally planned to cover both the topics of the SAP Community Developer License and the IT Project Roles roundtable. Both sessions had so much great content, we wanted to make them both available separately in their entirety. Because of this decision, we have split this episode into two separate parts. You can check out the first part of this episode here.

Dearest eGheads, we need your show ideas. If you have questions, suggestions, or topic ideas for future episodes, give us a shout here. Enjoy!

Running Time: 71 minutes

Talking Points

  1. 00:10 – Segway into the Roundtable
  2. 00:45 – IT Project Roles Roundtable Discusssion
    • 04:21 (Ed) Setting up the stage
    • 06:45 (Jon) Is BPX a new role or a refinement of existing roles?
    • 12:33 (Leo) Clearing up the “Functional” role?
    • 16:05 (Jon) Origins of the term BPX
    • 19:46 (Tom) Does SAP use BPX in their own environment?
    • 24:55 (Ed) The importance of a business process champion
    • 26:53 (Ed) The parallels of the BPX and the Solution Architect
    • 28:25 (Tom) Why you need to value technical skills and technical people
    • 31:25 (Leo & Jon) Where functionals and technicals fit in the hierarchy and why there is a growing need for more senior roles like BPX and Solution Architect
    • 37:20 (Ed) Where do Project Managers fit into the picture?
    • 41:10 (Thomas) All projects are not created equal
    • 43:05 (Leo) The Y Path
    • 46:27 (Jon) Defining and choosing meaningful career paths
    • 48:35 (Ed & Jon) Enterprise Architect vs. Solution Architect
    • 51:55 (Thomas) Standardization vs. Customization
    • 54:53 (Leo) Don’t forget about Change Management
    • 56:42 Final thoughts from the crew
  3. 61:18 – Wrap up with Apple Tablet fever and Football fanatics

15 responses to “Enterprise Geeks Podcast – Project Roles Puzzler”

  1. Jon Reed says :

    Guys – time for my traditional post-podcast comment.

    Glad you split this up into two – one long podcast would have been a beast, we waxed on for long enough on this one – but separate, two podcasts I definitely enjoyed.

    There were two points I took away upon listening to this. One was Ed’s point that we need other fleshed out visions of technical/functional career paths that don’t always railroad advancement into Project Management, which is a hat not all want to wear. “Solution Architect” is starting to firm up as such a role in SAP environments, I can only hope the functional equivalent of such a role, Process Expert or what have you, also comes to fruition as I believe it could be important. Right now, as Leonardo says, the closest to that might be functional team leads, but I see those as a bit narrower in scope in terms of understanding SAP configuration (functional team lead) versus overall process/industry know-how (process expert) – including modeling tools, workflow collaboration/web 2.0 tools, and perhaps as Leo calls form, some change management to boot.

    Next key point: so the first near-BPX role is actually gaining traction: Solution Architect, and Ed, since you are one, it’s not bigfoot – unless of course you are bigfoot. Hmm…but in all seriousness, that role is one we see formalized in many companies, even a Dice.com search will generate some decent results. However Enterprise Architect, as we discussed, is a role I see differently so that needs clarification. You could argue the Process Expert role is bigfoot, and that may be true in that it’s not on many business cards yet, but I’d urge functional types (and aspiring techies) to start adding those skills now rather than wait for “Bigfoot” to be spotted. 🙂

    Finally, while we geeked out for an hour we left out another increasingly relevant topic: lean process methodology, the companion in some ways to agile and scrum on the technical side. I view “lean” knowledge as increasingly relevant, not in a futuristic propeller hat way, but right now. Dagfinn Parnas, fellow SAP Mentor and eGhead, did an excellent TechEd video on definining Lean, Agile and Scrum: http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/16323

    Guys, I look forward to checking out the future ones in this job role series!!! Thanks for the invite, had a blast.

    – Jon

  2. Vijay says :

    Some one at SAP thought of the term BPX and promoted it – not the market. Market on the other hand created several types of “Architect” roles. Neither has a crisp definition – and they both need a techno-functional skillset to succeed. So I don’t think there should be any divide between Solution Architect roles and BPX.

  3. Ed Herrmann says :

    @jon – thanks for the great comments as always. I hope to have Dagfinn on the show at some point during our agile discussions. Re: Lean Methodology and Lean Knowledge, can you explain that a little more in context of the roles conversation? Do you feel that agile development is to a Solution Architect as lean knowledge is to a BPX. Please expand if you don’t mind. This is a very important subject that we hope to address in upcoming episodes.

    @vijay – thanks for the clarification. Can you expand on your thoughts about no divide between the two roles? Are you saying that these shouldn’t actually be two separate roles at all? I’m definitely interested in hearing more of your thoughts on this.

  4. Leonardo De Araujo says :

    @Jonerp – Great summary.

    @ALL – What I really think we need to do is to continue with this definition of the possible “hats” we have in SAP projects. All this from a methodology point of view. If indeed they represent how the companies/projects are structured, well, that is another story.

    Just a quick note to say to all that I had a great time and really enjoyed being part of the podcast.
    Let me know how I can further contribute to this.

    Leonardo

  5. Vijay says :

    @eWH I started typing here, and it kind of got long. So posted it as a blog on SDN http://weblogs.sdn.sap.com/pub/wlg/17689

  6. KK Ramamoorthy says :

    Not to pile upon what has already been said but to add my few cents, here is my attempt to define each role. Sorry for this big comment and thanks for your patience if you made it through
    Business Process expert: A person who has deep subject matter expertise in the business processes in his/her industry or line of business; keeps up to date with the latest and the greatest initiatives and process re-engineering within the industry/LOB. For e.g., in utilities industry someone who knows how the business process for demand/response work, how AMI scenarios work, how to improve shared services etc. This person doesn’t align with a solution (SAP or Oracle) but aligns to the business. In a typical SAP project, this person conducts workshops (client facing) to identify the processes that can be improved with the help of technology and builds process flows in a tool like ARIS to capture the ‘to-be’ process flow.
    Functional Consultant: A person who knows how to configure the solution/package and knows specific capabilities and short comings of a particular product. In a SAP project, typically configures the system based on business process models that were synchronized from ARIS to Solution Manager, for example. This is already becoming a commoditized role and soon will be performed remotely in the same scale as development.
    Solution Architect: A person who has broad experience in the solution and/or technology area. Probably this role started in custom development projects where the solution is built from scratch. The solution architect is responsible for conceptual design of the solution, for e.g. what database to use, what language to use, what hardware to use etc. In SAP world, this role is used for developing conceptual design for user interface strategy, infrastructure related strategy (for e.g. backup procedures), integration strategy etc
    Technical consultant: A person who has subject matter expertise in a specific area of the solution or technology. For e.g., CRM tech consultant, BI tech consultant, ABAPper, PI constultant etc. This role, as we know is already commoditized to a great extent and will only continue to be so in the future.
    Enterprise Architect: A person who acts a part of enterprise level governance body around IT strategy. Doesn’t restrict themselves to a solution or technology but could deal with areas like enterprise wide document management strategy, security controls (both internal and external facing) etc. Mostly enterprise architects comprise a design authority for an enterprise, especially those that span across multiple countries or big companies.
    As we can see a functional consultant can wear a BPX hat if they are industry major and package minor. A Solution Architect can wear a Technical consultant’s hat if they are pretty hands on and well experienced in their trade.
    @Vijay, with my attempt at these definitions, I don’t agree that BPX and Solution Architect are the same rather I agree with Ed’s point of view. Also, the reason I think you see lesser functional consultant understanding how technology works than the other way round is because technical consultants are service providers and they cannot develop quality product unless they understand the business requirements.
    @Ed, regarding contact in internal IT, isn’t fellow egHead, Martin Lang a IT director at Newtown Square. May be we can tap on him about internal IT stuff

  7. Vijay says :

    @KK – your definition of BPX is apparently different from mine. I just checked out that initial intro to BPX blog that Mark Yolton wrote http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/3637. Do you agree to that ?

    Since SAP is a packaged app, the usual pitch is that SAP already has figured out best practices, and if you can model closely to SAP’s standard – then you get a great solution with less investment. If a BPX does not have to care for what SAP has and builds another view of the business ground up, I would argue that SAP might be the wrong choice to begin with in this scenario. Where is the advantage in buying a packaged application any more?

  8. Matt Harding says :

    Hi All,

    Just a small note coming from another self-proclaimed Solution Architect…I believe there are two types of Solution Architects which are both equally as important in the marketplace:
    1. Is as discussed above – Broad Solution Coverage with a technical slant – Basically the guy who knows what it will take to implement the solution in detail (understanding the entire NetWeaver stack and not just ERP modules – or SAP for that matter), but heavily reliant on Functional expertise when defining a solution in order to ensure it doesn’t become a complete custom build 😉
    2. The other is the pre-sales style Solution Architect who is very functional oriented and essential when selling SAP or new modules to customers. These people can confidently convince a customer about the functionality of the product and make it seem like everything is just configuration (I’m not trying to sound like I’m joking there).

    Both types are pretty rare unfortunately, but being the first type of Solution Architect myself – I always found it an awesome combination when you get both types together to design a solution. (Shout out to Richard Hodges and Lodewyk Steyn who the best Type 2 Solution Architects I’ve worked with in the past).

    Cheers,
    Matt

  9. KK Ramamoorthy says :

    @Vijay, I see your point but I don’t necessarily agree with Mark’s definition. Marks definition ties the BPX to technology or a solution but if you look at the term itself, it talks about Business Process and expertise in it. Some may say, what’s in a name, but it is important that we get the terminology right because it should make sense to someone who is new to SAP world.
    I also saw some interesting comments on your weblog around BPM not being useful for BPX. But if you consider Mark’s definition, BPM shouldn’t be difficult in as-is state for an application specialist to use, right? In my current project, the finance team lead is a guy who has been in the industry for quite some time and has never run a SAP project. But in this project, he is conducting workshops and providing business process flows to the functional consultants (through ARIS), who in turn or configuring the SAP system to suite the needs. Now, this is a real world example where I was able to correlate BPX vs Functional consultant. Also, in this project, my role is a solution architect and I perform many of the duties highlighted in my definition.

    For SAP world, may be we should rename Business process expert to Packaged Process expert or Packaged solution expert and the solution architect to Packaged solution architect?

    Regarding your comment on buying packaged solution, truly agree that was one of the intentions when companies went for SAP. Industry in early 80’s (or even earlier) saw business process re-engineering which in turn led to best business processes which could be packaged in to applications. But we also know that, today, business processes are changing more rapidly though not drastically, with continuous changes in customer expectations, globalization, environmental impacts and technology improvements. So companies are looking for fine tuning their processes more rapidly instead of waiting for a packaged vendor to provide solutions based on best business practices. I think companies can use the technology foundation provided by SAP to fine tune their processes as needed and yet fall under the maintenance umbrella of SAP for the technology foundation.

    Hope my arguments makes sense. Your thoughts?

    KK

  10. Vijay says :

    @KK – agreed. I truly believe SAP should relook at the term BPX and take it to the next level. At the moment, it is a poor cousin of SDN. And we all have our own definitions, and lot of people seem to not like SAP’s definition of BPX.

  11. Jon Reed says :

    Guys, I’m a little “commented out.”

    Vijay, I posted a comment on your blog regarding my belief that there should be a functional equivalent for Solution Architects for functionals to aspire to.

    Ed, as for this: “Do you feel that agile development is to a Solution Architect as lean knowledge is to a BPX. Please expand if you don’t mind.”

    Short answer: yes. That is it in the nutshell. I’m still developing my thinking on this point but I’ll look into it more and get back with you further on details. Bottom line: functionals need to be grappling with the business implications of agile programming and agile business philosophies.

    – Jon

  12. Vijay says :

    Now that you mention Agile, Jon and Ed…
    I am right in the middle of a big program for inventory costing, and we are doing agile for several parts of it. So far – it has been an impossible thing to scale, despite every one making an honest effort. I am fast approaching a hybrid of agile/waterfall . As soon as I have a grip on how this works, I will post a blog with my thoughts.

    Agile worked so well for the smaller gigs that I was really hoping it would work in the bigger gigs – but so far, the experience proves otherwise. Oh well – we live and learn

  13. Ed Herrmann says :

    @Jon – agreed on “agile business philosophies”. The most difficult thing to overcome when trying to stay quick and agile during projects is old culture and tradition.

    @Vijay – I have similar experience to you. Smaller projects are easier to follow agile development methodologies to a tee. However, I’ve never agreed with the agile zealots in the world. Being agile is all about adapting in the face of change. The couple of large projects that I have successfully implemented an agile approach with my team, has been, and I have previously used the same term as you, a “hybrid” approach.

    Thanks to both of you for these comments, and we hope to address them in our soon coming episodes on agile development.

    Cheers,
    ewH

  14. Somnath says :

    Though late catching up with this podcast and Vijay’s blog, I have pretty strong thoughts on what is or are note the responsibilities of a Solution Architect role. Rather than being verbose here I put in a blog http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/16922 in SCN.
    BR,
    Somnath

Trackbacks / Pingbacks

  1. Enterprise Geeks Podcast – SAP Community Developer License - April 3, 2013

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: