Graphisoft’s new architecture for Architecture
It’s no secret that software evolves. Over the years, minor and major chunks are likely to get rewritten. With a major re-architecting programme underway at Graphisoft, Martyn Day speaks to Zsolt Kerecsen VP of Product Development, and Marton Kiss, VP for Product Success
Keeping a successful product alive over decades is a big task. Customers want new features, enhancements and improved performance — but they don’t want major user interface changes or the accidental bugs that sometimes creep in. Doing anything new with a much-loved brand is risky. It’s like changing a tyre on a car moving at 90mph.
Graphisoft’s Archicad product is 40 years old, but has continued to develop over its four decades: from 16-bit to 32-bit to 64-bit, the addition of Windows, its support for multi-threading, and for artificial intelligence, Apple Metal and Silicon, other capabilities.
At Graphisoft’s recent 40th birthday party, VP of product development Zsolt Kerecsen gave attendees some insight into the major software architecture changes yet to come. Many are already underway, designed to radically expand the way that Archicad works with the cloud and with future data workflows. These workflows might involve links to disruptive technologies such as blockchain, machine learning, augmented reality, algorithmic design, generative design and robotic fabrication. In short, Archicad’s code is under continuous review.
One of the most interesting aspects of all this is how Graphisoft plans to use cloud computing, giving users the option to run cloud services locally, either on their desktop or on remote servers in what the company terms the ‘Adaptive Hybrid Framework’. While Autodesk is increasingly cloud-centric, Graphisoft prefers not to force users to always be hooked up to the cloud and be able to perform processing locally on their own machines.
With this in mind, I recently spoke to Zsolt Kerecsen, along with his colleague Marton Kiss, VP for Product Success, about the changes coming down the line.
Martyn Day for AEC Magazine (MD): Looking back through history, how has Graphisoft looked after the code of Archicad?
Zsolt Kerecsen for Graphisoft (ZK): That’s a really good question. We have to take into consideration that the Archicad is 40 years old. At that time, the architecture, the thinking of how to build an application, was completely different to how it is today. You had to create layers: database layer, data layer, presentation layer etcetera. The hardware technology, the operating system technology were completely different. And the maturity of the programming languages was different. Forty years ago, there wasn’t real multi-threading, and if you chose to innovate your new technology, there was no JS. You had to write your own! To add a new technology would require you to take into consideration many, many things, before you introduced it. Even then, it was also quite dangerous, because rewriting something is always a tricky thing. So we have had to be extremely conscientious. If we went through the process of introducing some new capability, where was the value?
One value, from a software engineering perspective, is that we like to create maintainable code, because someone else will have to continue the programming, or do the maintenance. It’s much easier, of course, from an engineering perspective to maintain code when you maintain good housekeeping, always tidying things up as you go along.
But what happened 20, 30 years ago? All companies wanted to get to market as quickly as possible, and they didn’t really care about how ‘nice’ the code was. Investors were interested in how quickly you could get the product on to the street and recoup the investment. This meant that many different software architectures were created and we had to maintain those.
At that time, the most important code was written as monolithic applications. We had so many really big applications like SAP or Oracle, and software companies realised that this monolithic code, after 20 years of development, became huge mountains — not easy to manage, to modify, to find bugs, to re-architect or rewrite. It was a never-ending story. About 20 years ago, the industry started breaking down applications into smaller, more manageable parts.
It’s a very similar journey to what Graphisoft did, creating monolithic code. There was tons of engineering, architectural, structural, mechanical, plumbing knowledge inside. As software engineers, we had to sit down, think and calculate where the real value was. In some cases, we would identify a capability that was a small service and rewrite it. In other cases, we found that there were one million lines of code and we didn’t want to rewrite it again, because it took many years to create.
If we can define a functionality border, then we can make the code a service, by adding an interface. Then we can set the right API (Application Programming Interface) on how to connect to that. We have tons of APIs to let third-party developers create content on top of Archicad and we also use them internally.
With respect to your question, what have we done already is we started this separation. But in parallel to this work, we also reflowed and started to renew the APIs, not just in a programmatic way, but also in a philosophical way. We are going to create a robust layer for APIs, because of security, speed and to more easily support scripting languages or new languages, because the basis of Archicad is C++, which is a very robust, very fast and secure implementation. But now we can add additional languages like Python or other scripting languages, if needed.
Speed is super important. BIM cannot be super slow, of course, and younger users will not wait long for a function to react. We have to consider the overall user experience of performance, from functionality to workflow, and how easily they can use the UI
It’s work that is all happening in parallel. We are also renewing the entire test automation system, too. After checking every test solution on the market, we decided to write our own, because none of them were good enough from a speed and functionality perspective to be able to check the desktop code with many other applications. With the new test automation framework, and with welldefined APIs, we have dramatically sped up our testing time, whilst dramatically decreasing the number of test cases we have to run again and again.
MD: And am I right in thinking it must be even more complex for Graphisoft to programme, test and maintain Archicad, because you support multiple operating systems: Windows and MacOS?
ZK: Exactly. And it’s even worse than that, in fact, because when we started, there was just Windows, and then Apple, but now Apple has two different types: Intel and Apple Silicon. And it was just recently announced that Microsoft is coming out with an ARM version of Windows as well. So that’s actually four platforms that we will have to support in our portfolio. It’s another reason why we have to completely rethink how we are going to organise our development and deployment.
Stepping back a little bit, everything is about user experience. And user experience has three main aspects. One is the security and stability — we call this quality. We have to ensure that for customers who are using Archicad, the data will be 100%, 200% safe, whether it’s on the cloud or on the desktop. We need to guarantee that there will be no data loss. Without that assurance, any kind of nice functionality you offer will not be appreciated. Stability, too, is important. The software should run properly, and I’m not just talking here about functionality, but about ensuring that what the user sees, they get. So together, this is quality.
Second is performance. Speed is super important. BIM cannot be super slow, of course, and younger users will not wait long for a function to react. We have to consider the overall user experience of performance, from functionality to workflow, and how easily they can use the UI.
Finally, go-to-market speed is also super important. This concerns how quickly we react to anything, how quickly we can deploy to a customer and how quickly we react to customer needs. This applies to fixing or adding something. On the engineering side, with what we are building with this new architecture, the underlying philosophy inside of everything is the continuous integration and continuous delivery [CI/CD] concept. When code is a monolithic and full-desktop application, it’s hard to do that, as the customer has to reinstall the desktop application when new functionality drops. That was another reason why we are creating a new framework.
When you install Archicad, you install the frame, where you login, access security and so on. The content’s origin can be hybrid. If you run a desktop application, you have the benefit of deeper access to the operating system and the hardware. Browser-based solutions are limited. The content inside is what we call ‘hybrid’, because at that point, we are going to combine the cloud and desktop parts. You can download locally to utilise your hardware, if that makes you feel better. Alternatively, you can make use of the power of cloud computing, and store lots of data in the cloud, enabling you to work from anywhere. It’s just another possibility and totally down to the user.
A big benefit of this separation will be plug-ins or services. Now it’s much easier to create and define the smaller plug-ins. We deliberately call it a plug-in, because as a function, it’s a service that can run locally or in the cloud. Plug-ins work like Lego. You can plug in the elements you need and define what you would like to do, wherever you want to do it.
I mentioned before how quickly we can develop. Decreasing testing time decreases development time and also makes code cleaner. It also makes it much easier to manage legacy code. Legacy code can absolutely still be good, and if we can create a new border around that legacy code and put it in a plug-in, we can decide to rewrite it later, when we have a brand-new technology or idea.
Another very important aspect of this plug-in technology is the flexibility it brings when it comes to using different programming methodologies. As I said, the majority of our code is C++ for 3D modelling, when we really rely on the power of the operating system or the hardware. I still think it’s a good choice, and we don’t want to introduce a new technology for that. But for UI or mobile, we can bring in something new without having to reskin the entire software.
MD: In the human body, it takes a full 7 years for every single cell to be replaced. How much of your code is being rewritten in this current re-architecting?
ZK: It’s not too big. The good news is that we already have three plug-ins completed; for example, an analytical model was carved out from the big code, somewhere around 15 million lines of code. The next version of Archicad will already contain some of this new technology.
Marton Kiss for Graphisoft (MK): If you think about Archicad in terms of that human body analogy, then at the right time, it’s critical to be able to recreate certain parts, when it makes sense. But at the same time, going back to our roadmap and how we build that roadmap, we also create new things. So we have made a strategic decision to actually make sure that the new things that we create are created in a way that allows that type of follow-on strategy, that allows you to plug it in. From the technology perspective, the code that we are building is really modularised. So it’s much easier to maintain, much easier to integrate with other parts of our systems.
MD: From talking with Autodesk, Bentley and hearing the ideas that Greg Schlusener discussed at NXT BLD, it seems there is a lot of discussion around moving from files to data lakes — a fundamental change in outlook. Is this something that Graphisoft has a plan for, a BIM cloud?
ZK: User experience is our priority. If the user can update frictionlessly, they don’t really care where the data is. If it’s in a file format, or a data lake, or a database — whatever. We just have to ensure that they can record the data at any time they want.
We are absolutely thinking about renewing this part. But here, we are not talking about the focus being where we store the data. The most important part for us is how smoothly we can provide an update for our customers. So we call it a ‘frictionless update’. They just press a button and a new version is there.
With the concept of the data lake, I have a fear that if you store your data in the cloud, it’s a little bit harder to support offline work. We still have to support offline work, even if a user is offline for a couple of weeks or months. We have to take into consideration that one of the key benefits of Archicad was that it can run offline mode for quite a long time. In many places, there is no internet or it’s very hard to reliably connect to any kind of services.
It’s worth mentioning that Graphisoft is one of the few companies that supports older, unsupported operating systems as well! We are still supporting Archicad 17! [the current version is 26.] We try to be quite customer-centric and userfocused, of course.
MK: Let me give you an example of how we think about technology trends: a couple of days ago, Microsoft quietly announced its Windows ARM development kit. From our perspective, we are already looking at that, and we are already thinking seriously about it. We have actually already purchased that development kit, because we want to be among the first ones to support the new platform. If Microsoft comes out with an ARMcompatible operating system, manufacturers will jump on it.
MD: And what can you tell me about how you plan to deploy artificial intelligence in Archicad?
ZK: I’ve been working with AI for around a decade now. And what I have seen is that many companies use an algorithm and claim it’s AI, when it isn’t. I think where to apply AI is a million dollar question. Where is the right place in the business to be able to utilise AI from a technology perspective?
I’m working together with my team with universities in Hungary that are researching AI. Big data is the mandatory part, but how it’s applied, with probability theory and so on, means it’s not just the data. I think with our new approach, we will try to implement AI in the cloud first, and then somehow move it to the desktop path. But the first step is definitely that big data component.
Main image: Graphisoft’s ‘Adaptive Hybrid Framework’ helps the company bring new technology to market faster
The post Graphisoft’s new architecture for Architecture appeared first on AEC Magazine.
Powered by WPeMatico