Modeling the True Business Architecture

It has been said that one picture is worth a thousand words, but the veracity of this ancient maxim is radically understated when it comes to modeling the business architecture. Indeed, a well-modeled business architecture is worth its weight in gold, not to mention market share. But what exactly is business architecture, and by what standards can their models be judged?

Looking at the current crop of software systems that purport to enable business architecture, one is left with the impression that business architecture is, at best, flowcharts and Entity Relationship Diagrams replete with their COBOL-like field definitions.  But these tools are no more business architecture than is hitching a tired old horse to a new Corvette. The inherent disorganization of the models they produce not only obfuscates the enterprises and systems they document, they also do a grave disservice to the very concept of what business architecture should be.

Discovering how to model a true business architecture is not an easy task. Should you visit the websites of virtually any BPM vendor, aside from the occasional screen shot you will see none of the details of how their products operate, nor will you understand where their products might fit within the overall Business Architecture Life Cycle.  If you have the fortitude to brave a vendor’s sales force to discuss these details, you’ll eventually discover that most products only embrace a few cells of the Zachman Framework; some products perform only requirements capture, others are purely an automation engine, while a few more support direct execution of flowcharts.  But moving beyond that, integrating these various disparate products into a single whole is problematic at best. The sole exception to this disjointed approach to business architecture is found in the patented¹  Business Architecture System, which spans most all of the Framework using a single, simple syntax.

Using the Business Architecture System, at its highest level a business architecture is defined as the collection of the independent processes of an enterprise or system and the relationships between them.  This architecture stretches out in two orthogonal directions: process and data. The process model shows the sequence in which the overall business process flows, while the data model maps the path by which the data flows. Although orthogonal, the two models are a tightly integrated whole, because every independent process that appears on the process model must also appear on the data model and vice versa, one for one. Taken together, these high-level process and data models provide a complete, functional overview of the purpose and operation of any activity and its touchpoints.

The high-level architectural models serve many purposes.  First off, they define the full set of activities performed by an enterprise or system, and more importantly, they exclude the activities which are not part of the enterprise, thereby defining scope.  They also provide a clear roadmap for managerial alignment, not along classic functional lines of departmental silos, but rather along the much more agile lines of business processes and value streams.  In turn, the same models can then be used as a dashboard for allocating resources, defining metric measurement points, and monitoring the status of the flow of process and data. These high-level business architecture models form the blueprints that engage, enlighten and empower senior management.

But this high-level architecture is only the first step to defining the complete business architecture.  Next up is the expansion of the same high-level models via  decomposition of process and data to form detailed business rules which describe how each independent function is performed.  This decomposition is performed first on each data model, thereby defining the details of the exact interfaces between the various independent functions.  Once the inputs and outputs are defined, the business rules which transform those inputs into outputs can then be modeled.

The final stage of modeling the business architecture involves connecting the lowest levels of the models to the necessary underlying technology services via a Service Oriented Architecture interface, thereby forming a tightly-integrated, complete definition of the enterprise or system, from top to bottom, from strategy through implementation, all in a single, dynamically-navigable model using a single, simple syntax.

There are several noteworthy aspects to this approach to business architecture.  Foremost among them is that virtually the entire modeling process is devoid of technical details until the very last.  This allows for senior management to define, design, and develop the overall operation of their business, not Information Technology professionals.  Business Process Owners can map out business rules in their entirety without resorting to arcane skills such as UML or ERD’s.  Non-technical Business Analysts can finalize the details of the business rules through defining and re-using the necessary services, again without the involvement of IT.  In short, the business architecture is defined and maintained exclusively by business people. The only involvement for IT is to keep the network running and, in those cases where an automation engine is not being used, to translate the services into the target computer language by working directly from the models.

By taking a disciplined, scalable, integrated approach to modeling the business architecture, businesses can once again take control of their processes, data, and value streams. The business architecture becomes visible and understandable, and therefore manageable. The single, comprehensive syntax allows for complete understanding of the architecture by all stakeholders, ranging from C-level management to the offshore implementers and everyone in between. The entire organization is finally working from the same architectural play book.

This is the heart of modeling a true business architecture: a tightly-integrated, shared understanding of the organization’s value streams and their data.  Anything less is just a flowchart.

¹US Patent numbers 5,418,942, 5,564,119, and 5,960,437

======================

Ken V. Krawchuk is Chief Technology Officer of Business Architects LLC, providers of business process analysis and automation solutions (www.BusinessArchitectsLLC.com).  Mr. Krawchuk has served in a broad range of Information Technology roles over the last 35 years, and holds several US patents related to business architecture, database theory, process automation, and project management.

Bookmark / Share This

Bookmark or share this with others.