Topics In Demand
Notification
New

No notification found.

239

0

Great things are done by a series of small things brought together - Vincent Van Gogh

A robust architecture modeling is not a complex one; but an evolving one supporting the changing needs of the system.

Agile Architecture: Strategies for Scaling Agile Development

[Image Source - Agile Architecture: Strategies for Scaling Agile Development Published by Ambysoft Inc.]

Normally, a common question comes while defining the architecture governance as to who is responsible and accountable for the architecture of a software product? The easiest answer to this question is the person in an architect role, preferably a tech architect having knowledge of the components, sub-components and the integrated solution. It may be correct to some extent in a utopian world; but in an ever-changing and unprecedented world where the customer needs, end-user expectations and market demands are dynamic in nature you will also need the involvement of all these tribes and the team which is going to implement it. It also raises another question whether an architect is not part of the implementation or the development team. The answer is “yes” and "no” as it all depends on the practices adopted in an organization - siloed (traditional) Vs. collaborative (agile) modeling keeping either the architect tribe in high esteem or having the humility to accept that they don't walk on water.

There are often some problems associated when the strategy about ownership and accountability of the architecture comes into picture. When the approach is collaborative in nature which is of course beneficial for incorporating the feedback from different groups while designing the architecture, but this can also fall apart when the team doesn’t reach the consensus. In several agile teams, they are looking for someone to play the role of an “architecture owner” or an “agile solution architect” who is often the most technically experienced person on the team and is responsible for facilitating the architectural modeling and evolution efforts. An architecture owner unlike the role of a traditional architect, collaboratively works with the team to develop the architecture. Effective architecture owners are, in fact, developers experienced in the technologies that your organization is working with and can work on architecture spikes to explore new strategies. They also have a good understanding of the business domain and have the necessary skills to communicate the architecture to developers and to other stakeholders. Not to get overwhelmed with the SAFe (Scaled Agile Framework) defined roles of Enterprise Architect, Solution Architect and System Architect and discuss them here, it is obvious that in designing an architecture, the primary objective should be to arrive at a mutual understanding or vision of how you are going to build your system. Then the question comes for the discussion is how should you model your architecture in a collaborative manner to arrive at a mutual understanding? Again, the objective here is not to discuss the structural or behavioral diagrams; but to assume simplicity and the depiction of the proposed architecture should be such that a normal developer or even a business user can also understand it.

The complexity of your architecture increases the likelihood that individual developers will not understand it, increasing the opportunity for errors and failures. Furthermore, your architectural model should contain the right level of information, showing how various aspects of your system work together but not necessarily the details. It is important that you should do some upfront architecture modeling and not “Big modeling up front” (BMUF) to decide your general technical strategy, identify potential technical challenges, and to help build a consensus within your team around the technical direction. A lot of details at this stage are not required, instead, they are identified on a just-in-time (JIT) basis during iterations via initial iteration modeling at the beginning of each iteration or by model storming throughout the iteration. The result is that the architecture emerges over time in increments, faster at first because of the greater need to set the foundation of an initiative, but still evolving over time to reflect the greater understanding and knowledge of the development team. Nevertheless, this does not obviate the need to develop working software via a test-first approach allowing producing automated unit tests for production code before you write/deploy it.

Certainly, the complexity of the architecture increases as you start onboarding the new technologies, different systems and how the new technologies will transition into the proposed system, which is faster, effective, more accurate, reliable, and sustainable. But identifying and prioritizing the typical use cases and building quick prototypes will help in validating the architecture. The architecture gets evolved incrementally and iteratively, allowing it to industrialize over time.

It is also pertinent to mention here that Lean software development also recommends that we should not immediately embark on the architecture strategy; but consider a few alternatives and keep them "open" until they are tried and tested. It is, therefore, important to envisage several possible architectures when you are drawing up architectural design as part of the initiative. At the same time, it is also very important to understand that the model is mere an abstraction until it is proved/validated with the help of implementation. The development of an architectural spike helps to reduce risk because you quickly discover whether your approach is feasible, and you get the opportunity to learn and adapt your architecture.

Hence, the agile practices adopted for modeling the architecture must be aligned with the Agile manifesto and principles to foster the culture of collective ownership and cross-functional collaboration.

References and Citation:

https://agilemodeling.com/essays/agileArchitecture.html


That the contents of third-party articles/blogs published here on the website, and the interpretation of all information in the article/blogs such as data, maps, numbers, opinions etc. displayed in the article/blogs and views or the opinions expressed within the content are solely of the author's; and do not reflect the opinions and beliefs of NASSCOM or its affiliates in any manner. NASSCOM does not take any liability w.r.t. content in any manner and will not be liable in any manner whatsoever for any kind of liability arising out of any act, error or omission. The contents of third-party article/blogs published, are provided solely as convenience; and the presence of these articles/blogs should not, under any circumstances, be considered as an endorsement of the contents by NASSCOM in any manner; and if you chose to access these articles/blogs , you do so at your own risk.


images
Gaurav Dhooper
Assistant Vice President, PMO

Strategic thinker, seasoned Project/Program management professional, Agile IT Delivery/ PMO Leader, author and a keynote speaker at various global platforms. Areas of interest include Digital Transformation & Strategy, establishing Strategic Partnerships and implementing Agile ways of working. An avid writer and has authored many articles on Digital Transformation, Agile Transformation, Agile Project Management, Scrum, Project Management Offices and Hybrid Project Management. Has been reviewer for PMI’s Standard for Earned Value Management, Standard for Program Management and a book on Agile Contracts. Holds the voluntary positions of President of PMO Global Alliance India Hub and Senior Official of IAPM for Noida. An active volunteer and member of PMI. Works with Genpact as Assistant Vice President, Business Risk Management PMO (Program Management Office).

© Copyright nasscom. All Rights Reserved.