[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: XML As Fall Guy
Hi Stephen, no real argument with anything you've said. The term architect is intentionally co-opted and people in IT with that title usually are performing a different role than a Business Analyst. In my experience the Business Analyst finds and defines the use cases and the architect then tries to abstract the patterns out of those use cases and figure out the conceptual and logical designs that will meet them. As for UML, an application architect might be using UML but I find it pretty painful; it seems to me to be more of a detail design tool, and then useful only if you have to convey the detail design of a very large system to many people. Personally, I'd rather find the natural component divisions, divide those among the teams and let the teams work out the interfaces and not attempt to pre-ordain them completely.
As to your question "Is software as a written language that has to communicate to machines and humans different?" I'd also say yes. Not just from DDD, the pure diversity in programming languages supports that and the drive for languages such as Scala to support Domain Specific Language implementations gives some hints on how that can be generalized. However, DDD isn't going to eliminate any need for architecture. Identifying the proper domains is still a hard job and, in particular, good abstractions and generalizations are hard to get right. If that's left to "iterative refinement" then massive re-factoring becomes the rule and not at the level of continuous re-factoring as a good development process but more at the level of throw everything out and start over if you are not careful. Even worse, in many cases the the re-factoring is too complex for the teams to see the patterns across the individual components already built and the iterative design just doesn't happen as a result. I'm sure you are aware of the studies that show that errors caught in the design phase are way less expensive to fix than those caught later on (least of all after your healthcare.gove site is unleashed on the public)? Good architecture practices try to push that analysis as early in the process as possible. People focus on software development when they talk about Agile but that's usually Scrum or Kanban and that's only a small part of the Agile story. I've heard people suggest that it's as little as 1/12th of the process because of the way XP divides things up. I'm not sure I'd go that far, but I do think the "Iterative planning" portion of the process doesn't get the focus at as wide of scale as is needed for complex projects.
Peter Hunsberger
On Wed, Dec 4, 2013 at 7:44 PM, Stephen Cameron <steve.cameron.62@gmail.com> wrote:
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|