Enterprise SOA for the Skeptic (Part I): Finding Tangible Incentives to Create Win-Win’s in Multi-Player Scenarios
A lot of blogs here at SDN discuss Enterprise SOA as if all “actors” or “players” in a prospective Enterprise SOA situation are already “rational actors” and “consenting adults”, or can at least be eventually convinced to act that way. These blogs also tend to discuss Enterprise SOA as if the only way to convince people to use it is to convince them to undergo a searching re-examination of their core business processes, on the grounds that Enterprise SOA will enable them to dramatically improve these core processes. And these blogs are good in so far as they go, because there have to be at least some organizations out there (hopefully a lot of them!) in which the key decision-makers are rational actors who see the benefiit of subjecting their core business processes to searching re-examinations, and then improving these processes via Enterprise SOA. But surely we can all agree that there are plenty of organizations in which: i) key decision-makers are more selfish than rational; ii) the problems that exist in core business processes have deep deep roots in various organizational factors that are impossible to address. So for that reason, I attempted in these two blogs here: “Mass-Market” versus “Niche” Enterprise SOA Before BI there was AI: will Enterprise SOA bring it back? to outline another implementation strategy for Enterprise SOA – one which does not depend on the willingness of key decision-makers to become rational actors willing to change their core business processes. In both these blogs, I suggested that Enterprise SOA implementations are just as respectable if they leave core business-processes alone, just as they are, and simply “overlay” these processes to correct certain problems after the fact rather than before the fact. But even in cases where there is good reason to use Enterprise SOA to correct problems “after the fact” rather than “before the fact”, one is still going to be confronted with the problem of key decision-makers who: iii) understand prefectly well how Enterprise SOA can actually help them; but: iv) don’t see how they are going to benefit personally in tangible ways from an Enterprise SOA effort. (By “tangible ways”, I don’t mean letters of appreciation from their bosses, awards from professional associations, or the satisfaction that comes from a “job well done”.) And therefore, if you asked me what is the key capability that I would want in an Enterprise SOA “change-agent”, I would have to say that it would be the ability to figure out tangible incentives that can be used to convince key decision-makers to use Enterprise SOA “after-the-fact”, in order to correct problems that arise from bad business processes which are too deeply rooted in organizational factors to change. Furthermore, I’d like to illustrate this point by considering two “after the fact” problems that arise in military logistics due to certain business processes that have proven impossible to change over the past forty years, and in fact, have gotten worse rather than better, What you have to understand first about these two problems is that they occur in the following setting. 1. There are different budgets and chain of commands for “developmental” military logistics and “maintenance” military logistics, and the budget for one can’t get bigger without the budget for the other getting smaller. (So in other words, there’s no reason for cooperation between the two chains of command.) 2. The folks who do actually do maintenance work on a weapon system use two kinds of information: information provided by players on the “developmental” side of the house and information provided by players on the “maintenance” side of the house. 3. The “developmental” players include the one or more weapon system vendors (usually a prime and multiple subs, sub-subs, etc.), plus the PEO (Program Executive Office) that is in full life-cycle charge of the weapon-system (usually an actual “green-suit” colonel and his/her military and non-military staff), plus the general who heads up the “developmental” side of the house for all weapon systems 4. The “maintenance” players include all the non-military “apparatchniks” (civil-servants) responsible for procuring parts, setting the rules for what parts can be bought/repaired/replaced/removed where (field unit, read unit, depot, vendor site), plus the general who heads up the “maintenance” side of the house for all weapon systems. 5. Due to so-called “procurement reforms” implemented in the late ’90’s, the vendors on the “developmental” side of the house are under no statuatory requirements to provide “sensible” information to the “maintenance” players. Yes – the “developmental” vendors must by law provide certain information to the “maintenance” players, but there is nothing that forces them to provide information which leads to optimal results in actual maintenance situataions. 6. Furthermore, even if there were statuatory requirements insisting that “developmental” vendors must provide “sensible” information to the maintenance side of the house, these “developmental” vendors would insist on getting paid for the work required to collect this information. 7. Even though the colonel in charge of the weapon-system PEO is no longer someone simply rotating through the slot to get his or her ticket punched on the way to making general, i.e. even though colonels are now told that they will be held accountable for good decisions affecting the entire life-cycle of the weapon system long after they have rotated out of the PEO, these colonels have no particular personal incentive to focus their attention on maintenance problems that arise due to the fact that the “developmental” side of the house doesn’t talk to the “maintenance” side of the house. Due to factors (1-7) (and others which may be brought up later), two kinds of maintenance problems often arise. I mentioned these in the two blog posts I linked to above, but will briefly restate them here: a) due to lack of coordination between “developmental” and “maintenance” informatiion, weapon system components in need of repair frequently wind-up getting unnecessarily shipped upstream (from field to rear, from rear to depot, from depot to vendor) simply because the “developmental” side of the house has not given the “maintenance” side of the house good information on what can be removed/replaced/repaired where. b) due to lack of coordination between “developmental” and “maintenance” information, maintenance workers must sometimes unnecessarily request the purchase of “next-higher-assemblies” instead of the actual assemblies that need repalcement. Now – there are plenty of folks throughout the SAP community who are intimately familiar with military logistics and will readily understand all-too-well why: v) certain core military logistics processes will never be changed in our lifetimes via Enterprise SOA; vi) Enterprise SOA will therefore never be used “before the fact” to prevent problems in categories (a-b) from occurring in the first place. Also, there are plenty of folks throughout the SAP community who understand exactly how Enterprise SOA could be used “after the fact” to correct problems in categories (a-b) when they occur. And finally, these folks will understand why Enterprise SOA is precisely the right tool for “after the fact” correction of such problems because correction of these problems involve the interactive participation of so many different players on the “maintenance” and “developmental” sides of the house. But – the key point of this post is to say – it’s not enough to know how “after the fact” Enterprise SOA can easily be applied to correct problems in categories (a-b). Rather, the critical thing is to know how to design tangible incentives that wiill actually benefit key decision-makers on both sides of the house – the “developmental” and the “maintenance” sides. So in Part II of this series, I will outline my Enterprise SOA solution to problems in categories (a-b), but more importantly, outline the incentives which I finally realized might trigger decision-makers to agree to an implementation of this solution. In this regard, it should be noted that it isn’t easy to come up with “workable” incentives to ring the chimes of decision-makers. A “Business Process Expert” really has to know what I call the “pathology” of a given organization in order to realize what incentives can and should be offered where. And therefore, I think that a lot of Enterprise SOA training for “Business Process Experts” should focus on teaching BPXers how to get up to speed on the pathology of their organizations, rather than teaching them to assume that they’ll be dealing exclusively with rational actors and consenting adults.