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 responsive and scalable.
What solutions can be adopted for a better software architecture?
There are many patterns that must be understood for a good software architecture in order to provide meaningful benefits. We may start with a continuous deployment pipeline, for instance!
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 some 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 the MVC pattern. 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 small solutions with a very well-defined contained scope. In fact, even using the MVC pattern, when developing huge amount of code, it starts becoming overwhelming. And that's even more evident in software that was built to fit few requirements and then, it grew up to many lines of code to fit more and more requirements that were not in the same scope of that monolith. For this reason, most of the time, a modular approach is even better and suits most of the needs of software solutions enabling new further integrations.
By the way, we are still talking about monolithic applications that yet, although organized into modules, do not solve our main purpose: full scalability and quality maintenance for a better continuous integration. In fact, both a monolith and service oriented approaches are still not enough for an enterprise wide implementation that needs to be agile, flexible, scalable and provide high performance.
So far, we have approached softly the microservice concept by discussing both the monolith approach and the service oriented module organization of our application. Whereas these two architecture patterns have been vastly used and are still leading the industry, a very nice and clean approach for more enterprise oriented software developments, and ease of project management indeed, is the microservices architecture. This concept is the future of development life cycle as already adopted by great companies like Amazon, Google, Netflix and many others nowadays.
A microservices architecture is defined by self-contained services with very small scopes that interact between each other by the mean of an orchestrator, most of the time an API management. More complex implementation of a microservices architecture are also based on Event-driven architecture patterns but I would rather write something more specific next time.
The microservices architecture pattern also helps organizing the entire development life cycle into pieces and multiple small 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 microservices architecture, services must be kept small and they are never exposed directly to the user interface. So, from an MVC pattern we can move to a SPA pattern for the presentation layer. Business logic can be split to several services to deal with the business layer. This will ease the way application are deployed without directly impacting the final user experience. The big challenge in these kind of architectures is always the services inter-communication that needs to ensure data consistency. The approach changes drastically from an ACID design pattern that ensures data consistency in a transaction to an eventually consistent approach where more complex structures must be taken into account.
However, this approach enables full scalability and continuous integration independently and can be always monitored closely. If there is any downtime or failure in a service, the entire application can mostly continue to work without affecting the final user experience, allowing a better maintenance and experience.
Microservices architecture might not rely to the same server or shared memory of the front-end application as instead a monolithic application may do, by enabling better solution architectures 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 discussed easily about some low profile real examples but for enterprise architectures, the complexity increases. However, even final result are astonishing. Dig more into the link provided above to know more about microservices architectures.