News: Combating Complexity: Eight Architects Tell You How
OTN wraps up the Middleware Architecture Series with some surprising points of agreement among eight experienced software architects and some useful strategies for you to cope with architecture challenges.
- Posted by: Sudhakar Ramakrishnan
- Posted on: July 26 2004 14:00 EDT
Combating Complexity: Eight Architects Tell You How
As we sifted through the series for common themes, we kept coming back to the same strategic recommendations:
Cultivate collaboration as an architect dealing with complex, multi-layered applications, one of your most important tasks is bringing together people from the groups responsible for those layers and getting them to communicate and collaborate effectively.
Keep an eye on the Big Picture as overall system architect, you need to have the big-picture perspective not just of how the layers of your system fit together, but also of how your system will meet its business goals and work effectively on a human level.
Implement rigorous processes adhering to formal processes (for tasks such as model development, evaluation of solutions, and system maintenance) is a key strategy for focusing and simplifying your team's effort.
Additional articles in the Middleware Architecture Series
Who do you want to convince that someone can tell you in some screenfuls how to avoid complexity in software architecture?
For example, take the nice hint "Developing an effective model": If it were that easy, complexity wouldn't be any point in software architecture.
Or "Keep an eye on the Big Picture": Very helpful, consider that as knowledge that only real experts have... ;-)
After looking over the other articles in this series, as an editors note its ok, but as an article itself, this is a mere collection of buzzwords
Or "Keep an eye on the Big Picture": Very helpful, consider that as knowledge that only real experts have... ;-)Very simple: become an expert; most others will be extinct soon. I would say that the article is good and it is a short version of the following books:
I like what the authors were trying to do but the article would have benefited from some more concrete examples.
Which processes exactly did they put in place to manage complexity/communication. Regular design/code reviews, continuous integration, rss feeds of source control diffs? Did they follow RUP or UP?
From my experience the PATTERN REPEATABILITY and REPLICATION COST are keys to success in long-run.
These is Number One in my own list of quality estimation criteria. Then - Cost, Maintainability and Performance ... somewhere closing top 10 :-)