*
The moose likes OO, Patterns, UML and Refactoring and the fly likes How to go about Architecture ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "How to go about Architecture ?" Watch "How to go about Architecture ?" New topic
Author

How to go about Architecture ?

Raghavan Ramji
Greenhorn

Joined: Jan 26, 2008
Posts: 18
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Raghavan Ramji
Greenhorn

Joined: Jan 26, 2008
Posts: 18
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
http://www.agilemodeling.com/essays/agileArchitecture.htm looks like it might address your question quite well.
Nitin Gaur
Greenhorn

Joined: Sep 06, 2003
Posts: 27
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


If you don't like something, change it. If you can't change it, change your attitude. Don't complain.
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
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
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Nitin Gaur
Greenhorn

Joined: Sep 06, 2003
Posts: 27
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
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
See also http://simplewebs.com/?ArchitectsDontCode
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How to go about Architecture ?