When does a project not require an application architect?

Question

Do moderate or large projects ever not require an architect? I have worked on a number of projects where the development company involved has choosen not to assign an application architect. Either the software is built organically and with little concern for design or the design responsibility falls to senior developers.

The motivations for not having an architect range from cost considerations to believing that the development methodology makes the architectural role unnecessary (this argument could be made for agile development). Some open source projects work on the principle of collective contribution rather than development with architectural leadership.

Answer 1

I'm going to have to use an analogy here utilizing houses. Not too long ago (relatively) people could build houses without an architect or architected plans. They cut down some wood, used learned skills to cut and plane boards and built their houses. Cathedrals, castles, etc....they had architects and engineers, sure. But the vast majority of the time it was people using skills passed down to build a house.

These houses did the job but didn't last as long. They might be a bit leaky, they might be hard to improve, etc. But it's easy to use water to level your foundation and then add wood.

Modern day houses have infrastructure to plug into, codes that have to be met, etc. We need our housing designs created or approved by an architect before they can be built. The architect makes sure everything's up to snuff and that the house will stand and be habitable.

---

Applications are no different. We are not living in a world where complex structures can get away without being architected. Sure I can write a database for my library as a trivial exercise; I can also build bookshelves for my library without getting an architect involved. But once you get beyond simple structures, you should absolutely make sure somebody is paying attention to the bigger picture -- whether your structure (house or application) is going to do what it needs to do, whether it plays nice with others, and whether it meets the rules set upon its construction.

Answer 2

If you already have an architecture/system pattern that will allow you to build your project, you won't need an architect at all.

I teach Software Architecture at university, and the central skill we believe architects bring to the table is a systematic, thorough design process that satisfies the needs of all stakeholders with careful considerations for competing interests. There's a bunch of technical knowledge that architects must have, but it's not uncommon for developers to have the same knowledge (and even more).

The key thing is capturing quality scenarios and knowing how to apply design techniques/patterns that meet these qualities. Or inventing something on the fly if you have to.

Architectural reuse in the industry is high, often to the point that an architect is redundant.

Since I talk alot about this stuff, I could really go on and on and on...

UPDATE: I'd thought I'd collate some of the thoughts expressed in other answers.

• Architects are a central communication point.
• Architects communicate the design - good ones do it efficiently.
• Architects bring essential experience to the product/project.
• Bigger constructions need bigger designs, more planning, prototyping, etc and need someone to ensure "the right system is built right".
• In contrast to developers, architects consider developers to be stakeholders and implement tactics for dealing with their desired non-runtime qualities (scalability, maintainability, testability, reusability, configurability (MeTRiCS)).

Answer 3

Define "Require."

You can most certainly build a large product without a central vision or leadership. It will just take longer, have more bugs, be harder to maintain, and require more man hours to complete.

The advantages of having a Application Architect, in my experience vastly outnumber and outweigh the disadvantages, and the larger the project, the larger the effect.

Now there are things you can do to mitigate the effect, such has having strong and complete documentation regarding the intended design of the application, which are followed faithfully by the developers- but that's just having a document take the place of the Application Architect, it's not really a different approach.

Agile Development can be successful, but it's success is on having a well oiled machine of a development team, each of whom agree on the basic concepts of the program design and are comfortable enough to point out to each other when they have made poor decisions and correct each others mistakes.

Again, you're not really replacing the role of application architect, you're just spreading out the responsibilities to a group of people.

The simple fact is, that role [i]is[/i] something you're going to want to have seated. How you seat it is up to you, but the most proven, most effective method is to have a person do it.

Answer 4

In the place where I work, we have architects for a large project. The architects are if you like 'the voice of sanity' and bridge the gap between a business analyst style role ('This is what we believe the industry requires') and the senior developers ('this is how it can work'). They provide a consistent view of how the software should develop - the bigger picture, if you like.

Developers move around - especially the good ones - and getting consistency on a project is key, in my opinion. The architects specialise on an area of the project (large project, remember) and don't move around, so they develop a great understanding of what is to be achieved and how we should get there.

They also provide a 'smoothing curve' to the flip-flop situations you get with the changing business needs and the natural resistance of developers to change already baked processes.

Even open-source projects have what I'd call an architect - the central people in the project usually have a vision of what is being built and how it should be. The collaborators are providing ideas and pushing boundaries, but there is someone who vetoes a change if it doesn't fit.

Answer 5

It depends what you mean by "architect." If you mean what CVertex means, then indeed, that is correct. If you mean "a fat* person who doesn't code but likes UML a lot, and kisses management behind" then the main risk is that the project will work and not be supported by management, rather than the other way around.

* In my experience a lot of these no-code people have even more excess weight than I do. I see plenty of skinny programmers, though.

Answer 6

When there's only minor maintenance involved that doesn't require any architectural reworking or analysis.

Answer 7

My experience is that sometimes the architect just isn't called that. There is usually someone, or some group, who is responsible for the overall design of the code. I've had this be a technical lead, a team lead, or a project lead. It also tends to be a developer who has the added responsibility of guiding the large scale design. Perhaps I just have worked in smaller development shops, but I've never seen a point to having someone who solely does architecture work, there just isn't enough to be done on any one project!