Is Software architecture just a jargon....

World is not enough, the definition looks familiar to lot of people in this world. But once we go inside we really feel the fact of depth of this statement. 
Now, do we find that deepness while we define Software Architecture? Similarly, in software development, Software Architecture typifies a complex design artifact. Do we really need to dive in to find the exact answer. Yes we should;

What I have experienced is, people used to struggle alot to get the exact meaning of software architecture though they are really good Developers, Project Managers and Business Analysts. People who are experienced understand the meaning but who don’t will struggle for sure. At this point the software architecture is important for :

• Increases prognostication.
• Supremacy over the complex structure.
• Yield equilibrium and uniformity.
• Implement best practices.
• Re-usability.

Now, if you go through all the definitions given on Internet I cannot reach any final conclusion which again gives me a road block. What we gain from our learning experience is the most important part of understanding and the clear meaning of software architecture. As an IT professional you need to envisage how, why, when and what you want the application to do considering the Business Acumen. Basically you need a silhouette or outline of the system in context to what you are willing to design.

At this point of time we have functional and non functional requirements/constraints. The software architecture defines non functional requirements/constraints. And from the environment which is surrounding our system context you need to figure out the functional behavior of the system as well. Before we find out the solution, we normally jump into the discussion about OOP concepts, start learning Programming Languages and the Database. These are the prerequisites, but after understanding the architecture. And normally we are lost behind lots of questions; that is what we call an unbalanced knowledge discriminated in a software development scenario. In accordance to my experience I find the following heuristics which define Software Architecture or you can say which govern Software Architecture:

• Follow the rule of software world, “Divide and Conquer” for instance segregating the system to be built into discrete nuggets.
• Mechanism considering the techniques to create interfaces between these nuggets.
• Managing structure and the flow of the system to be built.
• Construction of the system to be built from the irrelevant environment.
• Proper utilization of development and delivery slants, techniques and tools.

Agility of Agile methodology:

Before we dive deep into the Agile methodology it’s good to know what Agility is and how it proves to be the efficient and effective way of doing a task. How it works or behaves? Agility is required to change anything which needs something new in regards to e.g. effectiveness, attractiveness and trendiness. In a sense Agility integrate with coordination and the power of the isolated movements. These movements are based on the balance of that integration process.

The main point here is “change” and the questions are “How to implement the change”, “What are the impacts of that change and how to deal with it”.

Agile methods were developed to cope with the inevitable changes that arise over the course of a software development project i.e. change in technology and requirements, resources or people assigned to the tasks are coming and going, etc. while still delivering a high quality product. Not only the methodology but a philosophy as described by Fowler which includes the different approaches such as XP (extreme programming), Scrum, Crystal Clear and FDD (feature driven development). Agile methods mainly emphasize on developing any software product by increments and the feedbacks from the stakeholders. And in a collaborative defined way the agile manifesto values:

• Individuals and interactions (over processes and tools).

• Working software (over comprehensive documentation).

• Customer collaboration (over contract negotiation).

• Responding to change (over following a plan).

 

This gives us a clear picture of what we are having on the name of processes, if required to be in a change environment. Now, if I need to figure out where is agility in this scenario of developing a software product it is certainly here when you start doing these tasks:
Estimation of effort, High priority and low severity taks, Functional and non functional requirements, Planning, Product backlog etc. by working on these tasks we are basically balancing the project requirements and work in progress for that.

The moment we enter the agile environment we will start focusing on values and the principles. Agile methodology, unlike the waterfall method, adapts to change rather than adhering to a plan pop up at the start of the development project. The mechanism which allows this versatility is iterative development, an ingrained practice of software development since long. Iterative development provides feedbacks from the stakeholders on regular intervals. On the basis of the given feedback, teams can determine whether the process or the product are still pertinent to the current level or situation and conform as necessary. And offcourse there is a balance in the "Client feedback and the development of the product".

Typical iteration, at the beginning of the iteration a set of requirements, or features, is selected and prioritized with the customer, after which the cross functional team discuss about implementing these requirements. The implementation work only lasts for the length of one iteration—from one week to one month—at the end of which the implemented product is evaluated, along with the process. The team assesses the accuracy of the work estimates created at the iteration planning and ask questions and the impact analysis. If, at the end of the iteration, there are still remaining features to be implemented, the next iteration is planned and carried out and repeated until the customer agrees that the required features have been implemented as a part of product backlog.

Finally, if we take an example of any organization where they have lots of products which are of very prone to be upgrade on timely basis in regards to their prices, any contests, and new features added and discount patterns and many more. There we need the agility of combining and stabilizing the previous features within a given timeframe with an accurate speed that integrate them with the given scenario.