How do you plan for starting a new web system?

I've been creating more and more systems recently and I find more and more planning and preparation I do before starting the project.

I determine what libraries or frameworks I will be using, what languages, the basic architecture of how the site will flow, etc.

I've also heard of other design processes such as hanging styrofoam balls to 开发者_C百科show where classes are and how they relate, which is a process I've never heard of nor do I know how it works.

Is there any software that helps with this process? Are there any guidelines or steps or do you have a recommended set of steps or guidelines that you follow when designing a new project?

So you're bascially doing solution architecture. There aren't any methodologies that I am aware of - at least none that are succinctly described in four pages or less (something I'm interested in coming up with).

To answer your question:

1 - Understand the constraints

The obvious is understanding the problem you're trying to solve and the context.
You may have a free-hand or you might be constrainted by existing standards - where I work (in a Govt agencey) we have lots of different technologies and systems, and there's a pecking order when we're looking at something else; technology we prefer and technology we're trying to grow out of.

Zachman is an Enterprise Architecture Framework; you might find it interesting but I doubt it will have a lot of relevance at the solution level, specifically. TOGAF is another one.

2 - Views

The thing about TOGAF (and Zachman) is that it has the concept of different "views", for example the:

• security view
• data view
• technology view
• application view
• process view
• support view
• operational view
• billing view
• user view
• performance, etc...

Right up front you want to be thinking carefully about which views are relevant to the system you're planning / architecting. As the project / system develops you need to keep these in mind; they will help guide major decisions. I also like this appoarch / way of thinking because it works along the lines of "divide an conquer" - break a large puzzel into smaller ones.

3 - Modelling

I haven't heard of using styrofoam balls before, but the idea of modelling relationships in a tactile way sounds very appealing - although if it's a big system you might need a really big room :)

Whiteboard are my favorite way of exploring how classes relate (and anything, really). I strongly advise having a digital camera with you, or a phone with a camera built in; I use the latter, I take photos of the whiteboard as needed and then sync them with my computer after the meeting and email out copies to the attendees. It's very easy to capture the information and makes you look quite professional as well.

UML is very useful, but you may need to pick and choose which bits of it you use depending on your audience - it depends how formally you want to look at things.

Formally modeling systems in a modelling tool (and using formal UML, as opposed to just diagramming, in say Visio) is alse very useful. If you're not familiar with doing this you'll find there is a pain threshold you have to go through but it's generally worth it when:

• the system is above a certain size / complexity, or
• you have many smaller systems to work with.

4 - Project methodology

I'm a big fan of agile / SCRUM. I'm looking at ways of appliying agile principles to sln architecture - but I don't have anything yet.

I attended a good session at Tech-Ed last year (ARC202 Challenging the role of the architect with Kevin Francis) - I have a write up here.

This was an excellent session - it's the first time I've ever seen anyone explain how an (solution?) architect should engage in a project - regardless of the methodology. Kevins an Agile advocate - and his talk focused on that, which made it twice as good: how to fit Architecture and Agile.

Some folks like Kanban.

Others find UML to be useful.

Architecture wonks use the Zachmann Framework.

I think most folks use a combination of these techniques. It's important to be flexible- each project is different. Keep sharpening your management skills and processes and you'll find a workflow that works best for the majority of your projects.