Web apps are everywhere: There are websites with lots of information, social networks for chatting and sharing, and intranet applications that help companies become successful.
But what do you find under the hood? How are these applications designed and constructed? What do they consist of? And what do they cost? Here’s an overview.
Die vier häufigsten Bauarten sind:
Obwohl sie sich von außen ähneln gibt es große Unterschiede im Cockpit, unter der Motorhaube und am Preisschild. Sehen wir uns zuerst die Scratch-Bauart an.
The four most often used building styles are:
Although they all look similar from the outside, there are big differences regarding the cockpit, under the hood or the price tag. Let's first take a look at the scratch construction method.
From Scratch used to be the most widespread construction method. Whoever likes to use it, needs to start from the very beginning: The technical plan. An architect designs all components from scratch and develops them together with a big team of experts in order to meet your requirements.
Scratch users often have special requirements for every level that have to be taken into account. The designing, constructing and correction of bugs takes a long time, and a team of experts is not exactly inexpensive – but as a result you'll get a product that exactly meets your desires and requirements – down to the smallest detail.
However, if a problem in the operation occurs, only the manufacturers' network will be able to help – and they are very expensive due to the big team of experts, or they can even be booked out.
There are easier ways though – at least that's the motto of developers using the Library Collection building style.
The developers discovered a huge collection of Open source components that are jointly built and optimized by a lot of volunteers and are given away to interested developers. Just like that – because they want to make the end users' lives easier. And they have succeeded!
If anyone orders a Library web application, the developer will choose the one out of thousands of available single components that will meet the demands of the user and with which he has already gained positive results before, or which were recommended to him. He compares them and chooses some of them. Then he puts them together so that they work together well and adds what might still be missing. Done is the Library application!
However, after only a few months or years, Library users might be confronted with problems. For example, if the application suddenly becomes unavailable. This might be the fault of the database, the server load, or due to a hardware defect. Since the Open Source components are very popular, there are a lot of experts for each component but no one that knows the individual compilation of the respective product or understands the big picture.
Correcting errors in a product or continuing its development is harder for someone who does not know how the parts are arranged under the hood and how they interact with each other. If the manufacturer already backed the wrong horse choosing the wrong parts, it is possible that a severe error of the volunteering makers – e.g., in the core of the product – will never be corrected. That's where the Framework construction method comes into play.
Framework apps mainly consist of Open Source components as well. What makes the difference is the choice and combination of pieces. And that's how it goes: The community of developers constantly exchanges their knowledge about products and components, compares them, and everyone shares their personal experiences.
Over the time the developers have realized that, while the end products differ strongly from each other for the user, certain technical details are mostly the same – in about 80 per cent of the cases. That is why the community decided to regularly build a 80 percent product and to offer it as an Open Source solution: A framework.
Developers of framework apps often use those 80 percent products as a base for each project and then add those 20 percent that meet the individual requirements. All components are combined in a unified form and are often interchangeable. Conventions might change now and then but everyone who knows them can maintain and improve framework apps, even if the production was several years ago.
Content Management Systems are often innately equipped with a bunch of features so that they can be used by as many users as possible. In order to make a CMS operable for its users, developers often have to deactivate certain features beforehand or have to adjust settings in detail. If they do not do this, the end product will often be overloaded or cumbersome.
Special requirements that are not yet included are often harder to add when using Content Management Systems.
Various building styles lead to the desired result: Scratch applications design everything from the scratch. Library Collection apps use single Open Source components, Framework apps are based on extensible shell constructions, and Content Management systems are all-round solutions for most users' requirements.
The selection of the right construction method is the first technical decision for every product. The chosen construction method has an essential impact on the time-to-market (TTM), the extensibility, maintainability, costs and potential follow-up costs.