LinkedIn - Is Business Modelling an act of an architect?
As is / to be
Introducing a new IT system in an organization is a great change itself, and I consider it similar to code refactoring. By the book this means providing the same functionality with new architecture, and thus enable improvements that were just impossible with the previous structures. So, I agree with Yves: even if that does not look like a great improvement, the first version of the new system should better be familiar to its users by having the same terms and functions as before, and provide a flexible ground for later improvement.
Adding new features initially requires very high understanding from the developers and strong support from the users, otherwise it only replaces the old errors with new ones based on misunderstanding.
Analyst/Architect
I see the technical details as the separator.
The Analyst must focus on the business terms, structures, use cases and non-functional requirements, without(!) considering any actual technology, tool, platform, etc.; must build an ideal model that satisfies the customer and is also open for further improvements later.
The Architect should match this vision with actual technologies, existing solutions, external toolkits, platforms; identify possible bottlenecks or requests that can't or should not be solved (example: not allowing speech recognition in a critical system because misunderstanding can cause damage).
Then (another important factor): based on this input, Project Management must set up timing and resource needs, and in most cases, prioritize the tasks, and finally, create a project plan for a viable subset of the vision and architecture that is both good enough and affordable (money, time) for the customer. This requires a serious negotiation with all parties, including the customer.
Well, this list of banalities was on "Analyst level", reality does not follow this nice vision by my experience. For example, if the Analyst and the Architect is the same person, the advantage and disadvantage is the same: the plans will be more technical, but the actual implementation details may break the (very important and required) abstractness of the business analysis, probably limiting the flexibility of the whole system.
Anyway, this was my 2 cents...
