The role of the software architect (part 1)

The role of the software architect (part 1)

hi I'm Simon Brown a senior consultant with c5 Alliance I like to describe myself as a hands-on software architect and this presentation is about the role of a hands-on software architects 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 a project to success so why do software projects fail them well software projects can fail for a number of reasons for example there might be over budget they might exceed the time allocated in the team or they might not meet the end-users expectations each ative and agile techniques can help solve some of these problems so for example by reducing the time between the reclines being defined and captured and signed off through to the delivery of that piece of software you're more likely to meet the end-users expectations because they've been much more involved in 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 in the budget and the time much much easier to so then each div 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 front 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 other project might be poor it might break often it might not be reliable might not be available and so on so again there are a whole bunch of other reasons why software projects fail and while that job can't solve those something needs to on the one side then we we now understand that software projects fail and like that that they can fail for a number of different reasons the other piece to our puzzle is that software artists and have a bad reputation in the industry and this bad reputation usually stems from limited involvement in software projects and that limited involvement can ultimately lead to projects failing so let's drill into this some more the first item we have hears is that large organizations particularly tend to have a centralized architecture team and these are the people that they generally hiring they had hunts and so on and they bring them in they put them in an office elevate them on a pencil and these are the ivory tower architects the thinkers and these people have a greater experience and knowledge to to share with other people and they're generally parachuted into project teams when those projects are starting up or 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 and they can do this because they don't necessarily understand the business context in which those project teams are operating in and also those centralized architecture teams tend to keep an eye on new technologies advances in design patterns and those sorts of things and 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 architect in for the first few weeks the project's only now okay this is when most of the requirements capture and the big the high-level design and the architecture is typically done but these project teams then release their architects after all that work is done and once this is effective at getting those big decisions made early it's not effective when during the construction phase or in the build phase your software development team need to ask the architect questions so for example they don't understand a design plan 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 the guidance that they need and 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 soft racket and instead they'll just try and hire the smartest developers that they can lay their 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 code together use the latest technology use elite programming and language features and so on but that 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 also used the latest technology the best design pans there's structure beautifully but ultimately it doesn't deliver on the non requirements the system doesn't scale it doesn't perform it doesn't handle the volume of data that is supposed to so again sometimes you really do need an architect to make sure that some of these bigger picture things are taken care of and having smart develop this is great but who's going to look out for after those architectural things you

18 thoughts on “The role of the software architect (part 1)

  1. Why insist on being called architects? Why can't you call yourselves Computer Scientists, Information Technologists, Information Scientists or Computer Engineers instead of being QUACK architects? Those titles fully fit your degrees and career. You may even fully professionalise your degrees by having licensing examinations just like real architects and real engineers. Are you ashamed of your degrees and are you afraid of licensing exams?

  2. This video does NOTHING to define and clarify the role of a software architect. The presenter rambles on about why software projects fail…agile…blah blah. Try explaining it in terms my mother would understand.

  3. @IIoWoII I know everything about them. They are just plain tradesmen who are hungry for professional titles. But the truth is, they are nothing but plain COMPUTER JERKS or QUACK ARCHITECTS. LOL!

  4. @AcquiredCardSkills neither.
    You coach a team of software developpers(people who write the code). You drive them in the right direction. So you make decisions on how the structure will look like based on the requirements the investors and the customers impose. You guide the development in the right direction in the same way a normal architect makes the plans and gives directions to the engineers and workers for the construction of a building.

  5. @IIoWoII alright, alright! If you computer jerks really wanna be called Architects, I suggest you use the title QUACK ARCHITECTS.

  6. @ragan2nik Software Architects are nothing but SAD AND PATHETIC BUILDING ARCHITECT wannabes who didn't make it to Architecture school! LOL!

  7. hello. what course i'll need to take to become a software architect? is it IT course or architecture?? thanks

Leave a Reply

Your email address will not be published. Required fields are marked *