March 31, 2004 (Revised)

Define software requirements that will provide full integration with other third-party products/functions to enable the interchange of information and system compatibility throughout the building regulatory process thus providing jurisdictions with full ownership of their data. Furthermore, this will limit software integration costs while expanding the potential market for technology and software developers and streamlining the nation’s building regulatory process.

Interoperability for the Building Regulatory Process (BRP) is defined as enabling discrete processes to communicate and share common and essential information and functionality throughout the BRP and Capital Facilities Process using interchangeable software tools. These interchangeable tools provide discrete functions that can be interwoven to optimize and automate existing business process needs.

The BRP includes:

• Licensing (verification, professional and construction trades)
• Construction Work Permitting, Review, and Inspection (needs to be broken up into further subsections)
• Materials and Equipment Certification and Permitting (conformity assessment / related permits: cranes, sidewalk, etc.)
• Maintenance Reports (post occupancy inspections / compliance)
• Complaint Response/Handling
• Enforcement (Violations, Compliance, Prosecution)
• Property Transactions (registering property ownership and transfer)
• Consider adding the following: zoning land use, stormwater management,
• Tie into other databases: Federal, State, & Local levels

Interchangeable software tools support functions within the BRP using common data elements/ data representation standards and modular software services. Interoperability will require that software tools be compliant with specified data and functional interchange capabilities. The principles for BRP Interoperability include:

• Data Portability - Definition of common data elements and structures
• Functional Interoperability - Definition of priority processes and services for interoperable modules

Assets that need to be developed to identify data interoperability include:

• Common Data Elements – data that supports interoperable functions and reference processes.
• Process Functional Description and Services – Processes where common data elements are used and in reference to processes where data is available. Incorporating this functionality will enable jurisdictions to be interoperable and help prioritize the functions for the software community.

Functional Interoperability is the ability to provide a framework for developers using XML technologies and service-oriented architecture to define the business process and invokes these services allowing for automation of the end-to-end business functionality.

Functional modules should leverage the following industry standard technologies to ensure functional interoperability:

• Service-oriented architecture (SOA)
• Universal Discovery, Description and Integration (UDDI) compliance
• Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), Web Services-Interoperability (WS-I), Business Process Execution Language (BPEL)
• User authentication and provisions standards to ensure secure interfaces (e.g. Security Assertion Markup Language (SAML))

Items that need to be documented to identify functional interoperability:

• High-level Process Map – Building regulatory process summary maps that illustrate the interactions between the functional entities by identifying the major touch points where the processes would interoperate (functionally or data sharing). (See Alliance website.)
• Functional Service Module Descriptions - Functional module descriptions will explain the level of functionality required as well as explain why a jurisdiction would want this functionality to be interoperable. These functional modules would be the foundation for the software community to define and develop interchangeable software tool(s).
• Detailed Process Flows and Step Descriptions–Detailed process flows will indicate where the common functional modules could be leveraged within the processes.

Future procurements should reference mandated software standards to be determined later but would include the following:

• Documentation on the current software product and how the product deviates from interoperability requirements (technical documentation with gap analysis)
• Product development timelines for achieving interoperability requirements (technical roadmap with interoperability milestones)
• Standardized data definitions and data structures following the Data Element Definitions or similar consensus data standards (XML Schema definitions)
• Conformance to the Function Services Requirements
• Standardized customer data interfaces including CAD design and web services with appropriate levels of user-authentication and security (SAML support)
• Ability to exchange or replace Process Level 2 component software through open, standardized data exchange formats and databases as well as through standardized functional service invocations and variables
• Object-oriented sub-process (level 3 and lower) components