Asking a different question- Architecture
In the part 2 of this article, we reflected on product management as aspects of build vs buy decision. In this part we will look at the technical considerations for the build vs buy decision.
As an architect, then the responsibility is to build an architecture that is resilient to changes and decisions made on different blocks of the application. Being Cloud native for a software product is given these days. Factoring technology considerations that will help us go to market quickly at the same time build an architecture that is capable of accommodating changes in parts of the system without disrupting other parts of the system becomes very important.
I am particularly excited about MACH as an approach to building scalable technology products.
MACH architectural approach provides the needed principles to build a resilient product that can stay robust through the evolution of the product
Microservice based (Modular) | Decompose the product into smaller self contained independent services that can be managed , updated and changed without impacting other services |
API - First | Provide API as a primary method of integration between these services so there is no tight coupling between the two services. This will enable us to change the underlying services without having a need to change the services that utilize them for their business functionality |
Cloud Native | The services are conceptualized and developed on cloud hence provide the required properties like hyperscaling, security, integration etc out of the box |
Headless | There is a clear separation between the business logic and presentation. The application components interact with each other using these headless interfaces. |
Creating composable architecture with abstraction that can provide the flexibility to change the underlying system without compromising the integrity of the architecture becomes a critical success factor in the technology system’s ability to stay nimble , agile and relevant to changing business realities.
In a world where SAAS solutions are becoming an integral part of our technology landscape, our roles as architects have evolved to become the solutioning experts who understand their organizational technology landscape and carefully devise an architecture that ensures scalability, maintainability, security , performance and availability through these integrations. In large enterprises where solutions are being bought or built every day, we will need a common language among all the architects to ensure we are doing things consistently and the way it protects the systems from becoming brittle or unsecure. Putting together a checklist of all questions that the architects have to refer to in appraising a system as it is being evaluated for use can go a long way in ensuring all of the members of the architecture team are following a consistent practice.
Many organizations have invested in capability centers or centers of excellence(example: data privacy, data , security, cloud etc) with an objective to go deep into each aspect of the systems architecture. These centers become invaluable assets for architects to leverage as they make their decisions of integrating newer systems into their solution.
The decision to buy or build is a combination of business ,strategy and technology teams together. However, the responsibility of ensuring the technology systems stay robust and resilient falls in the hands of the technology teams.
How are you or your teams handling the architectural aspects of buy vs build decisions ?