In the first post of this series here: Enterprise SOA for the Skeptic (Part I): Finding Tangible Incentives to Create Win-Win's in Multi-Pl... I outlined two related problems in military logistics which are well-known to all players in this particular vertical sector. Call them the "Wasteful Ship Problem" and "Wasteful Buy Problem", or WSP and WBP for short. I also argued that because the WSP and WBP arise from a complex "organizational pathology" that will never be cured in our lifetimes, Enterprise SOA cannot be used "before the fact" to prevent these problems from occurring in the first place (... because the responsible organization is prevented by its own pathology from using Enterprise SOA to re-invent the core business procesees that are causing the WSP and WBP.) And finally, I argued that: a) Enterprise SOA can readily be used "after the fact" to correct the WSP and WBP; b) Enterprise SOA is, in fact, a natural "after the fact" solution to these two problems because both problems are multi-player, multi-site, and multi-system; c) Even though it is easy to sketch out an Enterprise SOA solution to the WSP and WBP, this solution will never be adopted unless all the relevant players see that they will be rewarded by some tangible incentives for their willingness to adopt it. So in this follow-up blog, I want to accomplish two objectives: i) outline the nature of an "after the fact" Enterprise SOA solution to the WSP and WBP; ii) outline some tangible incentives that might convince all relevant players to adopt this solution. 1. An "After the Fact" Enterprise SOA Solution to the WSP and WBP Problems. The sites involved in the WSP and WBP problems fall into the following categories: a) The sites where repairs and replacements are actually done - for the sake of discussion, call these sites "Field, Rear, Depot, Vendor". b) the site of the Program Executive Office (PEO) of a given weapon system - this is where the "real-life" configuration management (CM) data for the weapon system is maintained, typically using CM files provided by the prime vendor for the weapon system; c) the site of the logistics system which maintains the data that tells repair site personnel whether they are are allowed to replace, repair, or remove a particular part at their particular site. (Note that this is not always one site - certain data may be maintained by some particular branch of the armed forces (e.g. army. navy, air force), and other data may be maintained at a higher level of organizational structure (e.g. "DOD") d) the site of the CM system maintained by the prime vendor of the weapon system and the sites of the CM systems maintained by the sub's and sub-sub's, etc. for their pieces of the pie. As you can see from this large number of sites and systems, correction of any given WSP or WBP is going to be a multi-player effort. For example, one can imagine the following correction scenario: S1. A repair person at one of the repair sites detects a WSP or WBP. This person sends a description of the problem to all the relevant players who maintain the relevant data systems (see b,c,d above), and also to a central player who has been designated to coordinate WSP and WBP correction efforts. S2. Each of the relevant players agrees that the data needs to be changed to avoid occurrences of this particular WSP or WBP in the future, and sends an indication of this agreement to the central coordinating player. S3. The central coordinating player sends out a change instruction to the prime vendor so that the required data will be permanently changed in the prime's CM system and the CM systems of all relevant subs; S4. The prime vendor also sends out emergency updates to the other relevant data systems (mentioned in b-c above), so that these systems don't have to wait for the next regularly scheduled update of CM data from the prime vendor. S5. When all players have made changes to their data systems, they send confirmations to the central coordinating player so that the change can be booked as "done". And as one can see from the nature of this scenario, it's a natural for Enterprise SOA, XI, PI, etc. 2. Tangible Incentives (Pay-offs) for the Players.2.1. Pay-off to the Weapon SystemVendors (Prime and Subs) The basic motivating assumption behind scenario (S1-S5) is that it will be cheaper to implement this scenario than to continue paying unecessary shipping costs and procurement costs resulting from WSPs and WBPs that are not corrected. So under this assumption of reduced costs, the weapon systems vendors can be safely offered a performance bonus based on their willingness to implement scenario S1-S5. This is going to be a guess-timate at first, unless all players want to spend some up-front time recording actual isntances of WBPs and WSPs and their cost. But the important thing to remember is that the vendors must be offered something, because they ain't gonna play for free. 2.2. Pay-off to the PEO XO's. As I mentioned in the first post of this series, PEO XO's are now instructed that part of their evaluations for promotion will be based in part on the quality and quantity of the decisions they make affecting the whole life-cycle of the system, not just the decisions they make affecting the near-term success of the system. So the pay-off here is a no-brainer. The XO evaluation process must be extended to include consideration of data on how many times the new correction scenario was used to ameliorate WSP's and WBP's during the XO's tenure. Any rational XO will respond to this change in the evaluation process by doing his or her best to make sure that all players in scenario S1-S5 do their best to use this scenario actively and effectively. Because there's no way that the evaluation team is going to believe that the XO's weapon system was so well-designed that few or no WSP's and WBP's occur. 2.3. Pay-off to the "Apparatchniks" (the civil servants who maintain the logistics data repositories for each branch of the services and "DOD" as a whole) Here, timing is everything. You may have to wait until the major honcho's are nearing the ends of the careers and their designated replacements have already been selected/groomed. At this particular point in time, the major honchos can safely agree to implementation of the new scenario without running the risk of being tagged for a failure. And, the designated replacements for these honchos can see that it is in their interests to play ball, if they want to stay "designated". 3. "Rear-guard" Activity to Consider. OK - you've got everybody on board and everybody loves your idea. Except: a) lobbyists for the transportation industry (planes, trains, and ships) catch wind of the fact that your idea is going to considerably reduce their clients' revenue and profits by correcting a large number of Wasteful Ship Problems; b) the vendors' bean-counters run the numbers and realize that their performance bonuses for playing ball don't begin to offset the revenue and profit they are illegitimately making from uncorrected Wasteful Buy Problems. This is when you start looking for another project, if not another job. Conclusion There are always going to be far more reasons not to implement a given Enterprise SOA solution than to implement it. But if you learn to factor in the issue of tangible dis-incentives when planning an Enterprise SOA solution, at least you'll understand why you'll never have an opportunity to work on your brilliantly architected solution which you've expressed and diagrammed in the latest and greatest language and tool for capturing business semantics.
