Hi, I'm Simon Brown, a Senior Consultant with C5 Alliance. I like to describe myself as a hands-on software architect. This presentation is about the role of a hands-on software architect in successful projects. Throughout this presentation, we're going to be looking at exactly what being a hands-on software architect means, and how an architect can help drive for projects to success. So, why do software projects fail then? Well, software projects can fail for a number of reasons. For example, there might be over budget that might exceed the time allocated to the team, or they might not meet the end user's expectations. Iterative and agile techniques can help solve some of these problems. So, for example, by reducing the time between the recurrence being defined in capture and signed off through to the delivery of that piece of software, you're more likely to meet the end user's expectations because they've been much more involved in helping you produce that piece of software. Again, because you're doing this, you have a much greater transparency on the software being developed, and that means you can track the costs, and the budget, and time much much easier too. So then, iterative and agile techniques can help solve some of the problems typically associated with software projects failing, but they can't solve all of them. Software is quite complicated and it's quite abstract, and it's really easy for software to get things wrong like the non-functional requirements. So, you need to build a highly scalable website. You build a website that functions correctly but doesn't necessarily scale. Again, these things are quite easy to get wrong. In addition to that, the quality associated with the software product or the project might be poor. It might break often, it might not be reliable, it might not be available, and so on. So again, there are a whole bunch of other reasons why software projects fail. While agile can't solve those, something needs to. On the one side then, we now understand that software projects fail and that they can fail for a number of different reasons. The other piece to our puzzle is that software architects tend to have a bad reputation in the industry. This bad reputation usually stems from a limited involvement in software projects. That limited involvement can ultimately lead to projects failing. So, let's drill into this some more. The first item we have here is that large organizations particularly tend to have a centralized architecture team. These are the people that they generally hiring, they had tons and so on. They bring them in, they put them in an office, elevate them on a pedestal, and these are the ivory tower architects, the thinkers. These people have a great experience and knowledge to share with other people. They're generally parachuted into project teams when those projects are starting up to when those projects become trouble for some reason. Now, what these architects can bring lots of knowledge to those projects, they can also very easily steer them off track. They can do this because they don't necessarily understand business contexts in which those project teams are operating in. Also, those centralized architecture teams tend to keep on all new technologies advances in design pans and those sorts of things. They can bring that knowledge into the project team when sometimes they just don't need it, and again it takes them off track. The next item we have then is sometimes teams will understand that they need a software architect, and they'll get that software architects in for the first few weeks of the projects only. Now, okay. This is when most of the requirements capture and the bit the high level design and the architecture is typically done. But these project teams then release their architects after all that work is done. While this is effective at getting those big decisions made early, it's not effective when during the construction phase, during the build phase, Those software development team need to ask the architects questions. So, for example, they don't understand a design pattern, they don't understand why the architect has chosen a particular technology or implemented something in a certain way. So, once the architect leaves the project, there's nobody there to give the software development team a guidance that they need. Again, that limited involvement from the architect can actually cause a project to fail. One of the side effects of software architects having a bad reputation from their limited involvement, is that some teams will just think, ''Well, okay. We don't need a software architect.'' Instead, they'll just try and hire the smartest developers they like the hands-on. Now, this is great because hiring smart developers means you're going to get people who understand technology, who live and breathe it, who can put codes together, use the latest technology, use the latest programming language features, and so on. But those doesn't necessarily mean that the system is going to be successful as a whole. So, for example, I've seen some very very good software systems that have used the latest technology, the best design patterns, they're structured beautifully. But ultimately, doesn't deliver non-structural requirements. The system doesn't scale, it doesn't perform, it doesn't handle the volume of data that it's supposed to. So, again, sometimes you really do need and architect to make sure that some of these bigger picture things are taken care of, and that makes smart developers as great. But who is going to look after those architectural things?
