Why would you want to write an EA Add-In?

I was thinking about the point I made in my previous post that Add-Ins may not be the right solution and, depending on what you are doing there may be some better options.  However, you may be curious and just want to have a go – a bit like me.  So in the spirit of exploration you follow some instructions for writing a simple EA Add-In, and hopefully get it working OK.

However, apart from trivial examples, writing an Add-In is not a small undertaking. So just before you dive into spending your time learning more about the techniques of writing Add-Ins, assuming that they will be the solution, I think it’s a good idea to reflect on why you think you need an Add-In, and in assess whether it make sense in your case.

If you are looking at writing an Add-In I would suggest that you probably fall into one of the following categories or something very similar:

  • You are an EA user and frustrated that the little bit of functionality you want is not provided
  • You are an EA user who needs EA to interact with other tools on a regular basis, for example to transfer data between them either to make your life easier or to enable you to use EA for a specific project or in a specific environment
  • You are a product developer and see that there is an opportunity to enhance EA to provide functionality that isn’t provided or is only available in a way that you don’t like, and think others would benefit from a different solution i.e. your solution
  • You are a product developer and you need to enhance EA to work with your other products to improve your customers experience

If I look at these requirements and focus on what you may want:

  • To integrate with other tools – e.g. to transfer information on a frequent basis
  • To harvest content from existing sources and want a customised solution
  • To customise the outputs from EA that cannot be done with the exist reporting tools or via a route that meets your reporting requirements/processes
  • The flexibility that you cannot get through other solutions e.g. scripting or existing Add-Ins
  • To provide interfaces to EA in a way that is not currently available – for example, you may wish to provide access to a limited set of data or need to perform integrity checks on data entry

So using these lists of requirements I’ll share some of my thoughts gained from my experience as an EA user, manager of EA Users, and EA Add-In developer; a bit of a check list. 

Although I have broken them down into different topics, many of these points are not independent, so need to be considered together, and probably with several iterations, before a decision is made. Needless to say the larger number of people involved or influencing your decision, the more challenging it will be. So here they are, with the caveat that I know I haven’t thought of everything – this is just the starter list, and I am sure that every situation will have its unique issues:

Are you sure that EA doesn’t already provide the solution? 

You may be surprised with this question, but the point I am making is that Sparx Systems have been doing a great job of adding lots of functionality and sometimes knowledge of this functionality is hidden.   I’m still discovering – it’s frustrating to find a new feature after having spent time sorting out a workaround so:

  • Before you go off and develop your own solution it may be worth checking the latest documentation or contacting Sparx support with your specific problems, as there may already be a solution
  • Raise a question on the support forum to see if anybody else is aware of a suitable solution
  • May also be worth checking if there are existing 3rd party Add-Ins

Of course, it may be that any solution you find does not meet your specific requirements but always worth a quick check.

Will one of the other automation solutions work?

If a suitable Add-In doesn’t exist you should consider if you need an Add-In.  Do you need to respond to EA events – if not then would some of the scripting capabilities within EA work,  or would the use of a scripting language such as VBA within the application you may be working with provide an adequate and possibly quicker solution to meet you immediate need?

One of the first tasks I had with EA such a long time ago was to provide capability with Excel to interact with EA.  This was all done with VBA .  Needless to say I think eaXL is a better solution but it can be done.

What support do you have for your proposed solution?

Depending on your situation, it may be that it’s your decision, but as soon as others are involved, either for approvals to proceed or perhaps more importantly as the potential users of your solution, then you need to consider:

  • Do you have established EA users who have a positive attitude towards EA?  Have you got them on side? or if not then you may be adding fuel to the fire! 
  • They may not like a solution being imposed upon them. Your solution may mean that they have to change the way they work – would they be happy with this? They may say they are, but how can you confirm that this really is the case?
  • And are you clear you have identified their specific needs? How can they or should they be involved to ensure that they take some ownership of producing the solution.

What functionality do you really really need?

