The Language of Business Architecture

Registration is free. Login or register to view/download this content.


Enterprise Business Architect, Independent Consultant
Ralph Whittle is co-author of a book titled, Enterprise Business Architecture: The Formal Link between Strategy and Results, CRC Press 2004. He is a Strategic Business/IT Consultant and subject matter expert in Enterprise Business Architecture development and implementation. He has built Enterprise Business Architectures in various industries, such as manufacturing, healthcare, financial, and technology. He has worked in the IT industry for over 26 years, conducting engagements in enterprise business process modeling, strategic/tactical business planning, enterprise business requirements analysis, enterprise business architecture and IT architecture integration, strategic frameworks integration with systems development methodologies and IT service offering enhancement. He is a co-inventor of a patented Strategic Business/IT Planning framework.

Many companies are beginning or at least seriously considering a Business Architecture (BA) initiative. Even though the Business Architecture has always existed, its structure, nature and appearance have remained hidden from view. The ability to express the complexity of an enterprise in a commonly understood and graphical format, for purposes of analysis and design is severely limited without the Business Architecture. And of course, one will need a rich graphical modeling notation or language in order to develop the BA.

Most likely at the beginning of a typical BA initiative, several business and IT managers are ask to provide their current models of the enterprise. Many times a model of classified processes listed in functional columns is innocently, but incorrectly assumed to represent the BA model itself. If some models are available, they are usually out of date or really just classifications of interesting things about the enterprise. Sometimes, the response is “nothing formal is available but I can draw one on the grease board!” In most cases, these representations are not models at all, but simply sketches or casual drawings lacking any formal modeling disciplines. These drawings merely represent the thoughts in an individual’s mind and do not possess the rigor or structure to be easily understood by others or shared throughout the enterprise without extensive explanation.

Some may have tried to adapt the Unified Modeling Language (UML) notation and artifacts as perhaps providing a “first look” at the Business Architecture. Even though the UML was neither designed nor intended for use as the language of BA, these first models may have at least launched some creative and focused thinking about the BA model itself. And yet, others may have also tried to use the Business Process Modeling Notation (BPMN) in a similar fashion. While these first attempts certainly had noble intentions, most likely, these “early drafts” using the UML and/or the BPMN were disappointing, both in the ability to represent enterprise complexity and to create a shared understanding about the enterprise. At the minimum, one would need to significantly expand the UML or BPMN in order to represent the Business Architecture. After all, neither the UML nor the BPMN comprehend Business Architecture needs! Ironically, it is interesting to note that the BA must integrate all of the enterprise’s business processes, probably modeled using the BPMN, and the business processes must link to UML or code development/generation artifacts.

Without delving into the full blown development of a modeling language for Business Architecture, perhaps one can at least begin the discussion and analysis by first looking at some of the most basic needs for Business Architectural modeling.

Highest level BA component:

In the core BA model, one will find the integration of processes, capabilities, functions, activities and other similar things represented as an essential component. Most likely, this essential component will represent an end-to-end collection of activities that deliver a result to a customer (or end user) and it has a clear goal: to delight the customer(1). This high level component integrates several enterprise elements and represents a singular but unique encapsulation of significantly important information. Some of these encapsulations may focus directly on the profit generating customer while others may benefit and deliver results to corporate executives, stakeholders, employees and the people who run the enterprise. However, its integration with other similarly encapsulated enterprise entities and external entities stands at the foundation of the BA. The organizing principle and purposeful reason for integration of the BA requires a clear definition, understanding and acceptance by the enterprise; and that principle and purposeful integration demands a customer-centric focus.

One can call this singular encapsulation many names, for example, a value stream or a customer-centric cross-functional process. And of course, the focus on a client, consumer, guest, passenger, patron, citizen, end user, stakeholder and other similar terms are just as valid as customer. Value streams will suffice for purposes of continuity in this article. After all, value streams are frequently used in Lean Manufacturing, Six Sigma, BPM and other enterprise disciplines.

