TheTree.Project
•Download as PPTX, PDF•
1 like•421 views
An initial presentation of TheTree.Project - good practice in Data Processing and Management in AEC industry
Recommended
Recommended
More Related Content
Similar to TheTree.Project
Similar to TheTree.Project (20)
More from Nikolay Gerasimov
Recently uploaded
Recently uploaded (20)
TheTree.Project
- 1. TheTree.Project Nikolay Gerasimov PhD, Consultant RICS Certified BIM Manager Autodesk Revit Professional
- 2. Foreword • Data have became a self-contained fundamental value for the last century • There is a lot of activities to find an appropriate way how to operate with data in AEC industry • General theories of how to deal with data efficiently: - Design of Experiments (science, est. by R.A. Fisher 1930s, planning&processing) - Data (Database) Management (corporates, since 1960s, formatting, storage) - Data Mining (computer science, 1950s-now, AI) • This project aims to apply DoE approaches to AEC data and invites to further discussion
- 3. Content • Problems and Goals • Data vs Information • Data Driven Process • The Tree • Roots • Trunk • Branches • Next
- 4. Problems • BIM, Generative Architecture, Computational Design – Data Driven Processes • Data is a mathematical representation of Information • Process = Processing • Effective processing of data - the key to success • Understanding principles of data processing – the key skill to success
- 5. Understanding instruments ARUP Design is an art to create something new using existing instruments. If you don’t understand them, you can only copy.
- 6. Goal To develop a new paradigm of working with AEC data as intuitively as with good old graphical information The paradigm must be based on: • Scientific approach • Practical realization • Artistic representation
- 7. Data vs Information. Case Study
- 8. Data vs Information Collection • Identifying sources • Understanding constraints • Formatting according to process requirements • Formulation of final goals Processing • Grabbing initial data • Choosing processes • Defining control points • Establishing report procedures Interpretation • Extraction of information • Analysis against final goal • Transformation into new initial data • Start next processing Synthesis Analysis
- 9. Data vs Information • Data is a collection of variables and parameters • Information is a collection of explicit logical connections in data • To find new information in data they should be processed in a common space or have similar metrics (synthesis) • After the result is achieved responsible data should be split and detailed separately
- 10. The Tree
- 11. The Tree Operation Keep data ready to reuse CAFM Construction Detail Realization Splitting Discipline models development and coordination Scheme Concept Process data Building planning BEM Str analysis Site analysis Planning Feasibility Colect data BEP Restrictions analysis RMSDisciplinesPlatformRMS
- 12. The Tree. Challenges • No realization of this architecture in real AEC software • In PLM it can be realized on Siemens NX platform as example • V-model can substitute Avanti for BIM purposes • Need to adopt RMS to AEC needs • Need to transform current practices into data driven systems- oriented processes • Need to close projects by RMS adopted to be next “roots”
- 13. Roots. Codes
- 14. Trunk. • MEP • Functionality • FMU • Str, fire… • Risk • FEA • Arch • Geometry • IFC • MP • Site • GIS Location Appearanc e Performan ce Safety
- 15. Branches. FulCoord A+S Arch Str MEP HVAC Base Bldng Arch Str Site MP Coordination Many to 1 Trial and Error Collaboration 1 to many Predict and Avoid
- 16. Next. • Collect feedbacks • Issue guidance • Create process super-map • Collaborate with vendors and enthusiasts to implement proposed architecture • Work on visualization of ideas • Visit LinkedIn Group for further information
Editor's Notes
- Disclaimer: I’m not a native speaker, so a lot of mistakes are possible. Any corrections are highly appreciated. Hello, everyone, my name is Nikolay Gerasimov and this is the first draft of my project’s presentation. Let me introduce myself at first. I am a graduate of Saint-Petersburg State University, faculty of physics. I have a PhD degree in physics, experience in analytic calculations and data processing. At the same time I’ve been working in construction industry for almost 9 years as a HVAC design engineer, mostly at freelance. Last 3 years I dedicated to modern technologies in design: Building Energy Modelling, sustainability concept, BIM and a lot of software for it, and now I am an independent consultant. Since I’ve started exploring modern approaches in AEC industry, I cannot stop wandering why there is no such a significant progress because of new computational technologies as it was hundred years ago when people received new technologies in construction and engineering? Look at the architecture and structures of the beginning of 20th century, they are still amazing! And it was a massive event, not just iconic buildings… The problem, as I see it, is in our visually-oriented mind. I mean, computational technologies suppose good mathematical thinking and analytic mind to be able to use computers as drivers not as just instruments. Look at progress in car industry. Machines drive all processes (some of them literally). Catia, as one of the most advanced design software, is purely mathematical, but at the same time is widely used. There are just more people in AEC industry than in car building one and, naturally, abstract thinking is a rare skill. How many people are good at math at school or in college? We should find a way how to explain most of people what all that abstract “data”, “information”, “scheme” etc. means. And this explanation should be beautiful enough to inspire people for creation new Sagrada de Familia or Golden Gates, or Eiffel Tower. This is what The Tree. Project is dedicated to. To do this we should firstly align the experience in working with data between AEC industry and others and within AEC itself. So, currently the main participants and contributors are supposed to be software developers, BIM managers, R&D professionals and enthusiasts related to these areas.
- For those of you who is not entirely sure whether he wants to read further, I would like to give a short description. As I mentioned, computers are currently the main drivers for the progress. One of the most interesting thing they taught us, is the fact that any valuable thing can be presented as a compilation of numbers and simple words which then can be easily acquired, stored, transformed and accessible at any time. For some activities it is a natural way of thins, e.g. bank business is build on a collection of records about its debtors and creditors. The more accurate and complete these records are, the easier access is – the more successful the bank. AEC industry needs automation no less than any other – it is the main trend everywhere. The problem is that it is not so easy to find a way how to degrade information into data to automate their processing. At the same time a lot has changed in calculation related areas – math, statistics, physics and engineering. They work with data originally, because they have no or not enough information about what they discover, only facts. And it is vital for them to have a strong fundament how to process data to extract trustful information, avoid false consequences and make the whole process robust to deviations (errors). Sounds familiar, doesn’t it? Scientists established several theories how to deal with data effectively and efficiently. The first is Design of Experiments, it was created by mathematicians and focused on statistical nature of measurements, but the main consequence is has – it provides principles of “good practice” in process engineering or how to design robust and trustable workflows. It gave birth to most of modern concepts: system engineering, lean practice, business process modeling etc. The second one is Data or Database Management. It is dedicated to problems of massive amount of data, how to store them, how to organize their accessibility and, again, robustness to real challenges. And the third, more exotic, theory is Data Mining. It studies problems of automatic extraction of information from data, i.e. how to teach machines to think. It looks like only human can interpret data qualitatively and make consequences but it is not so. Speech and image recognition are classical example of intelligent processing, financial analytics and prognosis is a good example of machine thinking. So, data is not something new and it is fundamentally universal thing . Many activities were adopted to use data natively, it has significantly helped them. To do it in AEC industry we need to look at what have been done in other areas, what fundamental principles drove their change and how to apply them for our purposes. I believe it is useful to meet with some basic theoretical aspects of operation with data as soon as we are going to transform the whole industry. This is why I decided to start this “good practice project” and not to limit it by existing case studies, we need more.
- The project is only at its early stage. This presentation is focused only on current model of data flow and software architecture presented as – surprise – a tree. At first we consider with more details current situation with transformation of AEC industry and purposes of this project. Then I should say a couple of words about difference between data and information with an example from my previous scientific work. Based on those topics we will consider a general model of a data driven process and finally discuss the idea of its visualization as a tree. After that I would like to suggest some directions for future work and invite you to collaborate.
- Let’s start from the challenges. As you know, before BIM became a fashion there were several paradigms which anticipated its underlying idea – work with data firstly. Products like Generative Components, Digital Project, relied on math rather on discipline-specific knowledge and features. And those who have had an opportunity to work with them, know how weird it is. Or at least it was. Look how popular Grasshopper and Dynamo are because of a brilliant idea of nodes and wires! Nevertheless, the entire logic remains the same – data first. So, what is the fundamental difference between data and information that we split so radically data- and information- driven processes? If you look at a paradigm Data-Information-Knowledge-Wisdom, Data are explained there as a collection of facts while Information is Data within context, it contains logical connections within Data and with their context. Practically it means that to be able to solve a problem on a computer we must formulate it in a mathematical language of variables and process parameters. It is not so easy to do and what is worse, it does change the way we work with information: now we have to degrade it into data, process them, get results and transform them into a human-readable format back! Is it worth? Yes. Because mathematical relations between variables in Data are much stronger and more robust than any logical connection within Information. It has quite far going consequences, we need to transform the whole “infrastructure” e.g. to approve your models against code requirements one has to reformulate them in a “Data-centered” language. Thus, all processes where data are the driver, should be transformed into “processing” of those data in mathematical sense. Does AEC industry have some fundamental troubles or features that will lead us to unique data processing? Not at all. Look around, data are everywhere, people can do fantastic things with them, one I will show later. Data is a universal paradigm and always have been. It is interesting to note that even first computers and their abstract models, like Turing Machine (1930s), were universal in terms of their tasks. It was the true revolution like alphabetical writing – to find a way of representation absolutely anything we can do, through a universal language and realize this approach through particular machines! We usually don’t see it – computers have user interfaces adopted to concrete tasks and we think about applying computers only in terms of software and its “appropriateness” to our purposes. User interfaces confuse people, they give us a sense of working with information only, so when we have troubles, first of all we try to change the software. Sometimes it works, in most cases temporally, and when it comes to build a system of coordinated software we rely on consultants. What if we want to build something absolutely new? And then teach others how to use it. The best way is to understand underlying principles of data processing, look at your task from aside, build a solution and then focus on changing people’s approach to prevent using computer like a rock.
- During my investigation of BIM and other modern trends I have heard a lot of times arguments like “Why should I know all of that, it is not my area, I need only to do my work, I don’t need to be a service man to drive a car”. The last is true. Driverless cars have proven this statement. The only question is whether our work in AEC is like a car driving? God, no. As for me, I always compare AEC with medicine (I have 5 years of experience even in this area) and I was really surprised by ARUP’s project OVE, where they presented a building as a human body. Such a coincidence There are a lot of doctors who are specialists in their own areas, aren’t there? All of them use the same instruments for diagnostics and very similar approaches for treatment but for their own purposes. What do you thing, they know principles of MRI or lab tests? I hope so. Otherwise, they are not professionals and you better to choose another one. Any building is a system of systems and the main value is produced by synergy between them – something qualitatively new is born every time when we create a “good” building. We aim to this and even if we try to maximally split and focus on single elements and works, we cannot avoid interactions between them. This is why Ford’s assembly line doesn’t work anymore – the value is not just a sum of components. The value is interaction between them. When we work with such a tightly interconnected system of systems, the ability to present your work in a universal language, to do it the same way as other human activities and align results with others is a fundamental skill. This makes one a professional and allows him to work successfully for many years.
- This is why I decided to start this project. I consider it as a platform for discussions between professionals, development of a strategic view on software architecture, systems of software what will engage mere people to use all of this in their everyday work. I don’t know any similar initiatives, so if there are some, I will be happy to join them. The final goal is not purely theoretical. All results should be documented as good practice recommendations and later as standards, I hope. Would be great to see real products or systems driven by established principles. And finally the best way to check whether you have found a proper solution is to present it to an absolutely new man, who knows nothing about the case. If you can explain what is going on – you are on the right way. I don’t talk about marketing when you insist on your opinion and confuse people with pretty but false arguments, to make them agree with you. History knows many examples when beauty was the last and only argument to accept crazy ideas. E=mc2, remember? The whole quantum mechanics is just a ΔΨ=EΨ. Isn’t it beautiful? I am not good at art at all, so I hope to draw someone’s attention to help me present complex ideas in a true impressive and intuitive manner.
- Ok, let’s have a break from all these stilted words. I would like to show you an example from my previous life, when I was a physicist and we had a task to find a way how to recognize different temperature fractions of oil. As you know, oil is a complex mixture of dozen of substances and in practice we use only parts of it, separating them by boiling. Different fractures boil at different temperatures so it is their main characteristic and we need to determine somehow what is this fracture. The task was solved as following: we captured another unique characteristic – absorption spectra. We collect a lot of them, so we were sure that we have enough data in statistical terms. Then we digitized those spectra and presented them as just a matrix of absorptances on each wavelength. The size you can se on the bottom-left picture, we had more than 96 hundreds of points for each spectrum. To find a strong and robust correlation between those data and the temperature we reduced the number of columns to 3 applying special mathematical processing and interpreted those 3 new values for each fraction as coordinates in an abstract space. When we did this we got a clear smooth curve, ranged all initial spectra in the right order, separated them from each other, so they are clearly different even in such an exotic representation and as soon as it was a curve – 1 dimensional object – it was obvious how to match it with temperature scale. The key to success (and what actually differs this approach from classical) is degradation of informative spectra into uniform array of numbers – data – process them from fundamental principles to find that synergy, hidden information we are looking for, and finally interpret the result in a logical, human-readable manner. After we did our work we provided the results to specialists – chemists, who immediately started interpreting why this curve has such shape, how this approach may by applied in other problems – they got new values to work with. Isn’t it the same we try to do when we want to create some new, sustainable, friendly, social environment? Or just a private house. Yes, it is the same, and we don’t have to invent a wheel: everything we try to do has already been done somewhere else. We just need to meet with fundamental laws which underlie there, and apply to our problems.
- Going deeper into the theory how to work with data to extract new and trustable information we can build a simple diagram of 3 main steps: collection of data, their processing and finally interpretation. Nothing new, we do it every day and I want to highlight it. But do we use it as a rule of thumb when we build our processes and make decision whether some software is appropriate for our needs? Do we ask our consultants or vendors to show us how their products look from this perspective to be sure that they will help us to improve our work, make it more robust and productive? This slight V-shape, does it look familiar? In system engineering there is a V-model developed in 1980s which describes a whole philosophy of creation of complex systems like software or satellite connection. It is a QA/QC model, based on a simple approach: to split variables and process parameters (which are requirements and constraints in real life) from logical connections and stages of evolution of the project (systems, modules, entities; definition, development, testing). The process doesn’t look like doing your job, then get a lot of notices and redo it until everyone is happy or the deadline comes. The process is highly collaborative. People discuss goals at first, align them, then talk about processes, align them as well and only when everybody are on the same page they start detailing their parts of the project. During detailing they periodically check their results against previously established requirements – not with other’s results – and at the end we have something like Microsoft Windows It is very important to note that during definition stage in this model all stakeholders work in a true Common Data Environment with common metrics. It is their goal to find a way how to make different requirements compatible before they start realizing them. Software development is a highly formalized activity so they do it naturally, but the idea is: if we formalize our workflows the same way, we will get the same high level of collaboration. If and only if, I would like to say. In AEC we have Avanti model WIP-SHARED-APPROVED-ARCHIVED which is based on separation of works, doing them and then attempts to align results. Many people have faced with problems of applying this model when they have started working within one common model in Revit. Where are those domains there? People want and ready to work together literally, how should they organize the workflow without checking before sharing? I believe the experience of our colleagues from system engineering is a good point to start.
- As summary of what was said: The way to improve our work, to make it really valuable and ready to fuse with other activities – is to transform it into data-centered processes. It will make our workflows mathematically strong, robust and productive. To make this transformation we must refuse using so intuitive idea as information and learn how to rely on abstract data. Believe in Data! The key advantage of working with data is the ability to use their synergy and extract new values from existing conditions. To do this data should be processed as a whole like we did with spectra in my example. Indeed, finding a way to represent different data in a “single space” means that they really have something in common and we just need to extract this common and transform it into new value. Secondly, uniform data representation allows us to solve optimization problems easier which is very important when we deal with real construction tasks. Finally, we can play with data as long as we want but sooner or later we will start receiving false results because we will not be able to adequately understand too long and complex processing. We know when to stop, usually it comes from practice and we rarely deal with scientific research problems. After achieving this stage we should split our data and extract those which are ready to be detailed separately. For example, when we do a master plan we consider the building shape as well. But when we have found an optimal solution for the master plan we will process related data separately from the building data themselves, we do not need anymore to keep them together. But of course we keep a link between them.
- ARUP’s Project OVE aims to demonstrate advantages of BIM approach in real life in a very impressive manner. TheTree.Project aims to demonstrate advantages of Data-centered processes in real life. Following above mentioned principles we can present data flow as a tree. There are 3 domains: roots, trunk and branches. The roots domain is our initial data: requirements, variables, restrictions. They feed the whole process and their structure aimes to guarantee its robustness against future changes and challenges. The trunk is where evolution of our initial data takes place. We process them as one whole to grow up, to find new values and to establish a strong connection between initial data – the roots – and results – the branches. The branches present processes of analysis and detailing of the results we received from the main processing. They are task-specific or discipline-specific and aim to realize the potential of synergy found in data through real objects and solutions. TheTree.Project is not a static concept, it follows real life in growing: we do not start from developing roots, then trunk and then branches. For example, initially we have the main domain for client’s requirements and code restrictions as roots. We start collecting them into one system keeping in mind that later we will have to spread it into other more specific and detailed areas. Then we are ready to grow our trunk. It is thin and low, but it gives us the direction and fundament to process future data in a common data environment. To grow up we need more data, stronger trunk, we check every time where we are moving to, it is an iteration process. Then it is time to split first results from the main trunk and establish first branches which will be discipline-focused and split them further into secondary task-focused branches etc. until we achieve all our goals. And all this grows in time, so the structure is life.
- For example, if we consider the desired structure of working with building data in a life-cycle perspective, we will see the same picture. Its parts are discussed every time we talk about BIM, but it looks like we rather feel than understand what we need to do. I would like to suggest the following system architecture: We start as usual from planning. It means that we use a requirements management system to create a set of rules and constraints for future processes and their results. As I’ve mentioned, we rarely deal with research projects, so we always know what kind of data we need to start estimating our potential and establishing a platform for further work When we have collected enough data – again, it is a question of experience – and established a proper platform, we process our data in a common data environment to find synergy between them. We analyze the site, mass our building, plan it, do energy modelling to understand how it will interact with outdoor and occupants; we estimate possible structural scheme and construction sequence – basically, we will do all that cool things which they promote as features of modern software. We need to do them if we want to avoid problems later, not to solve them. During all these calculations it is easy to check the results against previously established requirements and add some new to control further deeper processing until we achieve “item” level of requirements. This is where platform software are really useful. We do want to keep all data in one format (or very close formats) to be able to process them as a whole. Again, we feel that solutions like Revit significantly help us during early, not detail, stage, when we need to manage our data, not develop them specifically. Sooner or later we achieve “item” level of requirements in some area. It means that this part of data is ready to be developed separately, task-oriented. From my experience, as a high-level overview, it happens in the following order: site – engineering systems – structural systems – architecture (rest). Each of these areas splits further into disciplines, sub-disciplines, etc. but the logic remains the same: we only realize in particular details those values we found during analysis. We need only check and approve against previously established requirements. Do we need platform solutions here? No. We don’t need it and even don’t want, actually, to work with unified raw data. We should use task-oriented, specific software, which help us develop particular solutions. Nevertheless, it must have strong link both with platform software we used before, and requirements management system we use to control overall work (V-shape, remember?). What is the final goal of data management during a lifecycle of the building? To produce a structure and content which can be used as initial data for future projects or demolition. This is where, being honest, I don’t see any work. There are dozen of more or less data-oriented CAFM systems, but they do not allow us to close the life of a building into a cycle. They provide an operation-specific environment, “sub-item based” which hardly ever can be transformed into roots for future projects. I mark top of branches as a color-filled area to highlight that we need some branches ending as roots for future projects – we should think about it, I suppose.
- Being honest, I don’t know any software or combination of software for AEC which could realize this architecture in practice. It is quite strange because I know at least one set of programs which supports this architecture in mechanical PLM, provided by Siemens on their NX platform. The main problem is the requirements management system, I don’t know any AEC-oriented or adopted. As for me, it is the answer to the question what substitutes Avanti concept of document management in data-centered model. It works in mechanical engineering, we just need to adopt their experience, not to invent a wheel. The second problem is common data environment for processing. It is still a trend to process data separately in specific software. Even BIM level 3 and OpenBIM concepts suggest to only store all data in a single place, but process them separately. It is more likely for the branches in our model, because they have to be linked all together, we just don’t show it here. In my opinion, it is critical to change priorities in our mind. Sometimes there is no way to provide smooth transformation from old approaches to new ones. Such a complex and over-disciplined concept as sustainability cannot be realized on the current manner. As I said, we are looking for interactions and their results. To do this naturally we should model our buildings or other objects in a literally common data environment, where we can investigate them on neutral mathematical basis. This will allow us to find new values much faster, get information reach results with far going consequences and formalize the whole process to ease its control. Again, it is radically new paradigm, we have not had it for the last century in construction, its realization requires new approaches, in my mind. There are some programs which motivate us to do analysis in complex, e.g. early energy analysis, but it is not enough. The idea shown in ARUP’s project OVE should be formulated as the main law: we work with life systems of systems (even if they are artificial), to develop them we must consider them as a whole. No need to go in details immediately, quite the contrary, we work with our systems step by step not going deeper until understand their connections on current level of detail. And as I mentioned, we need to realize the idea of a cycle in practice and focus on closing our projects by data structured to be used as initial in next projects or demolition. Let’s look at the parts of our model a little bit closer.
- There is not so much to say about requirements management system. It is not something new, our colleagues from mechanical engineering already have some. To implement RMS on a project we must have all key stakeholders from its beginning or their representatives. What roles are important is usually established in client’s requirements. Thus, if the client wants his building to be highly intelligent, automation engineers must be involved among main specialists initially. All requirements which can appear during the project, may be split into several zones. The core consists from 3 zones of initial data: codes, client’s initial requirements and project location which gives you a lot of data about our building’s environment. When we need more information we dig into details about particular technology of usage, best practices suitable for our project and site restrictions. Then we focus on questions of future development and operation of our project, look for support from suppliers to realize our design and possible construction restrictions. It is not the only true representation, but I believe, these are the main areas we work with in every project. The main difference which AEC-oriented RMS should have, is code requirements domain. Moreover, it underlies the whole system of requirements, if we don’t have codes in the common system, it is prone to critical mistakes. In most countries codes are not formalized and their direct implementation in RMS is hard. Nevertheless, there are intelligent libraries or tools to simplify work with them. I believe, it is critical to organize codes formalization in those countries who aim to use BIM as a strategy, to develop their construction industries. Mostly, RMS systems are used in software development projects. The main difference between RMS for software development is the need to link requirements and objects in models on all level of detail, so we can identify why this object on a drawing or in a model has such characteristics. If you look at BS1192-2, there is a way from Employer’s Information Requirements to Master Information Delivery Plan, which is a time- and protocol-based framework for information exchange. This is the focus of Level 2 BIM – Information Exchange. The next step, as it is proposed in OpenBIM concept, is to use a single format to store data, so we should not worry how to exchange it. The question is how to develop our project data and the suggestion is to use a V-model: we firstly define requirements and then develop the model according those requirements. During development there is a checking procedure. It is an iterative process, so we start from obligations, then need to establish system requirements, align them, do schematic design, establish sub-system requirements, align them as well, do detailed design, reveal item requirements etc. The main advantage is that no one does a work to be checked and only after approvement he can work further (and if not, he has to redo his design). In proposed model participants at first discuss abilities and alternatives and only then realize them in particular design. Of course, to realize this approach we must have an appropriate common data environment and software to process our data so effectively. This is described in the trunk part of our model.
- The most interesting and important part of our model is the trunk. There are 4 main domains of characteristics we would like to see in our construction project: Its location in surrounding context and interaction with it Its appearance, aesthetics and harmony Its performance and functionality And of course, its safety in possible dangerous situations Traditionally, these domains are presented in several disciplines: master planners, architects, MEP engineers and structural engineers plus some specialists responsible for safety systems for the last. Historically they have been developed separately, so, we have different platforms for each, several formats to store and process data within each and a lot of software with various functionality. Good to know that during last years approaches within each domain were unified and we now have GIS for geospatial data, IFC for, mostly, geometry but also for some other static characteristics of building components, also contains schema of connections between items FMU – Functional Mock-up Unit – universal format to store dynamical models, e.g. Energy Consumption Model for a whole building or its particular system, or even components FEA – Finite Elements Analysis – or FVA –Finite volume analysis – universal computational technique widely available because of powerful and cheap computers; for initial stages may be substituted by semi-empirical methods based on so-called analytical (simplified) models. We have already started looking for universal approaches to systematize characteristics and items, unify their representation and description. As far as I’m concerned, all efforts in this direction are “paired”: there are works on GIS-BIM interaction, IFC-BEM (building energy modelling), GIS-BEM (contextual adaptive performance), etc. We need more. We need to see the whole picture and prioritize uniform processing of all 4 domains. This will allow us to extract maximum value from minimum data and establish mathematically strong fundament for the whole project. Current tendency to collaborate in Web, use common so-called semantics, databases, clouds etc. is a global trend. Many vendors promote this approach and provide different software, no doubt, sooner or later everything will be presented in a unified manner. I only want to focus on the fact that it is only means, not a goal. The goal is to process all data together. So, right now we need to start engaging people to not just collaborate in terms of exchange discipline-specific information or data but to change their processes and make them project-oriented fundamentally. The main instrument for this engagement is to provide efficient methodology how to work with not only your data but with the whole project data. There are a lot of software, tools, add-ins, commercial and research works. When people present them their believe that everyone understands what the problem is. At the same time there is not so much attention to the strategy and system architecture, to explain how all those pieces of software interacts and what is the final goal. BuildingSMART organization uses process maps in their projects, so one sees the whole picture, the path made from steps. I love this approach and would like to create a “super-map” for main processes and activities for main types of construction projects to link particular software solutions with them and see what is going on. This is one of future works for TheTree.Project.
- The branches is the closest idea of what we have now. We still work on a discipline basis, so we have a forest instead of a tree. It is quite funny to look at how companies spent dozen of money, tens if not hundreds thousand dollars to “coordination” software like Navisworks or Solibri instead of investing in a collaboration one. Can you see the difference between these terms? Is it easier to solve problems instead of avoiding them? They really believe, and some dishonest resellers convince them in this, that coordination equals to collaboration and means buying a specific, new software for clash detection between already created models and sending notifications about detected issues. I have never understood the idea of trying to match several absolutely different disciplines which started from different points and have been developed with different level of details. And the only thing we can do in this approach is to coordinate them “geometrically”. To resolve a clash we have to go back into each model’s history, find why we did this and then compare reasons and possible consequences from absolutely different points of view. Usually, structural guy win. Sometimes - architects. Seldom – engineers. Not because of logic but just because of priorities, timeline, cost etc. I would like to see functionality of collaboration software as a connection between all discipline models with the root one and with RMS. This connection must be supported by the workflow – possible conflicts should be avoided on requirements definition stage, the Trunk. So, when they appear, everyone could roll back and look what was behind this when they coordinated requirements. It will allow us to see all consequences immediately. Often, people don’t remember how this decision was made, and can agree to change it just because they don’t see anything dangerous. How many mistakes have been made like this..? Branches represent development of models and their further split to task-oriented sub-models. From schematic root design to detailed one then fabrication drawings, installation documentation, as-built, etc. We currently focus on this, don’t’ we? Two aspects to consider: firstly, turn upside down current logic and work from a base model to discipline master and then sub-discipline ones with strong connection with RMS; and secondly, as I mentioned earlier, finish with data ready to be reused in next projects.
- I hope this short presentation gives an impression about my view on future of BIM. I would like to hear feedbacks and comments from professionals and enthusiasts. May be I am completely wrong, may be there are some solutions which already provide discussed features or this approach cannot be realized at all… Anyway, this is only the start. I believe it is an interesting topic anyway and its discussion will help us to understand better our strategy and goals, so the next step will be issuing a guidance dedicated to good practice in data management in construction projects. Based on those recommendations it will be useful to create a map for processes and activities to represent current capabilities, problems and future improvements. I rely on tight collaboration - and actually look for it – with programmers and vendors, without particular software all of this is just one more theory. And of course, as I mentioned at the beginning, I do believe in power of beauty, although I am bad at design as you can see. So, would be great to attract some designers and keep on improving visual part of this work, because it is not only for professionals but firstly for wide audience who want to get the maximum from modern technologies. Thank you for your attention.