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