When undertaking a major -- enterprise -- software project, it may be useful to consider Conway’s Law, named for Melvin Conway, which states: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
Consider this person's approach: “We should model our teams and our communication structures after the architecture we want.”
I have seen a looming problem for many of my customers: making effective use of big data is impeded by data being scatted around silos, across departments or even teams. At Bluedog, we do not have a top-down model. The management is not hierarchical management, so Workbench doesn't focus on centralized tools or reporting, which many managers see as necessary to control workers. Bluedog's architecture is focused more on the needs of the end users than on the needs of management. Perhaps report proliferation indicates a hunger for data, but difficulty for business analysts to define what is important?
If you've read my books, you know I have seen application structures evolve from the late 1980s from monolithic to modular solutions of this century, using techniques such as encapsulation and abstraction to reduce coupling and increase cohesion. With service oriented architecture, the purpose of doing so is obvious – the results are software systems that are easier to understand, change, reuse, and enhance.
How has Bluedog been successful? We start with as small a team as possible. We avoid making architectural decisions at the top, but keeping the team "understaffed," to reduce the possibility of building complexity, or over-architecting. If possible, we put the developers in the same room as the customers, business analysts, GUI designer, database gurus. Proximity encourages communication.