In late 2009 (just before version 8 was released), I began learning how to use Sparx EA. A different branch in the organization I work for had purchased a few licenses to evaluate using Sparx EA as a Data Modeling tool, they decided to go with a different product, but thought that I might want to take a look for my Business Analysis work.
To be honest, at the beginning I found to tool to be a bit overwhelming, but soon realized the developer’s of Sparx EA had made a few assumptions:
- You have a plan for how you’ll organize your work
- You already know and understand the modeling notations you plan to work with
- You know how the modeling notations compliment and conflict with each other
- You DO NOT want Sparx EA to dictate to you how your work should be organized.
I had already made some progress on 2 and 3, but it took me a few month of experimentation to realize that it really was up to me how to organize my work, and other than some basic examples, Sparx wasn’t going to hand me the answer.
Once I understood there was no “right” way to use Sparx EA, I began to setup Sparx EA as an Enterprise Tool and Repository for our organization.
A lot of what you’ll see in this blog are entries based on my, my staff and my peers experiments and the lessons learned while we used Sparx EA to capture the models and information we rely on as Business Analysts.