Agile Software Buildings
Software buildings need to be like real buildings in many ways, they need to be functional, robust, be aesthetic and principally meet the people needs. Architects are the people who create the buildings foundation, as a concept, as a metaphor, to understand what is going to be created. To reach all the requirements, a high level of abstraction and detail is needed, but unlike Building Architects, Software Architects shouldn’t work alone, despite all the complexity of their work they can be Agile, following a set of good practices, principles and working together with their people as a team. This article describes how Software Architects can use Agile techniques to make better Software Buildings.
In the World exists almost infinite ways to build ideas, for every need exists an idea which can become reality. People have needs and make their ideas reality, but they need a way to express them, that is what we call abstraction; they also need to follow a process to concrete those ideas, in informatics we can call that process as Software Development; it involves many techniques, methodologies, etc.
As the needs grew, the technology evolved, and the ideas and processes became more complex; a wide variety of platforms, operative systems and software applications emerged, it was necessary that the Software Development covers all those new products; that was when the Software Architecture born. Software Architects have a wide experience on many platforms, they have the skills to abstract ideas, express them into a coherent language, separate the components, know the tools, predict and adapt the product over the time and the needs with multiple views of the reality; in other words they model the Software Building.
Software Architects’ nature is constant researching for new technology and how to apply it to existent or new products, they were developers but at that level they could disconnect from their team, in projects with Waterfall like methodologies, Software Architects tend to be apart from the team and sometimes they are seen as a high level informatics and their documents just can be available for certain people and the rest of the team must accept the plan even if they don’t like it. This would affect the team relationship and the project’s wealth too; the design made by one person could become as its “Master creation” and nobody could object it, those designs are Ivory Towers1. Another problem is the detailed documentation which could include irrelevant topics and wrong predictive design.
With the Agile Methodologies arriving, some practices could be applied to the Architectural view, many of them related to people communication and team work, becoming the Architect from a “Software God” to a part of the team. The time and processes could take less, modeling using the Agile Model Driven Development2 approach and the JIT (Just-In-Time) 3style.
This paper is based on the article “Agile Architecture: Strategies for Scaling Agile Development”4 written by Scott Ambler and on the Agile Architect Web site5.
Agile Methodologies are based on four principles:
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
They mean: team work, results over loss of time, clients participation and adaptability. All those principles are a good idea, but the Architect must be wise enough to balance the stakeholders’ needs and the dynamical processes taking care of the macro vision of the product specially talking about future and prediction. That’s why and Agile Architect has their own principles which adapt its work to the Agile environment.
They are separated in “Objectives” and “Principles”. The first ones detail “what are you trying to achieve” and the second ones “how to get there”.
Deliver working solutions.
Maximize stakeholder value.
Find solutions which met the goals of all stakeholders.
Enable the next effort.
Manage change and complexity.
Objectives are what we want for the project, which means we need working software every time, look at what are the client priorities and do that first.
Try to adapt the product to client needs, and be ready for the next step which means predict all changes in a short term. Change and complexity are the everyday for an Architect it must to know how to deal with them choosing the best solution.
Value people.
Communicate!
Less is more.
Embrace change: Plan it, manage it!
Choose the right solution for the Enterprise.
Deliver quality.
Model and Document in an Agile Fashion.
The principles are Golden Rules, a Sacred Code for an Agile Architect to assure its participation as one of the team and the quality of its work.
The Architect must value the people working around it as persons, they are not machines or objects, they have feelings and problems they need guide and they can guide too, they need motivation and the can be motivating too, everyone deserve respect.
The Architect needs to communicate with people, they can be skateholders, developers, managers; not all of them talk the same language and not all of them have similar tasks; they need to understand what the Architect is doing, have a rapid response, give and receive good feedback or comments.
Less is more, simplifying complexity saves time and effort, doing just the necessary documentation, clarifying it will result in a better understanding of the people working around. If something accomplishes its purpose it can be deprecated.
Embracing the change means there is no reason to not think on the future or wait for some power word to start thinking on it. Besides, every future change has a cost and an impact; they should be managed thinking on the stakeholders values and time. Changes should be managed in a controlled way too, alerting to all the willing people, explaining the reasons and costs.
Always try to choose the right solution for the enterprise, knowing the people involved is the right way to take decisions, also not all decisions are the expected by the stakeholders but they are what they need for their business. Negotiating is always a good option.
Planning and designing for testing assures delivering a product with quality, testing ideas, adapting ideas to the process, and delivers software frequently.
Using tools, papers, boards, and the agile modeling practices6, completes the Agile Architect paragon:
Model with a purpose.
Multiple models.
Know your models.
Know your tools.
Apply the right artifacts.
Model in small increments.
Model with others.
Use the simplest tools.
Apply modeling standards.
Discard temporary models.
Constructing Software Buildings is hard; it needs wide criteria to measure how much documentation create, what is valuable for stakeholders, what is better for the Enterprise, balance costs with development risks and changes, have a lot of experience and people knowledge.
Software Architects can choose many development styles but with Agile there are not recipes just good advices, willpower and the Ivory towers problem could be avoided.
3 William G. Griswold (1996) – Just-In-Time Architecture: Planning Software in an Uncertain World.