The sweet spot for solution architecture with agile is in the 80% of cases where a business needs positively transformative change delivered in the short term, with a progressive roadmap for the medium-to-long term. The solution architect is also responsible for making the final decision on a number of technical issues regarding product development – technology stack, programming languages, frameworks, infrastructure, and security solutions applied. A solution architect is working closely with a variety of professionals and teams within the company to deliver the ultimate flexible, extensible, and workable product.
It is important to note that all of the architectural roles described are highly intertwined, and in a number of companies they can be combined under two or even one position. At the moment, there is no clear generally accepted division of responsibilities for the roles of architects, so indifferent companies, may differ and even have a different name. I’ve been preoccupied with the question of how a solution architect fits into an agile team. Those meetings, in the context of the sprint, have as first intent to remind to the PO that his/her story is taken “now”.
He may act as a bridge between developers, managers and
other communities, and spends much of his time translating and mediating between
them. A true architect must not be parochial, and this means gaining experience
in different what does solution architect do roles and fields. The main indicator of the quality of work of a good solution architect is the stability of the IT infrastructure and the speed with which it can adapt to the ever-changing business requirements of the market.
Mastery of UML allows quicker, easier, and better communication with the DLs and the developers. Architects also consider technical dependencies with other ARTs or Solution Trains, acting as critical collaborators in these Coordination activities. They collaborate with teams to reduce dependencies during PI Planning, helping teams make the necessary decisions and adjustments.
Architectural professionals relating to systems, infrastructure, and enterprise may have requirements or concerns about the product requirements. The main responsibility of the Architect is to create few constraints and develop a high-level of directions and influence of the scope of the product being developed. Hence, a Stakeholder acting as an Agile Architect influences Product Owner’s decisions and also has a say on the items that go on the Product Backlog such that the Architectural objectives are met. Project development per se is outside the solution architect’s area of responsibility but they are held accountable for meeting deadlines and using resources (financial, technical, and human) effectively.
The SA has the ultimate responsibility for making the technologies work together. As a result the SA role comes with a requisite level of responsibility for the success of the project. Where the development lead focuses on detailed knowledge of a particular area the SA is very broad. Instead of getting mired down into the details of implementing one specific thing the SA focuses on integrating various parts of the solution into one cohesive network that solves the larger problem. Another approach to becoming a SA is to become a distinguished Development Lead (DL).
This is a collaborative forum where decisions can be made about the design of each service, integration approaches as well as discuss any issues with the overall solution. Such a forum can be chaired and facilitated by an architect as they have skills and experience leading such activities. In the Scrum Team, there is no specific person who is referred to as an Agile Architect as in the team there are various members and every one has their roles to play. There may be many people who have knowledge about the Architecture of the product. Also, the requirement of a specific type of Architect may change whenever a new Sprint is completed based on the Product Increment requirements.
It’s not like winning the lottery where one day your name is drawn out of the proverbial hat. A person may find their way to this coveted role within only a few years of professional experience but more frequently it takes a dozen or more years to consistently find themselves in this role. The Enterprise Architect is responsible for establishing the portfolio’s technology vision, strategy, and roadmap. While we must acknowledge emergence in design and system development, a little planning can avoid much waste. Since The Open Group does not recognize a unique Solution Architect role a relevant link for these mentioned artifacts can be to the Business and Systems Analyst roles. It is also worth reminding that The Open Group does define Solution Architecture as something larger than Forrester (see aforementioned definition).
He or she
must become the solution’s “champion”, selling the vision and keeping it alive
in the face of challenges. Each group of stakeholders needs to understand how
the architecture meets their requirements. This requires multiple https://www.globalcloudteam.com/
representations of the architecture directed at different parties. Any architect
must model to communicate, but an agile architect will follow the principles of
agile modelling, and help the project to “travel light”.
This points out that Scrum may be ineffective when the Scrum Team has to start with a fully ironed out Architecture. The idea of Scrum is that Architecture should emerge with every Sprint and develop as the product is being developed. The best way for an Architect to play a role in Scrum is to be part of the Developer as they will have a mutual responsibility for all the work including the Architecture. An Architect is required in a Scrum Team to lead the direction of the product development as every Sprint is completed.
It is this conversion part of the role – the role of the SA -that most often is underestimated in its complexity. Just as the ability of the Functional Analyst to create a requirements document is one part science and wrote procedure so is the creation of the architecture. Creating effective architectures to create a solution requires the careful balance of dozens of development concepts ranging from “Keep it Simple Stupid” to “Fail to Safe”.
SAFe architects embody the new way of working, participate in creating the organization’s (Implementation) Roadmap, and help accelerate the adoption as Lean-Agile leaders. Architects and teams collaboratively define Enablers in the roadmap to support exploring technical options and building the architectural runway, providing early feedback on achieving those milestones. Teams provide feedback on architectural decisions as they implement features balancing intentionality and emergence. In fact, the picture is even more complicated, because as the system matures
a team of people become involved, each with a different role and focus.