In order to effectively execute an IT strategy a roadmap must be created to contain and identify what common areas exist for the business' solution that could be leveraged by other systems in the enterprise or organization; or which capabilities the solution can leverage.

 

Typically architects will draw their solution design on a whiteboard, and link dependant systems that way. The key problem with that is there are a number of settings and data that are required on each node that can't easily be placed on the whiteboard. In Visual Studio 2005 Architect and Team Suite SKUs architects can go beyond the whiteboard and use the distributed system diagramming tool in Visual Studio 2005.

 

 

From this diagram the architect can update how the distributed systems are defined in a solution. Opportunities for reuse can be identified and the overall distributed system architecture can be changed quickly and easily. Then, after baseline, the architect can have Visual Studio 2005 build the stubs for these services and applications with definitions and attributes set at this aggregate level. The diagram also serves as documentation for technical requirements and can be updated after the solution is though with development to represent as-built.

 

The key idea in all of this is we begin with the end in mind and developing our IT solution to business needs. We can use these diagrams to form views of our solution--other views available in VSTS include the system designer (a drill down into each node above), class designer (a further drill down into a visual view of the code in a system), the logical datacenter designer (provides a visual representation of the desired deployment locations), and the deployment designer (creates entire deployment plan).

 

As I mentioned before, it is imperative that architects identify where existing systems or their own systems could be re-used by other areas of the business to reduce cost and improve ROI. The solution design, application design, and web service endpoint design are all key to determine what resources are available and which are needed and ultimately act as inputs to those components design or re-design to suite a more generic purpose.