Tools for Architects?


While VSTA has been pitched as a tool for the software architect discipline, I think of VSTA in a different way. I think of it simply as architecture tools. While useful for any of the various types of architects (http://blogs.msdn.com/smguest/archive/2005/12/12/503001.aspx)  that might exist out there, the product's usefulness is not limited to those roles.  The product is useful to anyone who works on the software architecture, whether they are an architect or not.


I also recognize that there are a large set of architects who are deeply engaged in the development process. These architects may find that VSTS's developer SKU also offers them significant value.


Comments (8)

  1. tadanderson says:

    I think the pitch that VSTS 2005 tool is for the software architect discipline was very misleading. VSTS 2005 offers nothing for the Software architect.

    See my concerns here:

    [http://realworldsa.dotnetdevelopersjournal.com/dsl.htm]

    See Jack Greenfield’s response here:

    [http://blogs.msdn.com/jackgr/archive/2006/01/06/510162.aspx]

    Where he openly admit Software Architects were ignored in the initial releases of VSTS 2005.

  2. MSDN Archive says:

    I’m the first to say that an architect will need to use other tools such as Visio to fill the holes in the current toolset. Which is why we invested in upgrading Visio to work on VS2005, even though we decided not to support UML 2.0. This in itself was no small task. Furthermore, some of the early marketing slides indicated that we might release the Visio UML tools only in the Architect SKU. This was later revised.

    I also agree with Jack’s statement that we had to scope this release to make our tight schedule. Therefore, we focused on an acheivable target for V1, i.e. supporting Connected Systems and our DSI intiative. As a result, we focused only on the structural viewpoint of the architecture. This, however, does not reduce the value of the current toolset for its given purpose. I am simply recognizing that VSTA still has some distance to cover in order to meet all the tooling needs of a Software Architect.

    Also, I’m not sure about how you (or Jack) defined a Software Architect. Nevertheless, Jack does mention that the tools were targeted towards the System Architect. He, in my opinion, however, fails to point out that Software Architects is a set that includes System Architects. Jack is an example of this himself as he is one of the key architects defining the system architecture of the current toolset. Please note that his designations is still a Software Architect.

    Thanks,

    Ali

  3. MSDN Archive says:

    Please read "the structural viewpoint" as "a structural viewpoint"

  4. tadanderson says:

    Thanks for you response. I think you guys did do a tremendous job in the features you included in the toolset. There are plenty of new tools for the System Architect, Developer, Tester, and Project manager. I did however switch my VSTS MSDN subscription from Architect to Developer once I saw the tools where only geared towards System Architects.

    I view a Software Architect as someone who is concerned with all the views of the application and is concerned with architecting a complete solution based on functional requirements elicited from all stakeholders and non-functional (Quality Attributes) requirements.

    I view a System Architect as someone primarily focused on the software in the context of hardware and the software’s physical architecture only, or the implementation view of the application. This is all VSTS 2005 concentrated on.

    Part of the job of a Software Architect is to concern themselves with System Architecture, but that is only one part of what must be considered.

    I did notice Visio Architect version was upgraded to Visio 2003 as it’s core, but it’s integration with VSTS is not any better, and as you mentioned is still not in UML 2.0. My job can be done with Visio, but the effort to use it is huge effort compared to tools built for Software Architecture, like XDE was. Having Visio offered free is nice, but it makes it a pain to sell management on the fact that it will be cheaper in the long run to spend the money on another tool that offers a better set of tools for Software Architecture as well as Analysis and Design.

    We ended up doing this to resolve the problem:

    [http://realworldsa.dotnetdevelopersjournal.com/uml_in_vsts_2005_provided_by_sparx_ea.htm]

  5. MSDN Archive says:

    Tad, you have provided a laundary list of things that we need to provide.

    What would be great is if you could provide the top three adoption blockers?

    If we could offer you one feature to convince you to get the Architect SKU, what would it be?

  6. tadanderson says:

    The top 3 adoption blockers:

    1. Currently VSTS 2005 only provides tool for the System Architect, or in the blog you referred too a Infrastructure Architect. I need it to provide me with the tools that make it possible to fill the role of the other Architect Personas. I do not agree with the 3 personas so it goes to a level farther than what they offer. I see an Application Architect and a Software Architect at different levels. A software architect is capable of providing packaged software or a product line. An application architect is only capable of providing custom applications, which are many times one piece of an enterprise. I view an Enterprise Architect as someone able to manage an Enterprise Portfolio that has become a professional in managing their domain. The laundry list I provided will have the potential of being used with a given component or module of the product line I am implementing. I am working with off-shore development teams, so I can not say what I am willing to live without when it comes to being able to visually describe the component that we are asking them to build. Right now, for this given project I need the UML diagrams I listed, and VSTS 2005 for Software Architects offers none of them. I know a lot of times you will find people usually only use the static class diagrams, component diagrams, and sequence diagrams, but I have found the need for each of the modeling diagrams on different projects given a certain development environment (off-shore, local, etc.) and a components complexity.

    2. The lack of development tools, when compared to VSTS 2005 for Developers, was very disheartening. The entire time, many times before I start the modeling and document of an architecture, I will be coding an Architectural Synthesis. Development tools for a Software Architect are as important, if not more important, as they are for any level developer. To find that MS doesn’t recognize that, is not a good thing. All the development tools would need to be in the VSTS 2005 for Software Architects for me to consider it.

    3. My #1 and #2 adoption blockers.

    I think the one feature you could provide to convince me to switch is institutionalizing Software Factories as an industry standard. MS has marched down that path and now needs to fulfill it’s obligation to us. I need to do my job with current industry standards and until MS provides me with the tools to do so, I will be forced to turn to third party tools. Part of the Software Factory movement is Product Line Engineering, which should mean MS is going to provide me the tools to get my job done.

    One thing that has me puzzled is how MS is planning on pulling this off, with no support for UML? Essential Unified Process (essUP): [http://realworldsa.dotnetdevelopersjournal.com/essentialunifiedprocess.htm]

  7. Eddie Hulme says:

    I am employed as a Systems Architect working with Enterprise Architects and have to have an appreciation of the complete enterprise domain I am working within.

    I am conversant and work within the various architectural planes of Enterprise, Information, Application and Infrastructure – and moving within these I can map the systems architectures within each and at the enterprise level can see how they all interact.

    I have to be able to modell these planes and also capture requirements and then model the business flows from these requirements into the Information Architecture. Only in understanding this interaction can I start to explore the application and infrastructure planes/layers.

    Too often and I see this all the time in the development space especially where developers call themselves architects – we start coding or selecting hardware and then code for the hardware forgeting the business needs. This is why such businesses who allow developers to drive their IS/IT end up paying heavily for years as custom development drives more custom developement.

    Using VSTS I can create an Infrastructure Model – but not a true large scale Systems Model based on the Systems Architecture. I cant model an Enterprise and until Borlands Tools are fully integrated into VSTS I cant even imagine attempting business analysis and automated requirements capture and modelling.

    Visio isnt there yet!But we all love it.

    As an application developer – I can use infrastructure modelling to design services and create code – I would also like to throw into the debate here the term developer and architect – since when have developers been architects – I suppose since the term architect pays more on the CV.

    problem is its all a bit disjointed.

    Do I build a datacentre or deploy infrastructure, then create a systems architecture, then create applications? A bit arse about face this.

    How about a Business and Enterprise Architecture. Design the building.

    Then based on the Enterprise put together an Information Architecture and Systems Architecture – you need both. From this define the Infrastructure Architecture including those common services needed to support the Information/Systems Architecture.

    Then within tose constraints let the developers loose with templates within VSTS.

    Software Architect v Application Architect – sorry chaps – we are playing on semantics – get back to basics and stop confusing the industry and our clients.

    regards

    Eddie

  8. tadanderson says:

    I wish I could agree with "Software Architect v Application Architect – sorry chaps – we are playing on semantics – get back to basics and stop confusing" but since I am in my 4th month of training Application Architects on how to turn their application into a product and moving them into being Software Architects, I can’t agree.

    The place I am at is great at one-off development and have some good architects who put the architecture of their application quite well, but they were, and are still somewhat lost, in moving to product line engineering. Building a product and building an application are two entirely different things. Until you have had the opportunity to work in both roles, you will not understand the large gap between the two. Hiring a carpenter to build your home because that is what he does, and then because he did such a great job you then ask him to build you a hospital that you are funding would not make much sense. I think customers need to be aware of the differences so they can hire the right person for the job.

    I have never said you don’t need both a system and software architect. On this current project I am working closely with a system architect to put together the physical infrastructure of the application. I only said VSTS 2005 supports the system architect only and offers nothing for the software architect.

Skip to main content