Companies have recognized, particularly large businesses, that building IT systems is complex. Enterprise architects are responsible for applying many of the same skills that building architects are required to display. They must understand structural integrity, operational safety, functional utility, and must assure that the systems satisfy mandatory requirements.
For the building architect, those requirements are normally expressed in both legal structures, such as building codes, and technical engineering resources, such as load tables.
But, wait a minute. Don’t IT architects have similar requirements?
In the 21st century, it is certainly true that any IT network, system or service must navigate through a bundle of legal rules regarding information, access and use, preservation and destruction, transfer, and other requirements. But unlike the building architect, the IT architect does not have a single, consistent legal resource on which to rely.
Not too long ago, I typed in the phrase "rule–based design" to find how that phrase is being employed across the world. What surprised me was the discovery that software programs have been developed which allow the building architect to approach and implement their designs around applicable legal rules with a very different model.
Historically, following the completion of the architectural and engineering drawings, most developed economies require the architect’s work to be submitted to building inspectors. These inspectors have the responsibility of evaluating the drawings and determining if all of the applicable legal rules and requirements have been satisfied. In many jurisdictions, this process was more than a quality control inspection; it more often resembled a game of "cat and mouse" in which the architect hoped that deviations from building requirements might not be recognized, and if deviations existed, the architect could negotiate an exception. Oddly, this compliance activity was occurring after the architectural creativity had been exercised, and often resulted in delays, unexpected project extensions and occasional outright denials of the right to proceed with building.
Recognizing the inefficiency of these historic practices, software developers have created products that can be employed by the architect from the very first moment at which the design process begins. These products identify and integrate into the design tools all of the formal legal rules that must be satisfied, based on the physical location, the intended purpose, and each layer of the design as it develops. As a result, the architect is able to design within the boundaries of the formal legal rules. The result is an architectural drawing that reflects a compliant structure, and one which can be more readily reviewed and approved by the public authorities.
Indeed, in Singapore, the Construction and Building Authority has developed its own software, which is able to electronically evaluate the submitted drawings and apply the appropriate legal rules in order to automatically identify deficiencies or circumstances requiring further review.
The differences have been reported by both the architects and the public authorities as significant improvements in the economic efficiency, accuracy and compliance of the buildings with the known legal rules. Many of those legal rules, in turn, reflect engineering requirements that are also taken into account by the design software.
Clearly, for the IT architect, there are lessons to be learned. For each step taken by the IT architect to better account for all of the rules that a solution must navigate, before the design process begins and long before construction of the solution is underway, the IT architect is able to better assure the timely completion of the solution, and the compliance of the systems and resulting data with applicable rules. Yet, even in this second decade of the 21st century, we are witnessing a continued failure of IT systems to be designed for compliance. Time and again, systems are designed, built and implemented without early and complete evaluation of the rules that must be satisfied. The result is that corporations (and their lawyers) are often patching compliance onto the systems after the fact. Expenses are increased, compliance is less assured, and the IT architect often gets stuck with the responsibility.
“Rules–based design” means that IT solutions are designed with a fully-informed awareness of all of the rules, including the legal rules, that the solution and the data must satisfy. With cloud computing, data that is dynamic and volatile, and mobile users, the challenge is genuine – how do we anticipate all of the legal rules that may apply?
The solution will emerge incrementally. But the first step is to accept the principle that IT systems, and their data, can be designed differently. We can take into account prior to the design process, and not after the completion of construction, all of the rules that the systems and the data must successfully navigate.
My training emphasizes, in every course, the need for all professionals touching digital assets to think differently about all of the rules that apply. Lawyers must understand IT rules; IT architects must understand legal rules. By beginning to build our IT systems like buildings, compliance can be improved and governance over the information can be accomplished. Building IT systems like buildings – what a concept.