In the language of BA, the value stream needs a representation, graphical icon or construct that sets it apart from other decomposed or aggregated processes. The value stream is at the highest level of a set of logically related and integrated elements, and sometimes stands alone for analysis, design and expectations for success as defined in the corporate strategy. However, one can harness even greater potential by integrating the value streams by having one drive, influence, respond to and/or initiate another! One can decompose the value stream for detailed analysis of its complexity, seeking performance improvement and then aggregate it back up to discuss its contribution to strategic objectives. After all, a value stream will include all of the people, processes and technologies required to deliver the expected results and outcomes.

Aggregation and Decomposition of processes:

Many process models begin in the swim lane format and these are very well recognized and understood. These models usually represent the lowest level process descriptions from which the transition to creating UML artifacts begins or to configuring packaged software begins or if using a BPM tool, the transition to eventually code generation begins.

Some of these swim lane models run for many pages, contain off page connectors and are occasionally hard to follow in this multi-page format. It is rather easy to aggregate a swim lane model up to a single box representation or maybe to a single page representation with a modest number of aggregated processes. While this does add an additional level to the model, it makes it more comprehensible and less intimidating to other reviewers.

From the multi-page swim lane model, some logically related group of sequential steps are consolidated into a single box along with its net external inputs and outputs. For example, perhaps a ten page swim lane model might aggregate up to a single page model with six or seven boxes containing their corresponding external inputs and outputs. Then by “clicking on” or decomposing any of the six or seven aggregated boxes, one exposes the very same detail and complexity of the logically related group of sequential steps as found in the ten page swim lane model. Some consider aggregation as the creation of “process black boxes” and this characterization is valid. These “process black boxes” also encourage reuse of formerly designed processes which have been optimized for performance. This is quite easy to use if properly aggregated, but rather hard to reuse if forced to model exclusively in the swim lane format. As long as the normal rules of balancing inputs and outputs between levels of a model are strictly followed, aggregation and decomposition become not only a useful technique, but a necessary one as well.

In the language of BA, the decomposed (lower level detail) and aggregated (higher level summary) processes need a different representation, graphical icon or construct, and most every modeling notation satisfies this requirement fairly well.

Aggregation and Decomposition of inputs and outputs:

Process aggregation and process decomposition are very useful tools and this technique has been around for quite some time. By applying the very same thinking to “inputs and outputs” of processes, one can realize a similar benefit. Inputs and outputs can be aggregated and decomposed as well; aggregated in higher level models and decomposed in lower level models. For example, if a company manufactures one hundred different products, representing all one hundred products in a single high level model would exhaust the modeling page’s landscape and overwhelm the reviewer. The one hundred products might be aggregated, say for example, by customer type, by line of business or by product family; it just depends on what is best for the enterprise, but not based on some arbitrary modeling rule.

At least three kinds of input/output aggregations should be considered: whole/parts, shared relationships and containers. For whole/parts, these inputs/outputs must have all of the parts to have the whole; for shared relationships, these inputs/outputs share something in common or may inherit some shared properties; for containers, these inputs/outputs are broadly defined, and are sometimes composed of several dissimilar but logically related elements.

In the language of BA, representations of aggregated or decomposed inputs/outputs must be clear in the model. Therefore, the representations of any aggregated inputs/outputs must appear differently from those decomposed inputs/outputs at their most elementary or lowest level. And to further enhance the ease of communication and differentiation in graphical models, “physical” inputs/outputs (e.g., a fulfilled order packaged in a shipping container) must appear differently than “technology related” inputs/outputs (e.g., a web transaction). All of these distinctions in a rich graphical modeling language improve its readability and ability to instantly communicate something of relevance just by its appearance.

Balance inputs and outputs between levels of a model: A model is in “balance” when all external inputs and outputs in a “high level” (parent) model are represented in a “lower level” (child) model. The two “levels” of models are then defined as “in balance.” This is a formal rule that requires strict adherence. “Level” refers to a position in a scale or rank, for example, parent model and child model, and most everyone is familiar with this term in this context. This formal definition of “balance and level” was explained in a book by Tom DeMarco titled Structured Analysis and System Specification(2).

In the language of BA, the balancing of inputs and outputs between levels of a model is a rule rather than a single construct in a modeling language. The manifestation of this rule is found in the appearance and relationships between parent (high level) and child (low level) models.


