No Magic MagicDraw Review
Mighty mighty tool, heavy load of functions, make it easier for non UMLers by customization to your needs


What is our primary use case?

Model-driven documentation including project architecture management, system architecture modeling, reverse engineering of salesforce data model, and providing method & tooling for whole project for modeling all other concepts plus output management to Sharepoint, Confluence, HP ALM

How has it helped my organization?

Our approach has made it possible to work with single diagrams and concepts every day, publish our knowledge base for the project team every week, and deliver documents like IT architecture and IT design for quality gates every three months or so and in compliance to the software development process and its valued templates.

The approach of introducing a dedicated method as a domain specific language has made it possible to let more project team members contribute to our knowledge base.

A core of the knowledge base has been defined that is "mounted" into other models focusing on various aspects like process definition and requirements analysis. The architecture model delivers the lego bricks that the business uses for assembling processes and workflows.

What is most valuable?

  • Plugin development implementing domain specific languages on UML making modeling much easier for non UML experts
  • Customized diagram types
  • Customized report templates for producing Word, Powerpoint, Excel from models
  • Producing complete architecture and IT design documents from models (model-driven documentation)
  • Generic tables as a diagram type that allows for viewing the same elements and relations of your diagrams as rows in a table with their properties as editable columns (such a great feature)
  • V18 comes with a mighty improvement for search called smart packages that allow you to save search request, materialize results, and feed generic tables.
  • Engineering and reverse engineering of data models and interfaces

What needs improvement?

As an architect who switches abstraction levels between enterprise architecture, project architecture, and system architecture I would highly appreciate standardized integration with EAM tools like Alfabet (formerly planningIT) e.g. using XMI.

The MagicDraw Teamwork Server allows for collaboration of modelers throughout an organization or even enterprise. But model size and concurrency are restricted due to the storage system. A real database storage layer in combination with lazy loading is needed to get rid of the necessity to split models in handy chunks today. Larger models slow you down; committing, updating, merging of branches and comparing of models (diff) do not scale yet; issues will hopefully be solved with upcoming V19.

Moreover, for EAM it is very important to not think in tons of models, but in an enterprise-wide repository (one database) instead with access via web portal and roles & rights management and alike enterprise features. Such features are subsequently built into the product (teamwork cloud, enterprise data warehouse) and will hopefully be merged in an upcoming version.

For how long have I used the solution?

More than five years.

What do I think about the stability of the solution?

Due to the fact that the tool loads models completely in main memory (no lazy loading) large models in combination with low JAVA memory settings can lead to crashes. Someone in the team should be able to cut models into modules.

What do I think about the scalability of the solution?

Letting larger teams work with one model concurrently without organizing partitions will highly increase waiting times due to lock & checking cycles.

How is customer service and technical support?

Customer Service:

Very good, excellent people, helpful advise.

Technical Support:

The customer has own dedicated support team on site which solves >90% of the issues and routes <10% to the vendor support. I can recommend this approach.

Which solutions did we use previously?

I was used to IBM Rational and switched because you work with the standards of your customers, right?

How was the initial setup?

Download tool, download plugins, installation wizard, activate

What about the implementation team?

I built a plugin containing a UML profile, a dedicated diagram type, and report templates for the architecture method of my customer; I was building the plugin during an early phase of a larger project in an agile way delivering feature after feature at the time they were needed in the project

What was our ROI?

After having filled a good portion of knowledge into the repository the way you are working shifts more to searching already existing content and assembling or adapting it for current questions or changes. Where others start research in various document libraries I am now able to often answer questions in a matter of minutes with much higher quality. I alone can maintain all architecture documentation for a larger project as well as for one or two selected systems.

What's my experience with pricing, setup cost, and licensing?

For most users standard floating licenses will suffice. For expert users and restricted features also provide some enterprise floating licenses (like 1 enterprise per 5 standard licenses). If possible provide a few named licenses for power users that work with the tool night and day otherwise they'll block more expensive floating licenses (calculate 5 users sharing 1 floating license).

Which other solutions did I evaluate?

I evaluated the most common approach as reference (Powerpoint, Excel, and Visio), Sparc Enterprise Architect because it is very well known in Germany, No Magic MagicDraw because it is the standard tool at the customer, and alfabet planningIT because it is the standard EAM tool at the customer.

What other advice do I have?

The most important factors of success when introducing the tool into your project organization:

1. Get someone who really knows it, can teach it, can configure it to your needs (method & tool expert)!

2. Get someone who really knows your model(s) and amends it frequently by refactoring the contents (librarian, may be the same person(s) as above)!

3. Do not wait half a year or even longer until your method is finished, it never will! Start the very first day, reserve 20-40% of 1. and 2. to iterate your method in an agile way. Start with the concepts you need first.

And don't forget to publish your content to your most frequently used channels like your project file share, Sharepoint, web server so that all project team members can consume your knowledge even if they cannot or do not want to use the tool.

Produce tables with elements from your models (diagrams) as input for project management, test management, migration management, whatever management!

Disclosure: I am a real user, and this review is based on my own experience and opinions.
2 visitors found this review helpful

Add a Comment

Guest
Why do you like it?

Sign Up with Email