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?