If architecting was only about solving a technical problem, then this discipline would be strictly under the computer science domain. What makes software architecture a child of the software engineering domain is the fact that an effective solution needs to solve business problem or achieve a mission.
It’s clear that an architect has to work works very closely with all stakeholders in order to understand the root of the problem for which a solution has been envisioned. There are two core qualities that an architect must exhibit. First, an architect must have an implementable vision of the whole concept from start to finish (if you don’t who will?). Second, an architect must intelligently question the business problem that a customer is trying to solve. This is very important, because this will minimize the risk of the solution not fitting into the existing (or future) technical and business infrastructure.
In mature organizations both software architects and business analysts speak a common language and work jointly to make sure a solution supports a business problem. In other organizations the burden often falls on the software architect to make sure that a solution design exhibits conceptual integrity from the business point of view. It’s not uncommon to have a group of business stakeholders individually represent what they want to see come out of the solution. But someone (business architect role) has to take ownership of the discrete needs and integrate them together into a comprehensive plan. Not every software architect is capable of deriving the root cause of a problem, and that’s OK. But a mature software architect would know when to bring in help to enable him to design the right solution.
Due to constraints thorough analysis is not always possible. This is where an architect must make a judgment call and make progress based on the known factors. In such situations it’s imperative to document risks and limitations of the solution so that the final result is judged against this segment of time.