BrainStorm’s latest Business Architecture conference in Chicago has come and gone, and while mid-April snowstorms like the one that struck the conference are fortunately few and far between, unfortunately a constant chorus that was heard from presenter after presenter was not; to wit: business architecture is facing a crippling communications problem.
The two conference co-chairs concurred: William Ulrich lamented how Information Technology (IT) and business people don’t speak the same language, while Ken Orr reckoned that business architects spend half their time explaining business to techies, and the other half explaining technical matters to business folk. Presenter David Heidt campaigned for the obliteration of the business/IT communications divide, and Bruce Silver pointed out how this communication gap is so pervasive that BPM suites from different vendors do not interoperate well, prompting a member of the audience to voice his disapproval how this lack of integration leads directly to the dreaded “vendor lock”.
Communication is clearly a problem in business architecture, and recognizing that problem is the first step toward solving it. Without a doubt, the cause of this communications conundrum can be laid squarely on the doorsteps of the vendors of BPM suites. Although it was they who made their BPM beds, it is their customers who are being forced to sleep in them. Among the bedbugs that continually nibble away at business architecture include:
Where’s the data? Entity relationship diagrams and their COBOL-like field definitions were invented by and for techies. Foisting such arcane constructs onto business people deliberately encourages a communications gap.
Where’s the scalability? Flowcharts are a terrible modeling technique, even for small systems. Serving such spaghetti as a process automation tool is begging for communications troubles.
Where’s the integration? Clearly connecting the enterprise architecture to the nuts and bolts of its implementation as data and process is crucial to a holistic architectural model. But employing a constantly-shifting syntax across a disjointed suite of products that are difficult to integrate and hard to learn guarantees even more communication problems.
Rather than perpetuating a myriad of indecipherable modeling techniques, a better solution would be to bring a consistent, understandable business-oriented approach to the modeling of both data and process. Given the innumerable ways that process and data can mix, perhaps the best architectural approach can be found in the fractal dimensioning provided by hierarchical models.
Historically, hierarchical models have seen their share of shortcomings. Although they are readily scalable and excellent for representing recursion and decomposition, implementations of hierarchical systems have been plagued by architectural limitations, redundant data or processes, and the inability to readily reference particular data elements, among other concerns. acking any unifying theoretical framework, hierarchical modeling was generally abandoned during the 1980’s in favor of a relational model.
However, that relational model has had its share of difficulties as well. One of its most pronounced problems is the inherent disorganization of the networked solutions it encourages, leading to classic headaches such as many-to-many relationships and spaghetti-like interconnections. The relational model also introduces an unwanted coupling between data and process which limits their agility and maintainability, since a change to the fundamental structure of one necessitates a corresponding change to the other. Worst of all, since a relational model primarily addresses data, process modeling has defaulted to similarly-tangled legacy flowcharts.
The solution to the shortcomings of the hierarchical and relational models can be found in a new patented principle known as connection-based architecture (CBA). Simply put, the basic concept behind a CBA is that any system can be represented exclusively by connections. From a data point of view, that means that bits, bytes, files, tables, XML, and other technology-induced artifacts can be eliminated outright. From a process point of view, unintuitive programming languages with their proliferation of symbology and syntax can similarly be disposed of. In their place remains a single, simple syntax built upon literally a handful of primitives necessary to manipulate and traverse connections, specifically: hook, unhook, locate, iterate, and case. This dramatically-reduced instruction set is used for both data and process, providing a CBA with a simplicity and portability far exceeding any other architecture. A CBA combines the best features of the hierarchical and relational models while avoiding their pitfalls.
The benefits derived from the use of a connection-based architecture are legion. Foremost is its simple, integrated syntax for representing both data and process that spans the entire enterprise architecture. The models are deliberately devoid of any technical terminology, providing an intuitive tool that is understandable by virtually anyone. Because there are so few primitives, coming up to speed with a CBA is trivial; the models can be understood by anyone with only a few minutes’ briefing. Since all data and process are represented only by connections, the architecture is infinitely scalable, limited only by the amount of hardware resources available.
When such simplicity is combined with the ability to model any data or process, the barriers to communication between business people and technical staff vanish. In fact, a CBA makes modeling so simple that a technical staff is no longer a necessity; business process owners can define, design, and develop their own automation solutions. Most importantly, C-level management can directly comprehend the models, bridging yet another critical communications gap. With a CBA, the only job for IT is to keep the network running. Business people can take care of the rest.
Leonardo da Vinci once noted that “Simplicity is the ultimate sophistication.” With a connection-based architecture, that simple sophistication for data and process modeling is finally within reach of business architects. And that’s no snow job.
