It’s always exciting to attend a large conference bustling with like-minded people, especially when the subject matter teeters on the cutting edge of a new market space, and BrainStorm’s Business Architecture Conference in New York City last November was no exception. It was my first Business Architecture conference and BrainStorm’s second, but no college curriculum could possibly rival the depth and scope of the information imparted to me during those two days. From the opening remarks through the final wrap-up, I was intrigued and completely captivated as speaker after speaker presented their vision of the current state of Business Architecture. It was like living in the future.
The conference presenters possessed quite a broad spectrum of opinions regarding the current crop of Business Process Management (BPM) software vendors and the capabilities expected of their products. For example, Janelle Hill of Gartner reduced the goal of a BPM system to its most basic premise: “The real value comes from making your processes visible. I don’t need a programmer to open the code and tell me how the process works. I can see a picture of it, independent of its implementation. If it’s visible, I can manage it.” Colin Teubner of Forrester Research observed, “Of the five core, key values [of a BPM system], four of them are focused on business value.” Author Ralph Whittle stressed that “BPM systems need to expand their focus on the enterprise blueprint and business architecture”, yet become more “holistic in nature”. While these are all laudable goals, a visit to the conference vendor room quickly demonstrated that the BPM industry still has a long way to go before making good on these promises.
For software that is theoretically targeted to business users, I found that the BPM systems on display at the conference ranged from unintuitive to needlessly complicated. Adding to the complexity, all of the products were implemented as multiple modules, with each module aimed at some niche of the overall scheme, and each boasting its own, shifting syntax. Notwithstanding a few overly-cute graphics, the products seemed to be aimed more at Information Technology (IT) professionals than your typical business user. After all, how many C-level managers understand Entity Relationship Diagrams – or want to?
The BrainStorm Conference was my first wide-scale exposure to BPM software; and while I was impressed with many of the capabilities of BPM systems, I was disappointed to see the manner in which they chose to represent process and data. Every process and rules engine I saw was based upon flowcharts – 50-year-old technology! – and a panel hosted by Knowledge Partners’ Barbara von Halle sadly predicted that there was nothing better on the horizon. While flowcharts may be fine for documenting simple subsystems, when it comes to designing or implementing anything of any complexity, they quickly degenerate into a mishmash of indecipherable bundles of spaghetti. Data modeling also seemed to have gotten the short shrift; and aside from legacy ERD’s, graphical data models rarely exist, and some offerings appear suspiciously like COBOL (merely a 40-year-old technology).
To my mind, one comment made by the Conference Co-Chair William Ulrich neatly summed up their shortcomings: “BPM systems are fractured across too many modules that have insufficient cohesion. What’s needed is a simpler, more-uniform approach to modeling using a single, common syntax.” Amen! Truer words were never spoken, but the devil is in the details. How could such a goal be achieved? Perhaps the best approach would be to put the current implementations of BPM systems behind us, and graduate into business architecture systems instead. But what features would a quality BA system exhibit?
Certainly a BA system would be based on graphical models, not on legacy lexical languages. The models should be kept simple enough for management to understand and use, yet precise enough to meet the requirements of automation. Toward that end, it should employ a single, cohesive syntax that would span the entire spectrum of process and data modeling needs, from initial requirements gathering through final implementation. The models would be easy to learn, and be just as readily understandable to the business-centric user as they are to the technology-centric user, allowing senior management to communicate directly with their technical staff for the first time. Unlike flowcharts, the architecture would handle complexity gracefully, ideally possessing unlimited scalability. The software would be embodied in a single, tightly-integrated product – a BA “system” as compared to the omnipresent BPM “suites”. Rather than aiming for 100% code generation, a goal mentioned by Forrester’s Ken Vollmer, the goal instead would be 100% code elimination via process and data models that execute directly. This, in turn, would empower business process owners to define, design, and develop their own applications without assistance from IT. Such an ideal business architecture system would be simple, intuitive, and easy to use. In short, what Windows was to DOS, a BA system would be to BPM suites.
A tall order, no doubt. In the next installment, we’ll take a look at a business architecture system which addresses all these aspects and more, a system whose capabilities form the benchmark for the next generation of BPM systems and agile development, or, if you will, for the first generation of business architecture systems.
Of course I’ll be attending BrainStorm’s third Business Architecture Conference being held this April, and I expect it to be another interesting and exciting one. For there’s a business architecture asteroid hurtling toward planet BPM, and the dinosaurs called flowcharts and ERD’s sit squarely in its path. Who wouldn’t want to be there to see what happens when it hits?
