Once the development leader has internalized their portion of the architecture the SA must continuously motivate and reinforce the good work that is being done. It is necessary for the lower level design and approach to match the higher-level architecture for the solution to be cohesive. That elegance helps to maintain cohesion between various parts of the design and encourages simplicity. It’s the art portion of the architecture that makes it elegant. They must also see the art portion of the architecture to get an appreciation of the subtle nuances of their portion of the architecture. Development leaders need to buy into and accept the architecture, to know how the pieces will fit together at a high level. The final component to the role of solution architect is the motivation and guidance of the development leads. Reviewing the pattern allows the architect to refresh their memory on the details of the pattern and to evaluate what additional guidance they will have to provide if they choose to use the pattern. Patterns are released through research and can come from places such as Microsoft’s software development libraries. Patterns are previously described and validated approaches that can be used to create portions of the solution. In addition to research on technologies and approaches critical to the architecture, there is often a review of patterns that might be useful to the architecture. This process can either be done alone or depending upon the size and velocity of the project can be delegated to a development lead. For instance, the SA may test to see if USB or serial port access is available from Java if there’s a need to read a device without downloading software. The research may be targeted at testing a technology that will become critical to the architecture. For instance, there is often a fair amount of research that happens during this phase. In the process of converting requirements to an architecture there are often parts of the SA’s role which seem out of place. 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”. 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. It is this conversion part of the role – the role of the SA -that most often is underestimated in its complexity. This conversion is based largely upon the previous design patterns that the SA has been involved with in the past through reading and staying abreast of the latest techniques, or through personal experience. The essence of the Solution Architect (SA) role is the conversion of the requirements into an architecture and design that will become the blueprint for the solution being created. They then remain involved throughout the balance of the project.Ĭlick hereto see how the SA fits within the full organizational chart. The Solution Architect becomes involved with a project at the time the Functional Analyst (FA) is developing requirements. They are responsible for the vision that underlies the solution and the execution of that vision into the solution. The Solution Architect is the person who organizes the development effort. (If you’ve not been following the series, you should read Cracking the Code: Breaking Down the Software Development Roles.)įor many developers perhaps the most sought after role is the role of the Solution Architect. If you’ve been following this series of articles you know already that every role in the software development process has its unique requirements. We may make money when you click on links to our partners. content and product recommendations are editorially independent.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |