Software Architecture Then & Now
Architect at least in the world around me, which is software development, has become a managerial role providing guidance and getting the job done by pushing the team. This is changing slightly with the introduction of the Cloud Architect role, where the architect is coming up with the component/deployment diagrams required for the solution. Yes, they truly have a better understanding about the software/ systems in general over the other team members, but I truly think they can do better and address the needs of the role better with a streamlined process that has been there for a while, knowing well that you can customize and adjust as it fits and not having to follow the entire process and draw all the diagrams rather than making these architectural decisions afterthoughts.
Architecture Then
If you were in a software development company, you would get an SRS (System Requirement Specification) which would be having the software to be developed. After the formalities of signing the agreements, etc, you would get down to work, which is developing the software. If you had an Enterprise Architecture practice, the process will hand over an initiative that had to be taken forward. The process from there onwards can be shown as follows,
The tasks that need to be followed are written next to each step in the circle. What I want to highlight here is that if these steps were followed, the chances are that the project would have been successful. Also, it is important to give some serious concern towards the Design time concerns, Systemwide concerns, and the runtime quality attributes. I have noted them down below for your reference.
Hereafter, following the best practices, the team would develop the software, do the required testing and deploy the solution. Testing best practices and deployment dest practices too had to be followed for the successful completion of a project. If you as an architect was concerned about the above mentioned and did the needful then you had done a good job for the success of the project.
Architecture Now
With agile practices, things have evolved. Agile practice can not be only for development or management of development. It too has to span for other areas including architecture, to keep up with the ever-changing and demanding business requirements. The way the software is developed and deployed too has contributed immensely to this change, including Domain-Driven Design, microservices architecture, containerized apps and etc.
Let’s start by looking at how Enterprise Architecture as a practice has changed to provide the projects/ IT initiatives that have to be carried out by the team.
From an architectural perspective, architecture development in the strategy formulation phase includes coming up with the Intentional Architecture which is mostly a long term view. Intentional Architecture is not something cast in stone, but mostly the best effort, collection of light-weight forward-thinking architectural view to guide further work close to implementation. When it comes to strategy execution, architecturally we are more concerned about the Emergent Architecture which is a short term view developed closer to the implementation phase. This is influenced by many operating factors and leverages and validates intentional architecture.
Based on the Strategic Themes that were derived out of the company /department vision, it comes into light the strategic objectives and initiatives. It is those initiatives that become projects and tasks which are taken cared of by the development teams.
With this change and the constant demand for scale and change, we are more focused on developing microservices with DDD (Domain Driven Design) and let’s see how we would take a strategic initiative to the next stage as an architect.
We will have to get the requirements for the software development and that could be carried out in the form of Event storming where we could identify the Domain Events, Commands, Policies, Users, and external systems. Once we have these in place, through context mapping, we could define the boundaries and identify the microservices that may collaborate to provide the expected functionality.
When you have the identified microservices to be developed, it is all technical as before and you will have to decide the scope, identify the technologies and be concerned about all the quality attributes to provide a proper system. Other than the traditional terminologies, we may also come across event sourcing, containerization, container orchestration, and continuous delivery to name a few. As the architect, you will need to have a thorough understanding of all these and how you will successfully deliver a project. Applying architectural patterns and cloud design patterns are two other areas that will play a major role, in the successful delivery of a system of scale.
My expectation was to bring to light the key concepts and its flow as a starting point so that different areas could be discussed in detail, most probably with code samples and so on. Thanks for reading.