No Magic MagicDraw Reviews

We use it for model based system engineering (MDSE).

I think one of the key things is the plugins for integration with requirements management tools like Doors. I think this is very helpful.

No Magic MagicDraw provides a lot of good features on functionality.

The documentation for MagicDraw and the video tutorials compared to those of the other companies are really a big area for improvement.

The other area would be having some profiles and ready-to-use patterns. It's something that is missing in MagicDraw compared to that in other tools. I think that it would be very helpful to have such profiles and ready-to-use patterns that would kickstart any architecture asset.

Licensing is expensive for this solution.

I believe that the overall UX needs to be completely reformed. The UI UX of the tool is not really user-friendly.

I've been using MagicDraw for probably three years now.

Our experience with technical support was positive. They responded in 24 to 48 hours.

I think the overall setup was very straightforward and easy; nothing was really complex. It took a minimal amount of time given that it's on-premises.

I did the deployment myself.

The licensing is on a yearly basis, and it's expensive. This is one of the qualms of this solution, and that's one of the reasons why we're not going to continue using it.

I would rate it at seven on scale from one to ten because it's still a good tool. It provides a lot of good features on functionality but still has room for improvement.

Before you start implementing No Magic MagicDraw, I would definitely recommend that you look at other solutions. You could take a look at Sparks and compare both Sparks and MagicDraw before you proceed with MagicDraw.

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

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.

• 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

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.

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.

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

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.

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

Download tool, download plugins, installation wizard, activate

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

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.

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).

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.

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!

It's now called Cameo Enterprise Architect 19. It is my system engineering tool.

I do systems engineering. If you go to my website, www.simtrs.com, there are simulation and training for this solution. You will see the benefits of MagicDraw and how I use it.

I use it for systems engineering and life cycle systems engineering, and even for deployment. The beauty of MagicDraw is that it has a simulation part, so you can simulate your model to validate it. The simulation allows you to bring in code off of an external code that you can write to set up the simulation and execute the code.

We are getting away from the old ways of writing a lot of papers and requirements documents, architecture documents, technical solution documents, interface documents - those days are gone. MagicDraw allows you to model the requirements and by doing so, you've got a good chance of not missing any requirements. The old way of doing things was to decompose the requirements into shell statements.

But when you model it, you will be able to practically make sure you don't miss anything. MagicDraw has a good modeling tool you use for case diagrams. Its use case diagram is part of the UML and SysML that you can use to model requirements to create an architecture. I've created a lot of architectures for the Army and also mapped those components of the architecture as the test procedures.

I wouldn't say anything negative about No Magic MagicDraw. But there is a steep learning curve. The steep learning curve applies to two things - system engineering and INCOSE. INCOSE, I-N-C-O-S-E international systems engineering. INCOSE is what most people use today for system engineering, for building systems, and deploying and maintaining them in a full life cycle. For MagicDraw there is a steep learning curve if you don't have the system engineering domain experience because a lot of folks go in there and say, "Okay, I'm going to do model-based system engineering." MagicDraw has a model-based system engineering tool but it only allows you to draw the diagram or the model. Then you need to understand the relationships between the processes and activities.

So some people can pick it up, but it's a steep learning curve. You have to do the correct keystrokes to portray what it is you're really trying to do. You take a picture, an ER diagram, Entity Relationship diagram, which is a diagram that shows all the components and how they relate to each other, not just an arrow. You can say this component influences another component or another component enables integration, etc... Things like that. You have to know what your relationships are and MagicDraw allows you to do that really well.

But they do provide manuals. They have a lot of manuals that you can go through for each plug-in they have. You have the system engineering piece, and then you have the DoDAAC, which is the DOD architecture. They use what they call a UPDM, that's a DoDAAC standard. You also have the UAF. System Ellis is the base for everything, but you've got other pieces for the government first. When working for the government, they require that you do your architecture using the DoDAAC. So it has the DoDAAC too, because the government likes certain things. It depends on who your customer is and what they want.

For the next releases, I would like to have them import requirements from other sources. They could make it very easy to do that because there are a lot requirements management tools like DOORS, D-O-O-R-S, Dynamic Object Oriented Management. A lot of folks use DOORS to create a requirement. For those requirements you allocate them to a component in the architecture and a verification method for that requirement. It would be good if we could import those into MagicDraw as components so you don't have to manually do these things.

I have been using No Magic MagicDraw for about 10 years.

The way MagicDraw scales is very good. You have the team server which allows a lot of people to use the product for a specific path. I can create different pieces because you don't want to have hundreds of sheets of the same model. Imagine you're flying a plane and you come over a city and see the view from 10,000 feet. But then as you come down you come into more details. When you're on the ground you'll be going to a bathroom, for example. If you want a model of the bathroom you've got to be able to set it up.

MagicDraw will scale that way, but someone has to be able to set it up to give you that granularity. You can get the bird's eye view or you can get the pie in the sky. It's like you are in an aircraft. You can see the city, but as you come down lower, you see the cars start running on the freeways. And as you get lower, you can see the toll booths and the gas stations. That is how it scales, but you have to have the ingenuity to be able to model it so that you can flip from model to model, which it allows. But it would be nice if I could have hyperlinks in there, where I could take the big model, click and see, just like you see Google Earth.

As you click it further up and down, it gets bigger and smaller and smaller and smaller until you get down to the very house that you live in. It'd be nice if they add hyperlinks or something like that so your customer wouldn't have to be an expert in MagicDraw. Because the way it is now, I have to import it to JPEG's or to files and organize it in such a way that it would take me a lot of time to describe what an architecture is. This is especially true for large systems. For small systems it's not a problem but for large systems it can be. For example, if you want to draw an architectural automobile, you start with the basics. But then when you start drilling down into the engine and the carburetor and all those different things, it can get very hairy. So you've got to be able to organize it in such a way and that capability isn't there. You have to do that manually.

