Good: (from the BPMS vendor and Business End-User perspective)

1. Business End-Users are solving problems with BPMS technology.
2. This group didn't feel there was so much confusion in distinguishing BPM as a management theory and BPMS as an IT solution set that supports that management theory, in contrast to how much of the rest of the conference was characterized.
3. BPMS vendors are automating organizational and departmental level orchestrations ('small BPM'), but no large scale Inter Agency partnerLinking reported or known ('big BPM').
4. Many are asking for BAM/BI and some have extended with CEP capabilities.
5. Federal Lines of Business are moving the overall emphasis of Federal Agencies from vertical integration to horizontal interoperation.
6. Other target capabilities that fit BPMS;
   • Operationalizing ABC with BAM/BI, instead of just creating timesheet buckets that aren't correlated with actual info-worker task efforts
   • Non-repudiation of Regulatory Requirements
   • Competitive Sourcing in-out sourcing decisions require public and/or private enterprises to prove Most Efficient Organization status, and BPMS technology is clearly applicable to quantify what MEO is.
   • Other large opportunities for using BPMS to retain institutional memory of Federal Gov functionality through Human Capital training and succession planning as the baby boomers retire.

Bad: (from a Chief Architect's perspective)

1. BPMS appears very immature, for example wrt OMG BMI standards. We only have BPMN 1.0/1.1 in most tools, and clearly all the OMG BMI standards are relevant to 'big BPM' (OSM, BMM, SBVR, BPDM/BPMN2.0, etc...)
2. Most acknowledge the design and runtime portability problem, however only some appear aware of or in support of BPDM and BPMN 2.0 and what that promises.
3. BPMS applications are not themselves service oriented - example given was perhaps a SaaS delivery of the transformation from design language to runtime language that occurs in every BPMS (mostly BPMN'ish to BPEL?). Desire would be for all functionality to be provided (regardless of mode of delivery) in a more modular used 'ala-carte' fashion, which is an SOA extension of what would be required to OEM in/out of other suites anyway. Don't just make these functional modules well designed and decoupled within the runtime platform, literally expose the BPMS service components as independant services that could be deployed independantly.
4. Even with Fed LoB's, the FEAF, and the FEA, there is no real process related focus coming from the Federal EA or CIO community, and this is sorely needed to embrace BPM as it pervades the 'business/data/applications/technology' of the FEAF, yet doesn't specify how missions (BRM) interoperate across agencies using service components (SRM) in the FEA. If this were better articulated (a CPO in the Federal Gov is more likely to be an HR related Chief People Officer), and BPMS suites were more mature, there would be a much better market for BPMS vendors into the Fed Gov beyond single Agency specific (and usually small departments within a single Agency) 'one off'' solutions.

Ugly:

1. Most Agencies still struggle with legacy modernization, or the ability to 'wrap and adapt' thier legacy systems in order to be able to participate in composite applications that choreograph Inter-Agency orchestrations.
2. Agencies are still caught in COTS customization versus SOA based service specialization.
3. [The ADM community in OMG and related standards (KDM, GASTM, others) are relevant, useful and mature in my experience, see adm.omg.org.]
4. The Federal SSP's and eGov implementations do not expose (or have?) service provider/consumer specifications, the community is still struggling with the basics of exposing service specifications, and therefore are a long way from being able to add QoS to Federal mashups, much less orchestrate or choreograph composite applications.

g.thomas@gsa.gov