What does it take to be a Software Architect?
Published: 2019-08-06 04:43:56

As an experienced developer with over 10+ years in software industry, I always wondered what it would take to be an architect. With a passion to be an architect, I started looking out for resources that could help me get me there. After a few online courses blogs and videos to get started, I began to shadow architects in my organization. This helped me understand their journey and their experiences in real time to connect the dots. As I continue my journey in pursuit of my dream job, I wanted to share my naive views on what it means to be an architect and what are few critical elements that software architecture depends on. Simon Brown in an article quoted: “Software architecture is all about having a holistic view and seeing the bigger picture to understand how the software system works as a whole” (Brown, 2009). 

(![Software Architecture](https://thepracticaldev.s3.amazonaws.com/i/fn0u51dotwh4ok2f0du4.png))

A very well designed software application is the result of an efficient design or architecture that is truly abstract and scalable to the growing needs of the business. Software applications today are not only built to last long, but are also built to change. In an agile organization, like ours, it is also very critical for applications to dynamically shift direction based on the customer feedback and be ready to build and deploy frequently. In responding to ever changing business needs and requirements, I have seen the architects work on architectural agility. They work with the stakeholders to maintain a steady and consistent focus on continuing architectural evolution in support of emerging features.

Structure always comes into mind when we think about architecture. Although the structure along with its relationship, also known as its behavior is an integral part of any application. An architect analyzes the business problem and breaks it into individual components and their relationship with each other. Architects typically focus on elements with more economic significance and those that have a long lasting effect. As the new business requirements arise, architects evaluate the cost to create vs cost to buy and work with stakeholders to get the approval as needed. These are very critical decisions that help the companies to be market ready and get ahead of their competitors to gain a wider footprint in the market. In my opinion, an architect is not only a technical leader but is also a master collaborator for designing the optimal applications that are supported by all the stakeholders of the organization.

Architects need to have a strategic view of where the business is going and how technology can be used to attain that vision. They negotiate effectively with the stakeholders to ensure that the quality is not sacrificed in order to meet the demands of the business. It is a known fact that a product with low quality, in the long run, is very expensive with many bugs and customer issues. Conflict resolution is a critical trait that every architect must possess to negotiate effectively. I have seen the architect resolve issues between development and product teams when they disagree on the priority of the technical debt over a new feature. They negotiate by comparing the cost of maintaining the tech debt over the benefit of implementing the feature. At times, if there are several stakeholders with competing priorities, architect may have to step in to bring them to an alignment and influence the decision.

Meaningful architecture is a living, vibrant process of deliberation, design, & decision, not just documentation. (Booch, 2016).
Architectural Style is greatly influenced by the systems and represents the experience which can be reused. Architects analyze the needs of the business and identify the patterns that were used to solve a similar problem. An architect must be experienced enough to identify the right pattern or a combination suitable for solving their specific needs. They need to identify the areas or bottlenecks that are slowing down the organization to quickly release features and propose effective solutions. Strong design experience and technical knowledge combined with analytical and 'joined-up' thinking is crucial for making such design decisions. 

Architecture is influenced by the environment and the culture of the organization. Each environment has some pre-determined boundaries within which the system must operate. Architects must be aware of these boundaries and make decisions accordingly. Additionally, they also must be aware of the internal and external technical constraints that will influence the decisions made. For example: The applications in healthcare environment, like ours, must meet the federal and state regulatory standards. Failure to do so may end up in hefty fines and penalties to the organization. The rationale used to make the specific decisions should always be documented well by the architects to help the stakeholders to maintain the applications.

I believe, the big difference between an experienced developer and an architect lies in the area they focus on. A developer usually focuses on implementation details of a single line of business. On the other hand a software architect will need to have pragmatic vision of the business at a broader level and how each line of business is connected to each other. Software Architect is a technical leader and master collaborator and drives initiatives with a holistic view of the business goals. They will influence successful outcomes in an organization with vision, strong leadership and effective planning while collaborating with the technical team and contributing to the optimal solution. The journey has begun...

Works Cited
Booch, G. (2016). Quotes. Retrieved from http://handbookofsoftwarearchitecture.com: http://handbookofsoftwarearchitecture.com/?page_id=70

Brown, S. (2009, February 9). Are You a Software Architect? Retrieved from https://www.infoq.com: https://www.infoq.com/articles/brown-are-you-a-software-architect