Introduction
The agile methodologies are getting widely accepted all over the world. However, there is still a lot of discussion and debate on how to apply those methodologies to the architectural space. Most conflicting issues arise between the ‘big design upfront – an approach that is strongly discouraged by the agile approach practitioners and the traditional approach to architectural design. In this post you will read on how you can achieve technical excellence, streamlined development practices, and a constant and ever-increasing flow of business by integrating the agile approach in to your software architecture. This can be achieved with a set of team dynamics, conceptual practices, and specific technologies that are proposed herein.
Architectural dynamic utilized in Agile teams
One of the 12 principles of the Agile Manifesto states that “the best architectures, requirements, and designs
emerge from self-organizing teams.” This is something that is considered as a foundation here, especially with regard to the shared specialization.
The architecture is an activity that is historically performed with emphasis on the early stages of a project. The agile development on the other hand, lays its focus on emergent design and iterative production. Thereby, it creates a series of interesting challenges down the road.
The basic characteristic of the agile approach is that it believes in shared responsibility. Unlike the traditional approach wherein a software architect was considered wholly responsible for creating the software architecture and higher-level design, in case of the agile approach this responsibility of the software architect is diluted. In this approach, the software architecture is developed by the whole team. Hence, it helps in preserving its multi disciplinary nature. Now, that doesn’t mean the role of software architect is no longer considered important. It goes without saying that the software architect will still remain the person who will conceptualize the idea of the software architecture however, he will explain the design to the team members and they all will contribute in its development. The benefit here is that the entire team participates in understanding the implications of the design and continuously evaluates them.
It is a fact that key considerations such as the modularity strategy, how communication is handled within and outside the application, and how data and services are accessed and abstracted are better analyzed when a team sits and discusses about them rather than an individual handling them all simultaneously. In this way, the team members contribute their suggestions, their fears and concerns. Hence, the probability of failure is reduced to a great extent.
These challenges are usually tackled by holding regular meeting of the team members for architectural discussion and revision. These review and design meetings comprise a lot of white boarding and open talk. Also, it helps to have the most important guidelines permanently exposed in the meeting area. These could include diagrams, checklists or reference charts around the walls, and semi-permanent flip charts that can be used as posters.
Patterns and practices followed in Agile architecture
The big design approach leaves us with several inconveniences. To avoid this one of the most common approach suggested it “sashimi” approach. Here separate design for each part is not developed instead, small codes are developed with the intent to connect all the pieces and then the main functionality is constructed. This will give you the same end to end set up that you wanted. The objective is to do away with complexities of big building architectural components. Since there are repetitions of some of the processes become unnecessarily big and unmanageable.
However one challenge that is faced with to replace this support system with architectural pieces is to define a decoupled API. At the outset developing the API becomes the most critical thing to do. For similar reasons it is advised to star with absolutely no implementation. Even if you use a third party component it is advised that you follow a similar practice.
Architectural Pattern
Concentric approach has also emerged as a most common approach for agile development of software for architecture. The first step is to analyze and develop technical vision of the desired solution. This technical vision enables you not only to compare your own progress but also to guide you as to what your subsequent action should be. Thus it is important to establish a logical continuity in your entire planning. The second step would be to decompose the entire step into as many small manageable steps as possible. This not only makes the job easier in terms of division of responsibility but also to check progress and to check whether the person to whom the responsibility was given has lived up to it or not. This also helps in adding up new functionality if needed. This helps us do away with the requirement of having to redo the entire program all over again.
The next step is to describe each such decomposition in terms of architectural styles. This helps us make this decomposition more understandable to people who are not directly linked with the project. The trickiest part is to define the layers. The layers have to be so defined that they represent the decomposed components of the project. If they are clearly defined then it becomes easier for the person to whom the responsibility is entrusted to understand and execute the work better. This also makes it easier to distribute the work among teams so that development of each part can be closely monitored and handled. This also helps understand which a particular component is lagging.
The next level is the packaging of the software to turn them into independent saleable software packages. This helps to turn them into independently recognizable software packages.
The next step is to finally develop the program languages and introduce the same to the stake holders.
However one should keep in their mind that all these different steps in the architecture can be undertaken in an independent basis as well. The latter would be in congruence with the needs and goals of the project!
Quality Attributes required in architecture
It is a common aspect in the world of architecture of what are the aspects which one should consider in a system design. There are several qualities and attributes which are essential. In perspective of agility one should keep in mind the attributes which must be managed in view of the backlog of the product. The implementation should be done on an incremental basis. In specific terms it means the management of a mix of needs, both the quality attribute requirements as well as features. Interestingly, the several qualities attribute lead to a trade off decisions and analysis where the usual prioritization might not prove to be enough!
The authors suggest that in order to manage quality attribute in an effective manner, one need to consider the latter as a goal whereas the requirements as a support system and user stories to the goal. It is important for the stories to have some normal acceptance criterion which re defined clearly. This is vital such that the tests that are implements can be neatly written out. For instance, some of the requirements are performance which need the resource usage and response time.
Validation of the architecture
The validation and testing of the architecture are the last stage of this section. From the authors point of view there are automated quality-attribute requirements testing, test-driven development, environment-configuration management, automated integration testing, and application-configuration management and automated deployment.
The authors are of the belief that interfaces should be defined as in the first section. Unit tests which can be executed should be used in the definitions. These specifications will have a dual role. Firstly they will safeguard for multi component and local refactoring and secondly they will be the point of entry for identifying defects in the reporting of the incident. The basic idea is that the implementation needs to be correct or changed in sync with the defect! However one should bear in mind that there are several changes in the architecture that will not be noticeable in unit tests!
In order to have a good management of the changes which should exceed the contracts of unit tests, one needs automated tests. The latter is a must for quality attributes and integration. While automated tests are difficult to create, their results are superior. These tests need to be such that they have a lower frequency which is a result of their resource usage.
Some of the examples include the following:
· Scalability: There is an acceptable amount of response time in the event of increase in system load. There is a planned capacity along with tool support which is a must for these tests. In this case both the server and client site needs to be kept in mind. The deployment also needs to be automated in the testing environment.
· Flexibility: The layers pattern needs to be instantiated. The tests need to be configured such that the acceptance needs to layer by layer, starting from the top layer only!
·
For the above to come true, one need to manage the configuration in two levels, one which is dependent on the environment and one is not. The automated deployment will be enabled in case of environment dependent configuration and focuses on the local and physical resource configuration! For the remaining configuration, there will be an issue that is the variability of the available functionality!
Technologies and techniques
It is vital to use the appropriate techniques and technologies in order to achieve the needed discipline through automation.
The agile world is one which has given more importance to human and their interactions rather than to tools and processes. in lieu of the above a helpful set of tools have been devised which make tedious and manual jobs away from individuals and make the execution frequent and fast. The latter is simple use to the constant feedback which is provided making it easier for human beings to act.
In order to attain the first level of technology, it usually includes frameworks and regular testing tools. Some of the unit testing tools includes xUnit to Cucumber apart from others. There are others like Selenium which is functional testing tools apart from several others which have a host of technologies needed for stress and performance testing. All of these run successfully on a built server as well individually at varying frequencies.
In a nutshell, while the basic development proactive is undertaken, it is supplemented with a specific unit test, stress level and acceptance to validate the architecture. There are style analysis, afferent and efferent coupling, cyclomatic complexity, code coverage statistics, lined of code per module and other such checks which were introduced in the second level. These tools are used in NDepend, StyleCop, FXCop, CheckStyle, JDepend, and Lattix among others. In the area of dynamic languages like Python, JavaScript and Ruby, there in an inherent problem in the implementation. However this should be filled up soon!
The third step is about metrics involving maintainability and flexibility regarding the project life cycle. In this arena, Visual Studio Team System has made immense progress.
It has been seen that a model needs to be in place for validation of a model of architecture. The important factor is for the automation of the process for the extraction of the required Meta data which is needed to validate the references, module composition and code. In addition, the distinguishing aspect of the module or code view of the system, starting from the runtime view in the evaluation period is vital! Lastly, learning about the performance of levels of reverse engineering is also done. The final step in the process involves the configuration and deployment in the varying staging
It is essential to have the project relevant and appropriate techniques in each fold and step of the main plan. The latter ensures that the controls are planted in the proper places with commencement of the project.
Conclusion
Symbyo Technologies strongly belief that the consideration of the architecture is the most fundamental aspect which creates value to the
software projects. Additionally, the agile teams have immense techniques, tools and mechanics which are on offering for the software architecture society. Interestingly, these contributions have been considered one of the best in its area. It provides immense benefits to the users and enhances one’s results and project value!
