When does a project not require an application architect? [closed]

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

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 2

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 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.