The second keynote of the day was Jim Adamczyk of Accenture on how standards play a critical role in creating value with BPM. He said that they have about 40 current projects that are focussed on BPM — the discipline of creating process-centric business and IT architectures — in addition to those doing “low-level workflow”, although it’s not completely clear where the distinction lies. They’re early enough with all of these projects that he couldn’t even list client names, which means to me that Accenture is a bit late to the game here.
He moved on to talk about the value of standards, both notational and serialization, covering much the same territory as I did in a webinar recently: notational standards like BPMN allows users to move between different modelling tools more easily, and serialization/interchange standards make is easier to move processes from one system to another.
He made some great points about how changes are specified: the tendency is for business to actually specify the system change (e.g., add this function to this screen) rather than focus on their business process and KPIs — I struggle with this constantly with my customers, and have to constantly remind the business side to state their requirements, not try to design the system. The problem is that IT has been letting them do this for years, either because it’s easier to not have to learn enough about the business to do the specifications and design based on actual requirements, or because it effectively passes the buck for any mismatch between requirements (what the business needs) and specifications (what the system does) to the business side. But I digress.
Adamczyk stated that a client’s need for standards depend on their entry point to BPM, although I’m not clear what he meant by this. He said that IT almost always drives standards and that business rarely wants to implement standards; I completely disagree with this in the case of BPMN, since there are significant tangible benefits to the business side from having everyone use the same modelling notation, and I have few business-side clients who don’t recognize this. I agree that the business side doesn’t explicitly care about XPDL or BPDM or BPEL or whatever is being used for serialization, but they will start caring if it means that they can’t do round-tripping between the modelling and execution environments. However, he’s deep in the weeds talking about WSDL and LU6.2, so I think that he and I have different views of BPM standards. Since he went on to talk about how Oracle Fusion is one of the most commonly used BPM platforms amongst their client base, I think that we have different views of BPM, too.
Then he made the comment that if you use of the BPM suites (like Lombardi or Appian) that you probably don’t care about BPM standards, which couldn’t be further from the truth. Many companies use a separate process modelling tool even though they use a BPMS, so both notational standards and interchange standards are critical. They’re even important between tools from the same vendor, such as Lombardi’s Blueprint process discovery tool and their TeamWorks BPM suite, which uses BPDM for process model interchange. And there’s the advantage hiring a new analyst who already knows BPMN, even if they don’t know the particular BPMS that you’re using, because that particular standard has become so widespread, and the reduced training requirements that result.
He does have a future view for the perfect world enabled by standards that includes federated orchestration, consistent policy and governance, dynamic and predictive infrastructure, and consistent methodology/training/tools; ranging from consistency on one platform to coverage of all platforms.
Although an engaging speaker, Adamczyk seemed to spend a lot of time apologizing for things that might be missing or inaccurate in his presentation: according to him, he doesn’t really know a lot about BPM standards, nor about the utilities vertical (the industry of his unnamed client example). He also said that he’s here as a proxy for CIOs (this is billed as a “CIO keynote”) rather than as an actual CIO. Enough, already: tell us what you do know, not what you don’t know.