It's been a year since the exhibition of QCObjects in the Web Summit and now a lot of people and companies are interested in placing QCObjects at the very core of its enterprise software solution. But why is it? Think for a moment about what is what a CIO of a big company should be looking for... She/he is looking basically for tree main things: To lower costs of enterprise software acquisition To enhance speed in the adoption processes of new technologies To find new sources of income for the company If a CIO isn't looking for any of the things above, she/he is not doing a good job and the company is condemned to fall soon. Because technology is actually the core of any business today. Right? Whether your company sells shoes or it does sell computers or even industrial machine parts, today it's not just about using technology for the better, it's all about technology. And most of the time, your company will have to build its own technologies in order to survive the rude competition out there. Lowering the costs of enterprise software acquisition So, in this search of ways to make your own technology, you (as the CIO of the big company) have to choose a stack of solutions built on software and hardware to enable your platform to achieve innovation that differences your company from others. You hire tech experts and put them in a role of project management, they hire software developers, and in between you need to bring them some tech definitions like the software architecture of your platform, so they can build the modules following the main definitions. And this process isn't just when the company starts as a startup level. It is always needed to be doing by someone like the CIO, and when the company is starting to grow as your big company does, you should relay in software architects to expand your tasks to detail. In this whole process of your role as CIO, if you don't chose the right technologies for your stack, the result isn't only that your doing a bad job, the final result is that the costs of your tech stack will grow to the sky and finally your company will fall in bankrupt as they can't afford to pay the bills to keep running the whole operation, and of course, you'll get fired. Improving the adoption processes of new technology But, to learn a new technology, most of the time is an expensive process. So you have to find a way to spread the word inside your company to get users to adopt the technology better. Because if not, you'll not be allowed to change a comma of the initial tech proposal you made for the company, and if you can't change it, you can't innovate, if you can't innovate, again, the costs of your old fashioned operation processes will rise as you can't build new technologies and applications to improve them, your company will be again in risk of not having the control of the main operation, and as a consequence, you know what happens. Finding new sources of income But, what about when you are running out of ideas to reduce costs in the tech stack? You've fired enough people out of your team, you got only a few full stack developers working on covering the main code support needs of your company. You've lowered the costs to the baseline, so you need something else keep the operation of the company up and running. You need to find a new purpose for the change. You're gonna go to your board and sell them the idea that the business is going well but it needs to be expanded, and using the same core of the technology that your company already owns, they can build new sources of income and your main task will become to find the new pathway, to build a new roadmap to innovate in a completely new product but using the exact same tech stack you're currently running. Right? You can build a new team to help you to develop the new features, you can also find new sources of funding interested to support your company to grow and expand its business. Choosing the right full-stack framework and beating the technical debt But, every task you and your team do, every new idea you and your team have, and every part of any new strategic step you go forward relays in the choice of the right full-stack framework. If you don't do it well, instead of finding ways to lower costs, improving the tech adoption and rise more money to expand the new sources of income you've found for your company; instead of all of this, you'll surely meet a new enemy called "technical debt", and this enemy isn't resting or waiting for your decisions. Technical debt is basically what you or your tech development team have been abandoned -bellow the carpet- of the software application you're doing to ensure speedy releases. And it is dangerous, and it's growing exponentially while the time passes. In the past years, the technical debt has killed more companies than any worldwide economic crisis. I don't need to tech you about the technical debt because probably you've already experienced it inside your current big company, right? The most effective way to reduce the risk of technical debt is to focus in improving the development of the most critical features based on its long-term impact. Based in tree goals/principals: Don't repeat yourselfWrite clean source patterns specifications and documentationSplit your operation in layers That being said, your full-stack framework needs to help you to address these goals Don't repeat yourself This is the very basic principal for the learning of design and source patterns. It means that you should not need to rewrite the exact same line of code every time you make a new application or program. You can and you must reutilise code! But you should not need to rewrite that code to being able to reutilise that. Write clean source patterns specifications and documentation In your big company you need to do a lot of coding for very specific purposes. Not just another landing page or e-commerce store. Sometimes you need to wrap some data from sources that are not databases, and process that data in a new format to display it in different terminals and devices. Your company has a knowledge base platform for documenting everything. It's not enough, you need to document the source, and it's not even enough. Split your operation in layers Your entire operation is a main block, and any department inside of the company has its own needs of functionality, so it should be easy to represent the business as a set of blocks or a block chain. Cool, right? NO. The fact is that a big company as yours or as a bank or a global assurance service is more complex than a single blockchain. It is actually a multi-layer architecture. In a multi-layer architecture there's a large layer that runs across the organisation and does the common functions. For instance, you can run a login micro-service in that layer, or an internal support ticket submit form. You are also leaning some parts of your transversal operation on third party SaaS platforms that have an API documented for your specific needs. So you got a SaaS layer that you can even split it into other sublayers like the API SaaS layer and the SaaS monitoring dashboard layers (as you probably will have more than a dashboard application running to measure the exact same source of data but with different stakeholders). And then, the core of your business. It has a business layer that communicates the third-party APIs and a transport service to standardise the format of your data. Also it has a core legacy layer with the baseline micro-services (by example: process the raw order payload) You don't have the exact same layers as well as you don't have the exact same functionalities on every department in your company, so it's not a blockchain. Choosing the right full-stack framework, what are the alternatives to QCObjects In the process you're understanding the way your big company really works, what is the real function of your role as a CIO, and what is the real architecture model your company has and the way to reduce the risks related to the technical debt, you have to make a choice and get a new tech stack today. Whether to replace the current stack or to integrate the new technology with it. And some current alternatives to build the full stack are: MEAN Stack (MongoDB + Express + Angular + Node) MERN Stack (MongoDB + Express + React + Node) Spring Boot + Bootstrap (Java + JavaScript + JQuery) Laravel + VueJs (PHP + JavaScript) Django + Bootstrap (Python + JavaScript) QCObjects (Pure JavaScript for Front-End and Back-End) The variables of choosing a good full-stack framework I've asked so many developers and CIOs about what are the variables they are measuring to have benefits of a framework. The most of people think that are commonly based on the popularity of the framework and the companies that are currently using that, as if it would be a warranty of something. If you really want to get some benefit from the framework your company is using, the right variables that warrantee the success of building your full-stack are the ones based on performance and the fulfilment of the principals that every CIO must to have in mind (to reduce costs of enterprise software development and acquisition, to ease the adoption of new technologies in the company and to find new sources of income). So let's measure the current alternatives with this variables in mind: Reducing costs of development The average cost of a development of a new application MVP is between 80,000 to 150,000 USD in an AVG time of 10 months for a team of 5 (Team leader + Product Owner + 2 Full Stack Devs + 1 DevOps) To develop a second MVP using the same stack the team as learned before, it will cut the cost in a percent as the team has already developed the main features that are needed in almost every MVP they gonna need. So let's do reduce costs with Angular: To reutilise an Angular component you have to copy the code of the component definition to almost every other place you use it. So you need a full-stack dev with at least 3 years now experience in Angular just to copy and paste something and then rename it. Because it is needed to know the exact place inside of the spaghetti code in the app to pick the code and then paste it in another part that normally will not work well for the first time. Ok, I don't think it is gonna reduce enough cost of the project. Let's do reduce costs using React: I gonna leave this line for the comments Let's do reduce costs using Spring Boot: Spring Boot has a lot of development, a huge community, a bunch of tools to help the source code edition. But if you have to make a small app with a hello world text you need to define the complete MVC pattern that is supposed to be compliant with the principal of inversion of control. And because of it is based in Java, you got almost no control of exceptions. 99% of the code maintenance work in Java corresponds to exceptions that are not from the system hierarchy. So that could be understood as well as only the 1% of the exceptions are enabling code for reutilisation, what is in fact traduced to more hours of development rewriting the exact same thing. I don't think this is gonna reduce enough cost of the project as well. Let's do reduce costs using Laravel + VueJS: Laravel has also a huge development community and VueJS is a raising framework made by Evan You and scaled in a very smart way. You need 2 kind of experts in two worlds that are completely different from each other. One from JavaScript and VueJS and the other one from PHP and Laravel. Split the app into micro-services and for every single team you'll have to have a minimum of two (2) full-stack devs that understand both languages. Let's do reduce costs using Django + Bootstrap: Django is based in Python that is a powerful language. Also it is fast, but day by day the Django architecture is getting complex and it is needed to copy all the models from one project repository to every other to keep consistency with the data handling layer. To be understood, if I change a field name or a field attribute value in the database, the code of almost every application in the company will be broken and the services will shut down. This is increasing costs of maintaining big scale operations in companies using that framework. Also in your team you need a python expert that is not cheap, and you can't escape from javascript as Django is meant only for back-end even with its supper extendable admin panel. Let's do reduce costs using QCObjects: QCObjects is a full stack framework made in pure JavaScript, it is lightweight and flexible, and it is mean for having the back-end and front-end together into the same project. One powerful feature of QCObjects is that you can publish your own app-templates and then you can reutilise them using one single line of code in the CLI. > qcobjects create --custom=myownapptemplate app Just this thing is cutting your initial costs in half and exponentially on every round of innovation where you have to build a new MVP. And in QCObjects Enterprise Edition, you can save your app-templates with private code safe in the QCObjects Enterprise Cloud Platform, that is increasing your security and increasing your infrastructure performance. Easing the adoption of new technologies QCObjects is meant to have the back-end micro-services and the front-end together but not mixed. You have the same syntax for both (back-end and front-end) but you also have compatibility with other old frameworks and technologies. For instance, if you got some mobile app made in Flutter and you need an API, you can use the QCObjects Built-In HTTP2 Server to develop that API. If you have a web app based in Django, you can use QCObjects in the front-end to allow Django to manage dynamic rendering of components. With QCObjects HTTP2 Built-In Server, QCObjects is a huge alternative to Nginx but it also works on Nginx or Apache Web Server. QCObjects HTTP2 Built-In Server is meant to allow developers to include advanced features in their web apps and to have a two way communication within the the front-end with the back-end. Find out more about QCObjects Interceptors and Micro-Services in qcobjects.dev Finding new sources of income With QCObjects you can make app-templates for your company or yourself and you can sell them to others. You can remain the LGPLv3 license of the initial app template or you can change it to another that is compatible with. The LGPLv3 license allows you to privatise some parts of code that are sensitive and you're not enforced to publish everything into the open source scope. Also, you can patent your code and become the owner of it. These benefits that seem to be obvious are not like that using other licenses. I hope you can read this article carefully and take the references of other frameworks as a technical and educational purpose only. The comparisons made here are meant to expand your mind to a new horizon and way of thinking and are objective as much as they can be. Previously published at https://devblog.qcobjects.org/why-you-should-use-qcobjects-as-the-full-stack-framework-for-your-company-ckgy9pere00ve20s1hszh72lo
