How to go about Architecture ?

[Raghavan Ramji]

I am aspiring architect

I would like to know how does an architect go about designing the architecture for a system ? Given a detailed Functional requirement what are the steps needed to complete and validate the architecture ?

Is there any link available from where I can learn this in detail ?

Thank you

[Ilja Preuss]

Well, what is the purpose of the architecture? I'd say to support the implementation of a system, according to functional and non-functional requirements.

So the only way to really validate an architecture is to implement the requirements; the only way to see whether the architecture is a good architecture is to see how well it supports the implementation.

Consequently, I don't think the architecture can be *complete* before the implementation is complete. Trying to fully fix the architecure before implementation is complete means to cut off a very important feedback loop.

With other words, the architecture needs to be evolved in parallel with the implementation of features.

By the way, here is a quite thought provoking article by Martin Fowler on the topic: http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

[Raghavan Ramji]

Let me ask my question in different way...

How do we go about documenting the architecture ? ( what are the key things to be kept in mind, what is the basis for selecting a particular architecture, how do you make sure architecture document covers all the things that are needed ? ).....

Any links for these questions ?

[Ilja Preuss]

http://www.agilemodeling.com/essays/agileArchitecture.htm looks like it might address your question quite well.

[Nitin Gaur]

Well, you do not always "select" an architecture, as an architect you evaluate tools, technologies and various options while desinging new one.
IMHO, anyone in architect role usually need to perfom these tasks:
1.Drives technology evaluation and selection process.
2.Responsible for designing high-level architecture.
3.Keep track of Service-level requirements such as Performance, Scalability, Reliability, Maintainability and Security.
4.Has vision of reusability and defining application patterns and frameworks.
5.Able to present and justify technology decisions to a range of audience.

-Nitin Gaur
http://www.linkedin.com/in/nitingaur

[Peer Reynders]

Originally posted by Nitin Gaur:
...anyone in architect role usually need to perfom these tasks...

IBM developerWorks:
What is a software architecture?
Characteristics of a software architect
The process of software architecting
The benefits of software architecting
[ February 05, 2008: Message edited by: Peer Reynders ]

[Lasse Koskela]

Originally posted by Nitin Gaur:
Well, you do not always "select" an architecture, as an architect you evaluate tools, technologies and various options while desinging new one.
IMHO, anyone in architect role usually need to perfom these tasks:
1.Drives technology evaluation and selection process.
2.Responsible for designing high-level architecture.
3.Keep track of Service-level requirements such as Performance, Scalability, Reliability, Maintainability and Security.
4.Has vision of reusability and defining application patterns and frameworks.
5.Able to present and justify technology decisions to a range of audience.

I believe you forgot the most important one:
6.Implements his own designs as a member of a development team, guiding the evolution of the architecture during the project.

An architect who doesn't live with his decisions stops learning.

[Nitin Gaur]

6.Implements his own designs as a member of a development team, guiding the evolution of the architecture during the project.

This applies only when architect remain associated during entire project developement which is not true always.

[Peer Reynders]

Originally posted by Nitin Gaur:
This applies only when architect remain associated during entire project development which is not true always.

I think Lasse is alluding to the fact that you avoid many problems if the architect is part of the team. On the other hand separation between the architects and development teams tends to invite (possibly attracts) problems. So ultimately that separation should not be as acceptable as it has become in some organizations.

See: Enterprise Architects Join the Team (PDF)


From Agile Modeling: Agile Architecture

You should beware ivory tower architectures. An ivory tower architecture is one that is often developed by an architect or architectural team in relative isolation to the day-to-day development activities of your project team(s). The mighty architectural guru(s) go off and develop one or more models describing the architecture that the minions on your team is to build to for the architect(s) know best. Ivory tower architectures are often beautiful things, usually well-documented with lots of fancy diagrams and wonderful vision statements proclaiming them to be your salvation. In theory, which is typically what your architect(s) bases their work on, ivory tower architectures work perfectly. However, experience shows that ivory tower architectures suffer from significant problems. First, the �minion developers� are unlikely to accept the architecture because they had no say in its development. Second, ivory tower architectures are often unproven, ivory tower architects rarely dirty their hands writing code, and as a result are a significant risk to your project until you know they actually work through the concrete feedback provided by a technical prototype. Third, ivory tower architectures will be incomplete if the architects did nothing else other than model because you can never think through everything your system needs. Fourth, ivory tower architectures promote overbuilding of software because they typically reflect every feature ever required by any system that your architect(s) were ever involved with and not just the features that your system actually needs.

[Ilja Preuss]

See also http://simplewebs.com/?ArchitectsDontCode