On a scale of one to ten, I would give No Magic MagicDraw a nine.

Overall I find it very effective and the customers are happy with it.

We use MagicDraw for model-based systems engineering. It differs from standard systems engineering applications by using models, as opposed to words or sheets. We define our system or subsystems via models and interfaces and then define the relationships between them.

It is used mostly during the design phase of all of our projects. After the production and testing phases, it is no longer used.

This solution can be customized to your needs.

The technical support is very good.

It is easy to set up and use.

The cost of upgrading the product should be lower.

It would be useful if there were a way of comparing the production and design models. It is not necessary because there are other tools to validate the design but having it included would be good.

I have been using MagicDraw for more close to four years.

It is very stable. They also update the software and when they do, they send an email to let us know what has changed and what new features we can use.

We have six users in the company.

I have been in contact with technical support and they are always there to help you. Whenever I need something, they help me. For example, I was trying to create numbers for a subsystem that followed a pattern like A1, A2, A3... but I could not find it in the program. When I contacted support, they told me that it was possible and they taught me how to do it. In the end, I was able to do it.

The initial setup is very easy.

I set up this software and the Teamwork Server that we use to allow multiple people to work on the same projects. After receiving the software, it took me less than a week to deploy it.

In addition to the initial cost, you have to pay annually for support in order to get the upgrades.

My advice to anybody who is designing complex projects, like defense projects or space projects, is that they have to use this program or one like it. All of the stakeholders have to understand that they need to review the product using models, in addition to the documents. Following this will ensure that it is very easy to understand the product that is being designed. 

I would rate this solution a nine out of ten.

The primary use case of this solution is for modeling and collaboration.

The most valuable feature is the amount of flexibility that one has to model, which is great for an individual. But it becomes a problem when you're trying to collaborate within a team. It is not a strongly coupled tool.

I dabble with the OMG (object management group) in terms of definitions of standard. OMG is now working on SysML version 2.0 and there is significant work that needs to be done to eliminate some of the ambiguities and foibles in the standard itself.

The user interface could have better quality tutorials. When I go to the manual, I can hyperlink along, but there are subtleties that you literally have to find by trying and doing.

One of the issues I am currently experiencing is with one of my environments. I use a Windows environment and a Mac environment. When I am working with my Mac and I right-click to copy and paste, it doesn't work. 

I find myself going back to the old control characters like Ctrl-C to copy and Ctrl-V to paste. Also, some of the ways that one can create elements and move more at a hierarchy in the model of view and the browser, don't work. I finally found an approach that has worked. 

In the next release, it would be better to have cleaner manuals that lead people along in a simpler way.

I have been an occasional user of No Magic MagicDraw for approximately five years.

We are running two different versions at the moment. One is version 18.5 and the other is version 19.

This solution is stable. I have not experienced any glitches and nothing has crashed that I haven't been the cause of.

This is a scalable tool. It's very flexible and all of the stereotypes that you can select or add, for example, we call it the 80/20 rule, where 20% of the tool usage gets you to 80% of the capabilities you need. 

I have not had the need to contact technical support.

Previously, I used the Sparx Enterprise Architect. I still use it on occasion.

The initial setup is straightforward.

We have an in-house team to maintain this solution.

For one of them, we had a government administrator to set it up. I did the other one myself.

I am not aware of the costs, as this solution is offered to me by the clients.

I am a sole proprietor consultant and I work within teams that are a mix of contractors and government employees. Also, I am an adjunct professor.

My advice goes back to the 80/20 rule. There is 20% of the basic fundamental capabilities that you will get you 80% of what you need or more.

My advice is to have a standard framework for a model within the enterprise. In terms of a standard hierarchy structure, know where you put the requirements or the logical architecture. Also, know how it changes depending on whether you are dealing with a system or with a system's assistance. The system's assistance depends on whether you have a directed governance environment or a federal, or coalition of the willing.

Because of the issues, I am experiencing with the OMG, I would rate this solution a five out of ten.

I am using MagicDraw as part of my research project.

The most valuable feature of this solution would be model-based system engineering. The MBSE capability of MagicDraw is higher than the other competitors.

The documentation for MagicDraw and the video tutorials compared to other competitors is an area for improvement.

In the next release, I would like to see more profiles and ready to use patterns. Rather than working from scratch, I would like to be able to tap into these patterns.

Some of the other competitors have that capability and I think that it is extremely helpful.

It's a stable solution. We have not had any issues.

I am not able to assess the scalability as we have not attempted to scale beyond the initial installation.

My experience with technical support was good.

I haven't interacted with them often but their response was reasonably fast. I usually get a response within 24 to 48 hours.

The initial setup is straightforward.

We completed the implementation in-house.

I would rate this solution a seven out of ten.

Used for Business and Systems Engineering modeling. Its role is to support a defense program that consists of multiple product lines.

No Magic software has great capabilities in supporting integrated business and systems modeling.

No Magic has the tools and capabilities to model a complete enterprise and all product lines.

For the most part, No Magic is a great tool for modeling. However, there are some technical features that you have to study and do research on to be able to understand.

I use it for model-based system engineering. We are customers of No Magic and I'm the principal system engineer.

The product offers good standards compliance and it's user-friendly.

The technical support is not very good and hasn't been since the company was bought out. It's difficult to raise a ticket, and they don't always respond.

I've been using this solution for 10 years. 

The solution is stable. 

The solution is scalable. We have six users in the company. 

The customer support is not good. 

The complexity of the initial setup depends on your use case. I found it reasonably straightforward. 

This is a very expensive solution.