Software architecture in an agile environment

Editor's Notes

• #3: Today we will talk about Software Architecture and Agile. But do you have already a definition for Software Architecture and Agile? Do you exactly know what a Software Architect should do and what is Agile?The webinar is divided into three different topics. In the first part we will have a short introduction to Software architecture and Agile development. Then we will have a look at the Software Architect role and finally we will see the Agile Architecture methodology. Next slide
• #4: Introduction. First of all let’s start with some terminology and explanations. What is Software Architecture? What is Agile Developments? And finally, let’s see how can we keep together Agile and Software Architectures. Next slide
• #5:  Next slide
• #6: Definition of Software ArchitectureSoftware Architecture is a terminology introduced some years ago in the software development community, which identifies a specific science or art of designing and delivery value. So the target of Software Architecture is to design and delivering value. Very important concept. If your architecture is not delivering value you should be concerned about it because it is a useless cost for the company.But what does it mean delivering value? Next slide
• #7: Software architecture is?Software architecture is a group of methods, techniques, documents, approaches, you name it … used to deliver and document software.A software architecture, generally is in place to help us delivering the following items: Business models, Engineering design, choose the right frameworks and platforms, bridge the gap between the IT and the business.  Next slide
• #8: Introduction. First of all let’s start with some terminology and explanations. What is Software Architecture? What is Agile Developments? And finally, let’s see how can we keep together Agile and Software Architectures. Next slide
• #9: Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.Agile Next slide
• #10: If we talk about Agile I am sure everyone of you has already heard about: continuous integration, unit testing, continuous delivering, flexibility to change, sprint and features.Agile is a set of methodologies, each one focused on a specific aspect of the development process.For example, we may adopt XP if we need to improve productivityWe may adopt SCRUM if we need some additional information about the team and the process and we want a light process to handle the development.We may have Kanban if the Team is 100% interchangeable, we may adopt TDD because we want to increase the quality of the code delivered.
• #11: In this slide we have a simple representation of SCRUM, one of the available methodologies offered by agile.The main characteristic of SCRUM is to break the development into small tasks, with minimal planning without requiring long planning tasks. It is composed by iterations where the team work all together to deliver one or more feature. There is no architectural view of the project because the team is always focused only on the feature they are delivering, for this reason the role of a software architect is tricky inside a team that is adopting agile.In the same time every member of team has the same decisional impact of any other member of the team and this can grant more freedom to the ego of every single developer, which is an important factor.So, how do we solve this problem?How do we keep together software architectures and agile? Next slide
• #12:  Next slide
• #13: In this simple equation we have on one side the agile methodologies and MDD development.On the other side we have AMDD, the agile architecture.With MDD (Model Driven Development) the team and especially the architects are forced to design the entire or a good portion of the business model upfront. This is the classic technique. Unfortunately with this approach we can’t be iterative like we are with Agile where we have plan/development/release iterations.AMDD (Agile Model Driven Development) is an agile technique that differs a little bit from the standard MDD Model Driven Development.With AMDD we create agile models that are just barely good enough to drive the development. This is a further step of the agile adoption, where in a first phase the team is focused solely to deliver features and fix bugs and it does not have an architectural overview of the project.
• #14: Let’s see how a software architect can live inside an Agile team and how it is really important to keep this role even if we are inside an Agile team, in order to provide a continuous overview and right documentation of the product we are delivering. The software architect is an ambitious role but even controversial because it has always been defined with a wide large definition that doesn’t always represents the correct role. Now we have some institutes and organizations like Microsoft and IASA that are trying to give a better definition for this role but there are still controversial decisions between the various organizations.
• #16: The software architect is the member of the team able to create an architectural design from a vision of a stakeholder. It does not mean that from the vision the software architect must create the entire architecture but he is able to translate the vision into something more understandable by the IT.He should be able to look at current and future requirements in order to drive the team and the costs into the right direction from the beginning.He should be able to take technical decisions that will drive the development such as: the right framework, the right OS, the right tools. This decisions should be made from his experience and his knowledge of the team.This is the strict description adopted by the architect organizations. Now let’s see how we can modify this role to fit into Agile. Next slide
• #18: Inside an Agile environment the Software Architect should be able to:Provide information about Frameworks and Platforms by sharing his knowhow with the teamProvide architectural knowledge during the modeling phase of each iterationInteracts with the business because the Software Architect represents the bridge between the business and the ITBe modest enough to contribute to development and delivering because in Agile every single member of the team should be flexible enough to cover multiple roles, from the developer role to the architect role, without regretting the database developer role either…So, based on my personal experience inside an Agile team, I draw few golden rule that every agile architect should follow Next slide
• #19: Let’s see how a software architect can live inside an Agile team and how it is really important to keep this role even with Agile, in order to provide a continuous overview and right documentation of the product we are delivering. The software architect is an ambitious role but even controversial because it has always been defined with a wide large definition that doesn’t always represents the correct role. Inside an Agile team a good software architect should be flexible enough to keep his role of architect and be also a good developer and tester in order to be a good and exchangeable key of the team.
• #20: In order to be a good Agile Architect you should follow these golden rules:A Software Architect doesn’t have anything special, it is part of the teamIn Agile, every member of the team is an active part and so should be the Architect, an active part of a teamAvoid Avory tower built during the design time following the MDD (Model Driven Development) methodology. It doesn’t involve the developers so the team, it doesn’t fit the collaborative approach adopted by AgileA strict Software Architect will fit better in a big team/project because there will be more space for his ego than in a small team where every member should be able to do everything. Inside a small team the software architect role should be cover by the entire team.
• #21: We are now at the final section of this webinar where we will have a look at the agile architecture methodology and how it works. Next slide
• #22: How does it works?
• #23: This methodology has been presented the first time in 2008 by JD Maier; he recently joined the Microsoft Enterprise Strategy team.The methodology is described with the following workflow:First we identify the objectives. How? You know what will it be the outcome, right? Here you should build a prototype, share the models over the team and discuss potential paths and risksSecond, we need to identify the key scenarios. We need to identify the architecturally significant use cases, but how do we know that a use case is architecturally significant and how can we avoid the Avory Tower? They are use cases important for acceptance of the deliverableWith the application overview, we can start to provide a general overview of the application. [show slide 31]Then we need to analyze the key hotspots, we need to use the quality attributes to identify the right hotsposts. But what are quality attributes? [show slide 32]Now you can create the candidate solution, the candidate architecture and discuss it against constraint and environmentThis workflow is iterative, so you will not define these requirements all at the beginning by through an iterative process. How? Let’s have a look at the next slide.
• #24: This slide represents the AMDD (Agile Model Driven Development).We have an initial iteration that we will call iteration 0 where we envision the requirements and estimate the potential risks and decide the architectural style and the frameworks, environments we will use. This step is really important because from here we will drive the team and the development through a specific path. This iteration, depending on the type of project, will take some days in order to allow the team to identify the high level requirements. You may provide some mocks of the UI and some mocks of the business model in order to have further to discuss.Then we have n iterations composed by three parts:Modeling. The model should give enough information to provide an estimation and to plan the work for the iteration. The scope of this part is solely to provide a good estimate for the current iteration, so the model shouldn’t go further than what expected by the current iteration. Remember that you can always go back and refactor the model!In this part few members of team meet together for a short period of time and discuss the model obtained so far. In XP this is called stand-up design sessionTDD first absolutely perfect into this process because after you have modeled your software you need to implement the model in the code. Using the TDD approach each part of the model required by the iteration will be implemented using the TDD approach, to improve the quality of the code constantly during the developmentAt the end you will come up with a double outcome. On one side the team has a full understanding of the architecture and knows exactly what to deliver for every iteration. Plus, you have been able to keep alive your software architecture process and the second outcome will be a well documented architecture flexible enough for an iterative development process.
• #25: Now let’s briefly see how it is structured a team inside Agile Architecture
• #26: Let’s take two different cases. Large and small team.In a large team you need some management and you need an architecture owner, which is usually the Software Architect.Usually when the team is large and there is more than an architecture owner, each of this owner is the team lead of the sub-development team. In this way the knowhow of the architecture is properly distributed across the entire structure.If the team is small, I found really helpful to distribute the knowledge of the architecture and the role of the software architect across the entire team following a more practical Agile approach. Next slide
• #27: Now let’s have a look at an agile architecture
• #33: First we determine the application typeUnderstand the deployment constraints such as the environmentIdentify the architectural style and keep it over the entire application. Domain Driven? SOA?Identify the relevant technologies that you will use in your architecture (WPF, SQL Server?)
• #34: These is just a short list of the quality attributes you may use in your architectureto identify the key hot spots.