Designing for Deployment (
Page 1 of 2 )
Here's one part of Visual Studio 2005's Team System that you may not have explored yet. The System Definition Model lets an architect diagram the system to describe the application's environment, security policies, and other requirements imposed by Operat
In a perfect world, systems would be architected and deployed as a cohesive whole, with all involved parties knowing how the pieces fit together. They would play nicely with other systems, sharing data politely and never stepping on each others' virtual toes. Developers and the operations folks would take tea together and share critical information, pinkies daintily extended, in genteel and moderated tones.
Miss Manners would be proud.
Then there's the Real World: DLL Hell, mysterious black boxes in patchwork systems, mis-configured servers (or apps that make unreasonable demands of properly configured servers) and neither developers nor operations knowing what the other is doing. When the developers finally throw a new app over the fence, it often lands with a splat.
And people yell. Or they mutter darkly under their breath, as they struggle to fix what ought not to have happened in the first place.
Distributed systems are particularly messy because, well, they're distributed. And the more places pieces of an app live, the more people are involved, and the more chances there are for miscommunication.
I guess there's been a lot of yelling and muttering over the years at Microsoft, because in Visual Studio 2005 Team System, they're finally providing tools to help mitigate the issues.
In Visual Studio 2005 Team Edition for System Architects (also part of the Team Suite), what Microsoft calls the first deliverable in the Dynamic Systems Initiative, Distributed System Designers, describe and validate distributed systems dynamically.
Which means — what?
Architecture 
