Friday, 2 October 2009

Microsoft Visio – Suitable for Modeling SOA and EA?

Over the last month, I have been looking at Microsoft Visio as a possible tool for modelling Service Architecture and other SOA deliverables and as a place to capture the Enterprise Architecture. This was prompted in part by a product report I have just completed on Orbus Software’s iServer product, which adds a multi-user repository to Visio.
Given the number of specialist modeling tools there are on the market, it is surprising how many enterprises we encounter that use Microsoft Office as their prime vehicle for capturing various items of metadata and producing the documentation and diagrams required to support their IT architecture and delivery projects. Requirements and specification deliverables are routinely documented using Microsoft Word, while metadata is captured as columns and rows in Microsoft Excel spreadsheets, and diagrams are constructed using Microsoft Visio (or even just Microsoft PowerPoint). However, there are many shortcomings to this approach in an enterprise context, and that is primarily what iServer sets out to address and I have examined in my report.
Until now, I had only been a casual Visio user. For simple diagrams we publish in reports, PowerPoint is sufficient, and also the format we provide to our customers. For more rigorous work – with our clients for example, or to produce our SAE Meta Model, then we use other UML modelling tools.
Once I started investigating though, I was impressed how simple it is to create your own stencils and templates, but moreover how straightforward it is then to connect instances of the shapes to items in a Microsoft SharePoint list. In the example below, I created a simple template for the Service Specification Architecture diagram we use in CBDI-SAE, and then linked it to a SharePoint list containing a catalog of Information System Services (TOGAF) which are classified by Service Architecture Layer.
Hence it would be straightforward to create a Service Catalog in SharePoint, and then visualise the architecture for the services in Visio. My product report looks at how to do this in iServer. Clearly that is a more robust solution than my simple SharePoint example. However, for anyone with SharePoint and Visio already at their disposal, all it takes is some effort on their part.
Hopefully I will find some time to work on a Visio Template and corresponding SharePoint Template for CBDI-SAE and make these available in the same way we have done with our UML Profile.
Let me know if that would be useful.
In the meantime, I am interested to know just how many folk are using Microsoft Office and Visio as their prime tools for capturing EA and SOA deliverables, and what your experiences are.


  1. Hi lawrence,

    The answer is no, it's not suitable.

    I have used Visio for standalone simple diagrams, but once you have a large model, a mass of connections between objects over several pages, and need to redraw the diagrams it rapidly become unmanageable compared with 'proper' EA modelling tools. I have had corruption issues with older versions of Visio.
    It still seems easy to accidentally corrupt diagrams.

    There is no repository in the version that organisations normally provide their staff so details about objects can't be held anywhere.

    iServer from does look like it will address the repository problem, but I haven't tried this solution in anger yet.

    On its own Visio is really just a drawing tool and not a modelling tool, and I don't recommend it to my EA clients. Other tools like BiZZdesign Architect or Sparxsystems Enterprise Architect are much more capable.

  2. Interesting comments Adrian. Thanks.

    So whilst iServer might add the respository function and better manage relationships between objects, it cannot itself overcome shortcomings in Visio in diagramming large complex models.

    It is also perhaps an inevitability of EA that models will be large and complex. However, that doesn't necessarily mean that all objects will be viewed at once, and you can scope things on smaller domain basis, and attempt to minimise dependencies between domains. But even so, that may be more appropriate to the target model and not the current state, where there may be no such structure...