SOA and Project Management

We’ve discussed the impact of enterprise services and Enterprise SOA on a number of occasions (in many of the links collected here and here especially).  My focus has been on complexity and how Enterprise SOA is part of the transition where “every project becomes a program”.

One of the little discussed impacts — on project managers, that is — is the increased interaction among business process experts, business users, and technical teams.  Demir Barlas has a link rich post on the SOA in SAP topic here.  I had seen some of these links before (Dennis’s post in Demir’s quote below), but Demir has pulled together other good links that serve as primers on the topic.

The impact of SOA on project management practices is alluded to in Demir’s last full paragraph:

Finally, because SOA is right at the heart of both business processes and enterprise applications, it brings together what you might call the suits and the geeks. SOA is making these disparate communities speak each other’s languages, as you can discover on SAP’s BPX forum.

In particular, project managers must dedicate more attention to their stakeholder management practices.  Many of these stakeholder groups are new to SAP projects.  As Demir notes, they don’t speak the same language.  Business and transactional users also have very different expectations about how the project should engage their time and attention.

Before you manage your next SAP Enterprise SOA project, take a few minutes to poke around on SDN and BPX to get a feel for the discussions.

Upgrade tips…what’s worse than a modification?

I was going through a list of upgrade tip articles collected by Demir Barlas (here) in his SAP Watch blog (here).  Most of them look unobjectionable, but one touches on a pet peeve.  Amit Jain calls them out here (original SDN post here):

6) Cloned programs — Cloned programs are customer programs copied from standard programs… [they] are coded by copying the standard program to a Z-program, having the standard includes or standard function modules.  This causes issues after the upgrade, because the standard includes or functional modules might not work with our custom code.

Clones are insidious, because developers don’t think they’re system modifications.  They’re right: they’re worse than system modifications.  I’ve never heard a compelling case for cloning.  Directly modifying the standard program — while not exactly encouraged by SAP — is a more straightforward and honest approach:

  1. There’s no more pretending that a clone isn’t a modification.   Taking standard code, modifying it, tacking on a “Z” to the name, then claiming it isn’t a modification seems disingenous.
  2. Clones hide from SAP monitoring and other system features.  In an upgrade, SPAU has features that attempt to account for mods when updating the code base.  It is much simpler to deal with mods in SPAU than by searching through the new SAP program.
  3. Clones create non-value added work.  For example, all of the dependencies to/from the cloned program have to be re-established manually during an upgrade.  Never mind the manual bookkeeping involved…
%d bloggers like this: