Short Answer:
They never intersect, as described, at a single "hail mary" point. They are different elements of the same process and should coexist together as part of that process. In the cases where one may be dependent on the other, the most ideal situation is that Information Architecture would guide the Software Architecture.
Long Answer:
When you start a new project, usually the software architecture starts its development and UX designer begins his.
First things first, this is hopefully not what happens when you start a project! A short list of things that should be happening when you start a new project (in an ideal world you can add a whole lot more):
- Product strategy
- Field research
- Face to face interviewing
- Requirements writing
In the very least, you should be defining a product strategy and defining your requirements. This should involve everyone: UX, software devs, management, marketing, other stakeholders.
If we just take a situations where just a product strategy and requirements definitions are done, what you end up with a clear roadmap for both the Information Architecture and Software Architecture efforts. It is not a question of "when do we intersect so we know we're going to sync up", it is "we both started knowing exactly where we are going, so we're going to sync up".
But that's a pretty simplified process. When you develop your application with user centered design in mind there is a much greater process that makes sure that you match the needs, wants, and limitations of end users at each stage of the design process.
When you look into different illustrations of UCD you will see many variations, but all getting at the same point. Here is one simple example:
... which I will oversimplify when I point out the following:
Strategy is where your product strategy is defined (among other things).
Analysis is where your field research, face-to-face interview, and requirements are all completed (among other things).
Design is where interaction design, information architecture, with low- and medium-fidelity prototypes are all done.
Software can begin architecture at this point too, because they have clear direction via the Strategy and Analysis stages. Being sure to include the software architects in the IA process helps them to understand how the system will be experienced by the user, so they can begin to scope their process accordingly.
Development is where high-fidelity prototypes are done, with full on software architecture and to the point where you are ready to release.
At no point did we send people off to do their own thing and hope they intersect at just the right moment. You've reached the end with everyone knowing full well were the others have been, where they are, and where they are going.
But, what if your UX and software teams have gone off and started doing their own thing -- despite your best effort. Well, hopefully you're developing under a Model-View-Controller architecture. There are several variations on the theme, but they all basically break down to the same notion: separation of the model (aka: data, vis-à-vis software architecture) and the view (aka: the navigation and flow of the user interface, vis-à-vis information architecture).
If UX comes back and wants a certain design, flow or interaction, it is the controller's job translate those intentions into the model. It is also the controller's job to translate data into the layout defined by the view.
If you wanted to shoehorn the two process you describe into this architecture, and run their development in parallel:
- Model => Software Architecture job
- View => Information Architecture job
The controller glues them together and can't exist until both a defined. So, in a perfect MVC world the two still never had to worry about intersecting because the application architecture properly separated them and allowed them to be bound together via the controller.
The Process Has Begun, Now What?
We always know the world is not perfect, and the UCD process does not always fall into place. So, what happens when things are already underway?
Based on comments below, it appears we are:
- Already underway with Software Architecture
- Just starting, or early in, the Information Architecture process
- Using MVC
So, where do we intersect? Ideally, immediately. Take the "perfect world" above and just bring the software architects into the Information Architecture process right away. Let them be a part of it and illustrate to them how the user's see the world. This will do a few things:
- Allow them to change their architecture as appropriate.
- Allow them to get a glimpse into how they will go about glueing your view to their model (MVC).
- Allow them to offer alternatives if your IA suggestions just doesn't fit and updating the SA is just not possible.
By including them immediately you avoid butting heads at the intersection and everyone gets to feel a part of the entire process.
If we're a little further down the line, or SA doesn't want to participate with IA, where do we intersect?
We're using MVC (per comments), so the intersection is when the controller is written. The power of the MVC (or similar) architecture is that the view and the model are separate. Because SA put "this here, and that there" does nothing to dictate how you organize the IA of the final interface. The controller figures this out for you.
The controller is perfectly capable of translating "A into B" and "2 into 3". Mappings can become confusing and code can become more difficult to maintain, but this is never revealed to the user. The software developers hate you (they normally do) but the users love you.
Reducing the complexity of the code is why communication should be constant from the earliest possible step.
A Quick Term Breakdown
Another comment leads me to believe there is some confusion in terms. So here is a bit more...
Software Architecture and Information Architecture are processes.
Model-View-Controller (MVC) is a software architectural pattern for implementing user interfaces. It divides a given software application into three interconnected parts, so as to separate internal representations of information from the ways that information is presented to or accepted from the user. (from Wikipedia)
The model, the view and the controller are all components of that pattern.
The model is a product of SA (and other details). The view is a product of IA (and other details). The controller is a product of getting the model and view to properly interact with each other.
The components of MVC are not "part" of any process, they are the ultimate end results. So, the controller is not "part" of "interaction and flows". Interaction and flows are defined by the IA process and are implemented into the view.
To double back and focus on some key points.
- Communication should be constant.
- IA and SA should never diverge to require "intersection".
- If they've diverged, regain communication ASAP. The absolute last rationale place for an intersection (in my opinion) is when the controller is developed to glue the view and model together.