You may have a vision for an elegant solution in mind but it may not what is needed to solve your current problem, in fact over specification make mean that it is a non-runner.

  • Can you produce a list of must haves vs nice-to-haves?
  • Can you further prioritise the requirements?
  • What is the impact of not getting all of your “must haves”? i.e. how “must have” are they really  – is it you or the problem specifying them
  • Is there a clear (and dare I say costed justification for each requirement) – really useful if others are pushing for requirements that you think are not needed!

Who will be the users of your Add-In?

The approach and choice of solution can vary significantly depending on whether this is a one-off need for a single user or for a wide range of users in different roles.

  • For a one-off use for a single user an Add-In may not be suitable or justified – either in time or just excessive – unless it can be a quick and easy “bodge” to an existing Add-In.
  • For the multi-role, multi-user solution the Add-In approach may prove useful in that the interface can, since it is under your control, be tailored to provide the level of guidance and protection you need.

When do you need the solution?

If you need it instantly you better re-calibrate and assess what would be a realistic expectation for the availability of an Add-In that you haven’t specified or started writing and then review the suitability of the proposed solution. If you really need it now what other options do you have:

Is there an existing Add-In or combination of products that could provide the solution, it may not be as elegant, but probably available much sooner. You may be in an environment where the long term solution would be an Add-In but you can provide a shorter term solution another way.

Although having written quite a few Add-Ins and could produce a simple Add-In within a few days or weeks depending on the functionality, integration etc, it really takes much longer to deliver a production quality product. So be careful about the quick fix – it may work but does it really do all you need.

Who is going to develop the Add-In?

If you are reading this it may be that you are a first time developer looking to produce the Add-In – Good on you, however whoever is doing the development it is worth checking their skills and experience.

  • Do they have the experience of developing the Add-In
  • Do they have experience of any other elements that are involved with the proposed Add-In whether this be other applications or services – in my experience this can be a bit of a learning curve (great fun but can take time)
  • If other tools / products are involved have you done an assessment of their suitability for the task that you expect them to perform.  For example the ability to programmatically interface with them e.g. are they are COM server, etc? and if you don’t know how will you find out? What experience do the developers have of these other tools?

Who is going to support and maintain the solution?

It’s all well and good producing an Add-In, but how long will the Add-In be needed and who will be looking after the Add-In. Maintenance is often the highest cost element for any product.

  • Who is going to provide the support? – by which I mean both help users of the Add-In – this can be a very time demanding activity and may not be costed in the project and perform any maintenance tasks that come with the Add-In
  • What support levels are required?
  • Is the Add-In going into daily use?
  • To how many people?
  • Where are their locations?
  • Who is going to do the bug fixes?
  • Who and how are updates to be managed?

How are you going to market your Add-In?

I know this may appear off the point but I just want to say to those who are considering develop Add-Ins as a commercial product you need to think hard and reflect on why you are developing and bringing a product to market. I’ve done it in both small and large organisations. Like me you probably believe that EA is a wonderfully useful tool and if only there was an Add-In to do *%$£*! then it would be so much more useful and everybody would buy the product; they wont!

It can be hard, and if it’s your money then be very careful – get help if you can at least to review your proposal.

  • Have you really identified a need in the market? Creating a need is an expensive and time-consuming business.
  • Have you a business plan? if not….do you know what one is? you need a plan (although in reality it should be name a business guess).
  • What level of confidence do you have in your figures?
  • What is the source of information – I know many figures will be guesses but it is hopefully backed up by some real and reliable research
  • Have you performed what-if cases e.g. reduced sales by 3, increased development/lead times by 3 – does it all still make sense
  • What are your expectations?
  • Can you fund the development?
  • Have you done a detail risk/impact analysis?

Plus a myriad of other points – I’ve created many products and had several start-up businesses in over my career – and not one of them was easy.

Convinced you want to carry on?

You got my starter list to consider if you are thinking about before starting to develop an Add-In.  It may be a no-brainer, you need one and your company will fund it, so you can just get on with it. If not, then perhaps there a few more points to consider.

Whatever the decision I trust that you have a really well thought out and detailed specification before starting.  I tend to start with an EA model as should any good BA – and then start the design … stuff for another day.

I do hope that these thoughts are useful and help you. And if you do have decide to develop an Add-In do have fun writing it.