Software architecture is an awful word that give the imagine of a senior developer that gives standards and patterns without even building any software since years. That's how Martin Fowler started his talk about this topic. His talks are brilliant and full of inspirations.
Software architecture is the art of building reliable and scalable applications that keep performance over the time and give the ability to continuously integrating new features, setting patterns that can be embraced and understood by the others.
Code is important! If you are a technical person you need to have the notion of the technical skills required to build straightforward solutions. You need to keep in mind the scalability, the continuous integration needs, the performances, the quality more than all. You need to keep in mind the integration and relationship between components that make the system.
If you go to a senior developer, he/she would know about the overall components and solutions they are working on or need to be implemented. An expert developers instead might have a shared understanding of the whole system design but a software architect must be able to build and encourage the understanding of the whole vision, the global design as it would be a social thing where everybody must be able to understand easily. A good software architect must have the clear vision and the right design decisions early on or at least be able to get it right early on. Said that, it's not the component itself that matter but the whole picture and definitevely the why we are adopting that kind of solution that must be understood!
Why should we care about software architecture?
Well, one of the most important thing to keep in mind when designing a software and solutions architectures is the quality. We need to put much effort on quality so we can build more features for our next releases throughout a continuous integration.
Unfortunately, most company does not understand it because they want the applications done earlier to get earlier benefits. This was true in the past. But nowadays technologies are increasing and changing every day and this approach is not convenient anymore. The old approach may give some benefits soon but not in the long term. And the long term is what we need to have in mind when building outstanding software architectures.
Furthermore most of the companies do not understand craftmen and software artisans. They only rely on economics world. And economics always win! And the first element left out for economics purpose is the quality.
In fact, we can build good architecture that are pleasant for our external customers and that are cheaper but with a very low internal quality. Higher internal quality will often cost more and that’s why quite often projects are only built without quality and with no long-term vision in mind. The external result may be much the same for the customers/users but with poor scalability and huge code hard to change internally.
So why should we spend more for better internal quality?
Well, the difference is related to cumulative functionalities. I mean, you can build something quickly with a monolithic solutions and get benefits up front. But for continuous integration purposes, we need to keep in mind scalability and quality. These give benefits in the long-term since we can implement and integrate easily new functionalities without messing with the whole application. With a better internal quality, we’ll be able to have more features more and more quickly and that’s why a good architecture is important. And there's even an economic reason, as if we don't take care about quality in our architecture, in the short term we may win but on the long term we’ll be quickly loosing as every new implementation may take too much to be integrated due to the poor design and low quality.
Who needs an architect?
Well, all those companies that may want to improve their revenues with a long-term approach reducing costs of maintenance and easily scaling their solutions keeping track with the market and customers demands. Most companies are adopting this approach understanding the value of the long-term architecture, building reliable and scalable software architecture with quality in mind. Those companies that won't adhere to this new approach will be facing trouble loosing their business and markets against those new solutions adopted by the others that may be responsiveness and scalable.
Which solutions can be adopted for a better software architecture?
There are many kind of architecture that should be put in place for a good software architecture that gives meaningful benefits. We may start with a continuous deployment pipeline!
The deployment pipeline is the key pattern that enables continuous delivery. A deployment pipeline implementation provides visibility into the production readyness of your applications by giving feedback on every change to your system. It also enables team members to self-service deployments into their environments.
Continuous integration must be adopted to ensure smooth deployment processes in order to increase responsiveness and quality. This may be reached out throughout an holistic approach to delivering software. First, it is important to train the development team to write more production-like software, unit testing the software against a production-like environment, always automatically up to date, enabling auto environmental regeneration with scheduled tasks. Maybe, trying to create simple task for complex operations through a button click to regenerate complex environment from the production one. There are good solutions for this.
Furthermore, it is important to take a step forward and implement deployment processes back and forth from test to production and back to test again. Increasing this kind of processes, it will enhance the way the final product can be continuously integrated and improved or bug can be quickly fixed when in maintenance mode.
Another key success factor is the code refactoring. Refactoring is one of the most important skill an expert developer must have. Lots of code have been written and most of it is poorly scalable. Even if you think to implement one of your own code to add any kind of your new ideas, you will be struggling with what you have written in the past. This is due to low attention to quality with a willingness to finish ealier with a short term vision. A good software architecture vision is for long-term approach.
Nowadays, one of the most reliable pattern to a good software architecture is MVC pattern used everywhere, I hope, as it is a common layered architecture that separates the three most important software concepts: the Model, the Controllers and the Views.
This pattern is one of the best approach for developing reliable and scalable code but not the only approach ever. In fact, even using the MVC pattern, when developing huge amount of code, a good organization in modules is clearly required. That is because when maintaining such huge softwares, if it is not organized into modules, it must be understand in its whole complexity before integrating something new. Instead, just understanding the module to be implemented itself will already enable the new integration.
By the way, we are still talking about monolithic applications for sure that, wheter organized into modules, do not resolve our main purpose: full scalability and quality maintenance for a better continuous integration. In fact, MVC by itself it’s not enough, as already stated.
So far, we have approached softly the microservice concept by using the module organization of our application and.... here we are. The very best approach for software developing, and project management also, is microservices architectures. This barely new concept is the future of development life cycle process as already adopted by great companies like Amazon, Google, Netflix and others.
A microservices architecture is defined by APIs management that allow also a great project management by definition. In fact, it helps also organizing the entire development life cycle into pieces and multiple little teams each of them implementing a different solution for the whole application. It is a Technical Project manager duty to organize and integrate the whole picture to get to the final result.
With microservice architecture, services must be kept small and they are never exposed directly to the user interface. So the MVC pattern can be followed for the front-end application with less or no business logic using dedicated front-end servers with load balancing and whatever, and API services built to deal with the business layer in order to not redeploy always the entire application but only few services whenever required, without impacting the final user experience directly.
This approach allows a full scalability and continuous integration independently and can be always monitored closely. If there could be any downtime or failure in a service, the entire application will mostly continue to work without affecting the final user experience, allowing a better maintenance.
Moreover, another pro for the microservice architecture is given by the fact that each microservice might not rely to the same server or shared memory of the front-end application as instead a monolithic application may do. In fact, developing microservices may allow a better solution architecture with more granularity and performance scalability based on the business requirements.
This approach enhance the most important factor and key success for every company that is based on economics. In fact, while we can understand the code, the solutions and all the architectures, most of the companies just understand business and economics, so to speak, revenues.
With a microservice architecture, one of the most important success factor is the faster iterations and continuous improvement and integration. This leads to quick implementation maintaining the quality of the software and of the overall architecture in the long-term generating high revenues not just for the short term, now and quick, but later and for a long time on.
So to speak, this is the best approach an organization may look for to increase and maximize productivity and embrace agility.
There are lots of complexity around microservices and continuous integration and improvement. Here I talked easily about some low profile real examples but for enterprise architecture the complexity increase but even the result are astonishing. Dig more into the link provided above to know more about microservices architectures.