Monthly Archives: December 2012

Why this site?

Following on from Why EA?  its now over 10+ years since I’ve been using EA (V3.5 2002).  It is now a much more powerful tool with a lot more functionality and I’m inspired to explore some of these capabilities. Not least I expect to learn stuff that may be useful to me, or at least intellectually interesting if not directly related to my day job.

My main use of EA to date has been in the roles of a:

  • User  – developing product specifications, managing requirements and developing processes
  • Administrator – setting up and managing EA projects as well as managing/training teams of users
  • Software developer – designing/integrating tools/coding including developing EA Extensions

I find (and observe) that with most tools once a user is over the initial learning curve there is little increased use of features.  Probably due to a lack of need and/or awareness. I can recall occassions when I have seen a colleague using a feature of a tool unknown to me and immediately gone about using it and it is at these times I feel I should be spending more time learning.

If as part of the tool induction process a user attends (and puts the effort into) a good tailored training course they are likely to benefit.  At this point I could have a big rant about organisations who don’t invest in training their staff on the tools they are asking them to use – seems such as waste both for the users and I’m sure financially for the company – end of potential big rant!

Personally I know I have tended to use the same stuff in EA and there is a lot more that I should know about.  Also there is a lot that I’ll probably never need to use in my day job that could be of interest.  As with many topics the more you learn about something the more you realise that you don’t know.

So I aim to dedicate some time to exploring EA further very much in an experimental mode – to check out areas of the product, what they do and how they may be used.  I’m not committing to do anything other than explore and hopefully find some interesting and useful stuff.  Clearly where I spend my time will be based on my interests so there will probably remain areas I just don’t touch.

Rather than keep the results of these experiments in my own personal notes, and hence only useful to me, I thought I’d make a bit of an effort to share information I find – hence this site. In doing this I’ll probably include notes on stuff I do know how to do and my experiences of doing it. At times some of my writings will be in note form and hence may not make sense and in time this will be resolved.

BUT just a reminder (a word of caution) – what I do, the why I do it the way and the tools/environment I use is very individual to my particular needs and may not match what you are trying to do so beware of taking any of my information on face value and applying in any other situation.

So whats the plan:

I’m going to spend some time pulling together some experiements and as time permits document them on this site. I’m not promising to provide the answers to your problems (Sparx provide support, their forum and community site do that), but if you

  • Are curious about EA and what it can do – me too – 1st job will be to trawl through the latest product and check out what I may like to explore
  • Are looking for some examples on how to use EA – I intend to produce simple but working examples to test stuff
  • Want to see how to extend EAs functionalityonce again will produce working examples – although nothing too big (get enough of that during the day!)

then perhaps some of this stuff I capture in this notebook will be interesting to you.


Why EA?

I’ll start by saying that I’m a bit of a EA Evangelist, not because I’ve been paid to be one or indoctrinated by others but because I’ve found it to be an invaluable tool in many different areas of my work.

My interest in, and subsequent long-term use of, EA started over a decade ago (mid-2002).  When working as a product manager I was tasked with bringing together the specifications for some new  products.  This work involved capturing and consolidating all the requirements from interested parties, enhancing them as necessary for clarification, prioritising them against market need and ensuring that we could track compliance of candidate products.

At first sight this seemed pretty straightforward until I realised that the source information was stored in lots of spreadsheets, each covering different areas of the specification.  Furthermore, there was the added complication that those involved with generating and reviewing the specifications were spread around the globe.  Once I had grasped the size of the task, and being a somewhat structured engineer (I think!), I needed to come up with a solution that would support the management of this mass of information that would work in the environment.

Without going into more detail about the scale of the task it became clear that the first job was to move away from spreadsheets – the tool of choice for the other product managers and engineers.  Why – its pretty difficult, if not impossible, to manage traceability with spreadsheets. So there were many questions – for example:

  • What are the short-term and long-term needs?  i.e. do we have the option to build a system and would that make sense?
  • What options do we have?
  • Would any of the alternatives be acceptable to the team involved?
  • What about out interactions with 3rd parties – how did they manage their specifications and most importantly provide us with feedback in the manner that we need?
  • ….

When I’d had a few days to think about the task it become clear to me that our work was really a design activity and hence so much more than consolidating requirements from each party with their own area of interest.  So with that idea in mind I had a few conversations with informed sources and was introduced to a range of potential tools, most of which scared me due to their complexity (high learning curve), restrictive, cost… until I told about EA and took a look.

With EA, here was a tool that offered a straightforward interface to a database that I was sure could be used by those familiar with office and simple drawing tools could use.  If I could capture the information in the spreadsheets into an EA model and iteratively build the relevant relationships I was onto a winner.

Well without going into the whole story (perhaps in a future post) I was able to convince the team and even though most of them had no knowledge of UML give them enough guidance so that we moved from the spreadsheet approach to structured model contain objects and their relationships.

Needless to say we still had to support spreadsheets and their import/export as they were used in the review process as well as by 3rd parties, and so the ability to do this, albeit with some coding, meant that EA provided the flexible solution that was needed.

Since then I have continued to use EA for any task where I needed to maintain information(objects) and the relationships between them as well as the more traditional UML design jobs.  Not a purists approach but as I like to think about myself a pragmatic perfectionist – if that makes sense; at least it has helped increased the time to spend doing the important stuff.

So 10+ years on EA is a much more powerful tool with much more functionality and I’m now inspired to explore more of its capabilities. So read my post on Why this site?