These few recommendations and suggestions are merely intended to initiate the thinking about the language of Business Architecture. Anyone trying to build a Business Architecture model will quickly realize the futility of using the UML and/or BPMN and will begin to understand the ideas presented here as a starting point for developing a modeling language or notation specifically fulfilling the needs of the Business Architecture. A modeling notation which maps its constructs to those of a real language, coupled with a rich syntax and semantics for all constructs, will lead to a very effective and efficient way in which to communicate important ideas within the Business Architecture; after all, a picture is worth a thousand words!

For those wishing to see an example of a Business Architecture model that supports the ideas presented in this article, just review the web site listed below. Please use Internet Explorer as the links are configured for this browser. Just click on any colored vertical rectangle, representing a value stream (or an aggregation of value streams) in order to navigate through the models.

  1. James Martin, The Great Transition: Using the Seven Disciplines of Enterprise Engineering to Align People, Technology, and Strategy (American Management Association 1995), page 104.
  2. Tom Demarco, foreword by P. J. Plauger, Structured Analysis and System Specification (Prentice-Hall 1979), page 78.

Similar Resources

Featured Certificate: BPM Specialist

Everyone starts here.

You're looking for a way to improve your process improvement skills, but you're not sure where to start.

Earning your Business Process Management Specialist (BPMS) Certificate will give you the competitive advantage you need in today's world. Our courses help you deliver faster and makes projects easier.

Your skills will include building hierarchical process models, using tools to analyze and assess process performance, defining critical process metrics, using best practice principles to redesign processes, developing process improvement project plans, building a center of excellence, and establishing process governance.

The BPMS Certificate is the perfect way to show employers that you are serious about business process management. With in-depth knowledge of process improvement and management, you'll be able to take your business career to the next level.

Learn more about the BPM Specialist Certificate





  • Business Process Management Specialist
  • Earning your Business Process Management Specialist (BPMS) Certificate will provide you with a distinct competitive advantage in today’s rapidly evolving business landscape. With in-depth knowledge of process improvement and management, you’ll be able to take your business career to the next level.
  • BPM Professional Certificate
    Business Process Management Professional
  • Earning your Business Process Management Professional (BPMP) Certificate will elevate your expertise and professional standing in the field of business process management. Our BPMP Certificate is a tangible symbol of your achievement, demonstrating your in-depth knowledge of process improvement and management.


BPM Certification

  • Make the most of your hard-earned skills. Earn the respect of your peers and superiors with Business Process Management Certification from the industry's top BPM educational organization.




  • Operational Excellence Specialist
  • Earning your Operational Excellence Specialist Certificate will provide you with a distinct advantage in driving organizational excellence and achieving sustainable improvements in performance.


OpEx Professional Certificate

  • Operational Excellence Professional
  • Earn your Operational Excellence Professional Certificate and gain a competitive edge in driving organizational excellence and achieving sustainable improvements in performance.



  • Agile BPM Specialist
  • Earn your Agile BPM Specialist Certificate and gain a competitive edge in driving business process management (BPM) with agile methodologies. You’ll gain a strong understanding of how to apply agile principles and concepts to business process management initiatives.  

Business Architecture



  • Business Architecture Specialist
  • The Business Architecture Specialist (BAIS) Certificate is proof that you’ve begun your business architecture journey by committing to the industry’s most meaningful and credible business architecture training program.

  • Business Architecture Professional
  • When you earn your Business Architecture Professional (BAIP) Certificate, you will be able to design and implement a governance structure for your organization, develop and optimize business processes, and manage business information effectively.

BA CertificationCertification

  • Make the most of your hard-earned skills. Earn the respect of your peers and superiors with Business Architecture Certification from the industry's top BPM educational organization.




  • Digital Transformation Specialist
  • Earning your Digital Transformation Specialist Certificate will provide you with a distinct advantage in today’s rapidly evolving business landscape. 


  • Digital Transformation Professional
  • The Digital Transformation Professional Certificate is the first program in the industry to cover all the key pillars of Digital Transformation holistically with practical recommendations and exercises.



  • Agile Business Analysis Specialist
  • Earning your Agile Business Analysis Specialist Certificate will provide you with a distinct advantage in the world of agile software development.


  • DAS Certificate
  • Decision Automation Specialist
  • Earning your Decision Automation Certificate will empower you to excel in the dynamic field of automated decision-making, where data-driven insights are pivotal to driving business innovation and efficiency.