- Councils & Projects
|buildingSMART alliance Information Architecture Projects|
Information Architecture Projects: BIM Activities - Stakeholder Activity Model
Developing an Enterprise BIM Framework Utilizing an Activity Node Tree Construct
1. Background, Purpose and Objective
The buildingSMART alliance, a council of the National Institute of Building Sciences (NIBS) and the North American Chapter of buildingSMART International has been coordinating the efforts of the facilities industry to implement open BIM standards for the industry over the past several years. Goal #2 of the Alliances Strategic Plan, the development of a Stakeholder Activity Model as part of an Enterprise Management Framework, that will be the basis for the future of informational relationships throughout the facilities industry and thus the basis for true information interoperability.
The development of an Enterprise BIM Framework is one of the most important and primary steps to enable the production of a consistent set of interoperable standards for the exchange of building and infrastructure data through the lifecycle of a building project. To achieve the vision of interoperable standards for the exchange of building and infrastructure data throughout the lifecycle of a project, the development of a holistic end-to-end framework and best practice roadmap - a node tree that provides NIBS stakeholders with a comprehensive view of how the business and data functional requirements cover the lifecycle of planning, managing, design, engineering and construction, operate and use is essential.
The primary purpose of an Enterprise Framework is to facilitate the communication, planning and scoping of business capabilities that enable the accomplishment of enterprise or project wide business transformation, integration and interoperability. Highlighted below is the Project Overview and Summary Information.
Purpose (Problems, Needs, Gaps)
Scope and Approach
Conduct the required research, and document existing work and best practices and "string" the various pieces together to build the end-to-end framework that provides the context of enterprise wide functionality and management.
This enterprise framework will be utilized as a planning tool, communication and scoping tool (as it displays the meets and bounds of the project) to enable integration, interoperability and transformation of each functional area within the enterprise framework.
2. Developed Products – Overview and Benefits
To achieve the project objective, a number of products were created. Each of these products has a specific purpose and intent. The use, purpose and objective of each product is discussed below.
BIM Enterprise Activity Node Tree
The Enterprise Activity Node Tree or Operational Activity Decomposition Tree is a functional, hierarchical decomposition of Enterprise-level Operational Activities for a given business functional area. It defines the scope of a given enterprise, and provides the required context and content required for planning, scoping and business transformation.
The Node Tree constrains the relationships of the activities and is used to decompose the operational activity model only to a level necessary to identify cross-functional information exchanges.
For example in the case of the BIM node tree, the activities will be decomposed to a level where the relevant business function, information exchanges, data and metadata for the planning or construction of a building is visible and determined.
The BIM Node Tree was developed utilizing a number of artifacts and best practice resources including:
These sources in addition to multiple workshops and collaboration sessions provided the necessary context and content required to develop the enterprise node tree illustrated in Figure 1 – BIM Enterprise Node Tree.
Figure 1 – BIM Enterprise Node Tree
The BIM Node Tree consists of the parent core functions necessary to define the information required for Building Information Management. It defines what is done and not the sequence of how it is done. It consists of the core functions related to the lifecycle of the building - Management, Planning, Design, Construction and Operate/Use and is a hierarchical decomposition, which means it decomposes each of the parent core function into related child activity nodes, providing a level of granularity required for more definitive scoping and planning. The BIM Node Tree will be one of the key products utilized to define opportunities, or information dependencies among Activities that need to be further scrutinized and utilized to identify relevant information exchanges and related data and meta data.
When the Node Tree is stabilized and approved, the decomposed activity model diagrams will be created with Input, Control, Output, Mechanisms (ICOMs) identified for each Operational Activity during workshops and or stakeholder meetings. Selected or focus area Operational Activities will be defined and expressed at the correct level of decomposition and definition.
Life Cycle Model (LCM) and Architectural Precast Process Model
One of the key products developed for this project is the Life Cycle Model event trace description or business process model depicted in Figure 2 – LCM Process Model.
The LCM process model was developed utilizing the COBie Use Case and a Model View Definition based on NBIMS version 1, part 1 to demonstrate how activity nodes from the BIM Node Tree map easily to the LCM and provide a logical sequential order for the flow of information throughout the facility life cycle. A second example provides a process model for the Precast Concrete project accomplished by Dr. Charles Eastman of Georgia Tech utilizing activity nodes from the BIM Node Tree – Figure 3 – Architectural Precast Process Model.
These examples will help extend the vision to others working to define BIM for the facilities industry nationally and internationally and allow them to produce far more valuable products, which also define interoperability needs.
Figure 2 – LCM Process Model
Figure 3 – Architectural Precast Process Model
The purpose of a Process Model is to provide a sequence-ordered examination of Business Process Steps to achieve a Business scenario or business context.
The Model displays a series of business steps that are executed sequentially, or in parallel, in response to business events, to produce a specific business result. Secondary purposes of a process model include:
The LCM and Architectural Precast process models for this project were developed using the Business Process Modeling Notation (BPMN). BPMN is a standard notation used across industry and Government to document Business Processes and is promoted by the Object Management Group.
This standard has been developed specifically to model collaboration across organizations, and supports the implementation of a service-oriented architecture (SOA). The primary goal of BPMN is to provide a standard notation that is readily understandable by all business stakeholders; the business analysts who create and refine the process; the technical staff responsible for designing and developing the software and infrastructure to support the process; and the business managers who implement, manage and monitor it. Consequently BPMN is intended to serve as common language to bridge the communication gap that frequently occurs between business process design and implementation.
The process Steps in the LCM and Architectural Precast process model are derived from or mapped to leaf-level Operational Activities in the node tree. The process models are characterized by multiple object types by the following four major groups; Flow Objects, Connection Objects, Participants and Artifacts.
Flow Objects actually perform the work and produce the models, synchronize the Process Steps, and direct the process flow. The Flow Objects are:
Connection Objects are represented by arrows that show the flow via sequence or by synchronizing messages between different organizations. An example of a connection object is a sequence flow.
Pools represent participants and their roles, respectively.
Artifacts are notations that do not affect the process flow, but provide clarity to the reader. An example of an artifact used on the process models include Data Objects.
3. Next Steps
It is anticipated that the Node Tree developed under this project may be included as part of the National BIM Standard version 2, and thus used long into the future in defining the scope and business process models and data interoperability related to BIM. It is the first step in determining the required "Building Information" provided or generated from the relevant nodes within the node tree that can be shared collected, stored, updated and provided to shared to stakeholders at anytime from anywhere through a model/server/cloud computing enabled environment.
In essence developing and executing a service oriented architecture (SOA) strategy for BIM is what is required.- SOA is an architectural and design discipline conceived to achieve the goals of increased interoperability (information exchange, reusability, and compatibility), increased federation (uniting resources and applications while maintaining their individual autonomy and self-governance), and increased business and technology domain alignment. Figure 4 - BIM Cloud/Service Concept is a graphical illustration of the BIM SOA approach.
Figure 4 – BIM Cloud/Service Concept
In order to achieve this strategy, the completion/definition of Node Tree, the complete decomposition (ICOMs) of selected "in scope" activities with relevant information exchanges, populated with the required data, metadata, system function and system data exchange information utilizing multiple categories and classifications if required are some of the primary tasks required to determine what building information the node/activity will produce, that is provided to the "Cloud" and shared with stakeholders. Other tasks and project required to fulfill the BIM SOA concept include;
The conversion of previously created business process models to adhere to the activities of the node tree developed under this project – The work and sample process models developed under this project have demonstrated how activities and data from different business process models will relate utilizing a consistent activity/node construct that is reusable. This critical capability previously did not exist previously.
The creation of Data Models or a single integrated data model is one of the primary requirements and products that will enable the stakeholder community develop a more informed architecture based on standards that can be used as an industry architecture framework. The development of data models either at the logical level - data requirements and structural business process (activity) rules or at the physical level - the physical implementation format of the Logical Data Model entities, e.g., message formats, file structures, physical schema will entail the conversion of the data included in the various information exchanges promoted by ERDC into a data model linked to the information exchanges on the decomposed activity model, that is linked to activities in the node tree, that are mapped to process steps, information exchanges and data objects on the process models. This data model could also be included as part of NBIMS as it matures. Prior to that it will help identify who is creating and who is using data and help ensure that information is not re-collected but re-used and enhanced throughout the facility life cycle.
In essence the data models describe the structure of an Enterprise Framework's data in terms of Entities and their characteristics as Attributes. It provides wide definitions of the Entities and their Attributes and captures structural Business Rules governing the interrelationships between these Entities and their Attributes.
Data models consists of:
The Conceptual Data Model is used for concept refinement and stakeholder comprehension of the Data and Information requirements. The Entities and Attributes depicted in these models are refined into a Logical Data Model where Entities and their Attributes are restructured according the rules of normalization. This is done to capture all of the Data and Information requirements prior to producing physical transactions and database schema documented in the Physical Data Model. This process is reversible starting from either the conceptual or physical as long as the integrity of the model is maintained, as it is forward and reverse engineered.