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.
Development of the Phase 1 Enterprise BIM Framework for the buildingSMART alliance.
Connect major participants of the building industry in a stakeholder activity model describing behavior associated with delivering, maintaining, and operating buildings by articulating improved information exchange processes thereby defining the scope of the buildingSMART alliance effort.
The Executive Director buildingSMART alliance, National Institute of Building Sciences and the business architects of Global Insights + Solutions.
The Executive Director buildingSMART alliance, National Institute of Building Sciences.
An Overview and Summary Information, An Enterprise Node Tree, A Sample Activity Model, Process Models, and A Sample Data View/Model.
Purpose (Problems, Needs, Gaps)
It will provide the ability for stakeholders to visualize the broad context of the end-to-end functional requirements, visualize how their communities fit in the enterprise context and visualize the requirements and logical business and data interrelationships and interdependencies inherent in the decomposed sliver/deep dive.
Scope and Approach
Assist the buildingSMART alliance in developing a holistic end-to-end framework and best practice roadmap that provides key stakeholders with a comprehensive view of how the business and data functional requirements cover the lifecycle (Plan, Design, Construct, Operate, Manage) of the business enterprise.
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:
- The Penn State Computer Integrated Construction Research Program Integrated Facility Management Process Model (PDF) - Sanvido, V. (1990). "An Integrated Building Process Model." Technical Report 1, The Computer Integrated Construction Research Program, The Pennsylvania State University, University Park, PA.
- The Building Information Model (BIM) & Industry Foundation Classes (IFC) ISO PAS 16739.
- The Information Delivery Manual for Precast Concrete - Dr. Charles Eastman, Professor, College of Architecture Graduate Programs.
- Construction Operations Building Information Exchange (COBie) - Dr. William East, Research Civil Engineer at the Engineer Research and Development Center.
- Office of the UnderSecretary of Defense Installations and Environment, Department of Defense Business Enterprise Architecture, Real Property.
- OMNICLASS - A Strategy for classifying the Built Environment - A project of the Construction Specifications Institute.
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:
- Aligning Business Rules with specific Business Processes.
- Setting the foundation for controlled, systematic transformation.
- Establishing a basis for measuring the progress toward achieving transformation objectives.
- Establishing key criteria for testing and evaluating transformation solutions.
- Linking data, metadata and related information or transaction types to specific Business Processes.
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:
- Process Steps perform the work and produce the model. Process Steps, are also called tasks. Tasks that are further decomposed into subtasks are called Sub-Processes.
- Events act like traffic signals and hold up the process or allow it to proceed in response to things that happen, called triggers. A Start Event starts the process in response to a trigger. An End Event signifies the completion of the process. There are three types of Events, based on when they affect the flow, Start, Intermediate and End.
- Gateways control the divergence and convergence of a flow. Thus, it determines decisions, as well as the forking, and merging paths. The following types of Gateways may be used, depending on the conditions.
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.
- Sequence Flows, shown by solid arrows, indicate the direction of the Process, from one Process Step to the next. Displaying the name of a Sequence Flows is optional, except for Conditional Sequence Flows, since these represent Gateway decisions, or when it adds clarity to the Diagram. Some Sequence Flows have an initiating Event that triggers the Sequence Flow, such as the receipt of a message.
Pools represent participants and their roles, respectively.
- Pools are represented by an open rectangle with a Participant's name on the left. The Pool contains the processes performed by a Participant. It also acts as a graphical container for portioning a set of Process Steps from other Pools. A Pool may be further divided into Lanes, if it is necessary to show Roles within the Pool.
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.
- Data Objects, represented by a folded paper icon, reflect data that is consumed or produced by a Process Step. Data Objects are the mechanism to show what data is consumed or produced by Process Steps. Data Objects are graphical representations of Information Exchanges on the process model.
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.
- Enable effective management of data resources by providing a single set of consistent data definitions for use within an Enterprise Framework.
- Capture the Business Rules describing the structure of data needs within the Enterprise Framework.
- Serve as data reference framework to support the sharing of data between business domains and external organizations.
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:
- Conceptual Data Models - The required high-level data concepts and their relationships.
- Logical Data Models - The documentation of the data requirements and structural business process (activity) rules.
- Physical Data Models - The physical implementation format of the Logical Data Model entities, e.g., message formats, file structures, physical schema.
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.
Back to Projects & Standards