Category Archives: Manager

Information for those working on a project which is using EA (or may use EA) and needs to understand what it can offer and its benefits

eaForms – an element properties editor which can extend and enhance the EA experience

For the last few months I’ve been developing an EA Add-In which has taken longer than originally planned, hence my lack of time for other experiments.  As the project unfolded, we discovered more, expanded the idea, added more features (scope creep!), and then a few redesigns of the UI to provide users options. And even now we still have more ideas to explore.

All in all its taken a few months longer than planned.  I suppose I should believe my rule of thumb which is, when asked by a project manager how long will something take to do – take your first estimate and multiply the time by PI (3.14159265359….   – perhaps not to that level of precision!), and its the number you don’t want to believe, as it could well put you off starting the project at all.

So 2 months becomes 6 and I am now nearing the end of completing the initial phase of this new Add-In – eaForms.  I  had expected to be where I am now before my summer break in July, but instead spent much of my break coding albeit in the sun and must admit it was fun – especially learning more about what you can / can’t do with EA all the time.   I have lots of material from my discoveries for some posts on writing Add-Ins – hopefully I’ve get some time to write up soon.

So what is eaForms – simply it’s an Add-in that allows users to design and run alternative element properties editors.

The idea came from my work in trying to capture knowledge from people who had no knowledge (or interest) in modelling and when pushed to found EA too techie to use.  This led to confusion, frustration and often a bit of a mess for your’s truly to sort out. So why can’t they have something that is a bit more accessible.  They may still have to use EA and so accept that they will be using a modelling tool.  Also there is no getting away from them needing some training to cover the basics plus monitoring afterwards, but at least I could make life a little easier by removing some of the complexity for data entry/editing.  In addition, in doing this I could also help drive consistency by, for example, providing them with a defined set of values instead of a free form text box etc…  less mess for me:-)

eaForms operates in 2 modes:

In Designer mode – the EA user can configure a form, using the eaForms toolbox,  to produce a form that will be displayed for a specific Element type/stereotype combination (support is included for both core element as well as MDGs that are enabled at design time). The content, layout and appearance of this is up to the designer.  The form designer is free to produce forms of different shapes, sizes, colours and perhaps more importantly content using “controls” that go beyond that provided by the standard EA dialogs.  For example:-

  • Combobox (with options for user defined values, to restrict users selections)
  • Checkbox – to provide that quick “yes/no”, “true/false”, as well as other booleans
  • Related elements – with the ability to link to one or more other elements without dropping the current editing context
  • Listviews that display collections with some options to edit items in the list, once again without dropping the current editing context.

Plus built into the design is the ability to add further “gadgets” that as the need is identified.

As an example – here is the basic design of an eaForms in EA – drawn using EA’s drawing tools on an eaForms diagram


In User mode – the EA user, assuming eaForms is enabled, need do nothing.  When they edit an element for which there is a matching form available eaForms will present this instead of EA presenting its standard dialog – below is a screenshot for the form design above:


All in all no real magic but pretty useful.

Of course, for the experienced EA user the benefits are different.  They can produce forms that help them by bringing information together in a single place in the way that they want (I do this for classes, where I have a single form with the class information, its attributes and operations). And bearing in mind it only takes a few minutes to produce a form it can be time well spent, of course, for the artistic it’s easy to spend more time enhancing the look of the form!

Although we think this is a great tool it is important to remember eaForms is just another tool in the EA toolbox. It is an Add-In that can extend and enhance the users’ experience. Using EA still requires guidance from those responsible for the models. Our aim with eaForms is to help in making EA more accessible, reducing some barriers and helping ensure data consistency. Not for everybody but useful to the many.

We have more ideas on where we could go with eaForms and could just continue developing but probably better to let you play (and hopefully provide feedback).

We plan to start trialing eaForms soon – so watch this space.  In the meantime we have started with some short videos that demonstrate the product and its use which you can find on YouTube Channel.

Be back soon.



Simplifying the Element Properties Editor to make EA more accessible

For those presented with Enterprise Architect (EA) for the first time I can imagine that they could well be pretty confused, unless they have been introduced to EA with training that is tailored to their specific needs.  They need to be taught to ignore all the stuff that can get in their way by guiding them carefully in a structured way.

Like many tools rich functionality often comes at a cost, such as lots of menus and options which don’t add value to those users focusing on a single task area.

Many tools start life to address a small number of problems and, with a limited view of the world into which they will be deployed, no doubt strongly influenced by the developers own background. As the tool develops,  new requirements drive their expansion but in doing so it carries with it the baggage of history.  This is not a criticism but an observation.

This is a challenge for any tools developer. The ability to produce a product that meets the wide range of the users requirements, whilst ensuring that the product is accessible and usable. And this only becomes more challenging with time as users ask for more.

We know that over the last decade EA has grown in many different directions, with a large number of features and a high  degree of flexibility.  And it must be pretty rare for anybody to want all of them – in any case a steep learning curve; I’m still learning having used EA for a long time hence this site!

So if say you are Business Analyst(BA) without a strong technical background or tools background where do you start. I know from experience that introducing the tool to new users who have never used modelling tools before it can be confusing and there is a degree of resistance since they already have a solution be in Word, Excel or just a piece of paper.

If the new user is able to adopt a positive approach, we introduce them to diagrams and its toolboxes and then a few elements and so all is fine until they see the Element Properties editor and then a few questions are usually asked:

  • Why all this information?
  • What does this mean?
  • What do I fill in here?
  • That isn’t relevant at this stage of the project?
  • Can I only view the stuff I need?

Now one aspect of EA is that the properties editor is very generic and as such has more items that often needed for the job at hand.  Of course, having a generic editor has the benefits of familiarity across all elements, however for our BA they are unlikely to be doing this other stuff.

So our BA has the task of capturing the initial Use Cases and we want them to be captured in EA, otherwise we will have a further task of importing them and the classic problems with knowledge in multiple tools.  So if we want them to use EA how do we make EA accessible?

It was one of my colleagues who made the suggestion that wouldn’t it be useful to have the option to provide a simplified editor, specific to the element type, which would allow the essential basic information to be input.  And with the option to access the normal detailed property editor as and when needed (if at all). So that’s just what I’ve done.

I’ve started with a Use Case Properties Editor (UCPE), not least as my colleague is a very experienced BA who could provide the requirements.  So when a user double clicks on their newly added Use Case Element in a diagram they are presented with a specific dialog – as illustrated below a screenshot of partially edited form.

EX Use Case Edit Form

Screen shot of simplified Use Case editor

As you can see this form provides the basic information the BA may wish to entry including constraints and Use Case specific attributes, plus there is the option to link to relevant actors in the model – as illustrated in the screenshot below. (Default values for the non-displayed items can be configured so that sensible values are specified.)

Select Actor Dialog

Select actor from tree view of available actors

Edit Actors form

Screen shot of pop-up dialog to allow editing of actor properties

So now rather than deal with the choices of what to fill in on the detailed element properties window a user can use the UCPE, and if needed just press the “Detail” button to switch to the normal EA editor.

This is just the start and other edit forms could be available for other elements, and configured to meet the needs of users working in specific areas. The screenshots are based on my initial test version and this will no doubt grow with new requirements.  If you are interested in these ideas do let me know as it will help me in moving forward with this development.


There is so much more to Tagged Values than I thought

For years I’ve used the tagged values within EA.  However, for some reason I have always assumed that they were just used for strings and a few other basic types for storing numbers.  However,  this is not the case.  As I was reviewing the user guide for some related information the other day, I was surpised but delighted to discover that there is so much more, with support for a much wider range of tagged value types, with some really useful functionality.

Without repeating the detail (that’s in the manual – “Tagged Value Types”) the support for types goes way beyond the basic string, integer and other number formats to much more complex and functionally richer items including:

  • String based items (Directories, Filenames, URLs)
  • Date
  • Selection from Pre-defined reference data e.g. Authors, Phases, Roles
  • Reference to element or elements within the model
  • Checklists
  • Custom Tagged Value types that are defined using a template and can help validate data entry
  • and finally the ability to use an “AddIn” to respond to the tagged value broadcast event and hence provide an open ended ability to interprete what is stored, the actions etc

For these complex types suitable context sensitive dialogues are presented to support the setting of the tagged value.  Furthermore, each of these types can be set to apply to element types and/or stereotypes – the screenshot below illustrates a range of different typed tagged values for an element; in this case a class.

Examples of typed tagged values

Creating tagged values can be done using the “Settings |UML Types | Tagged Value Types” – remember to check the syntax in the user guide for specifying the “Type” , “Values”,  etc – the following screenshot illustrates a tagged value that will reference a Requirement element which has a stereotype “test”.

Creating a new typed tagged value

Typed tagged values can also be created through templates or MDG – so a bit more reading to do on this when I need to use them.

As Tagged Values are stored as reference data they can be exported to /imported from other model. The screenshot below illustrates the menu selections used to export the data –  note that a further dialog will appear where you select “UML Types | Property Types”Menus to export reference data

Now of course with this new knowledge I can immediately think if only I’d known about these before.   In particular, in setting up a model for a project I’ve found it useful to preset tagged values to ensure consistency, and the wider range of types would have been really useful.  Plus the ability to use an AddIn provides a means to “validate” actions, and much more.

Well this new found discovery just highlights how much exists within EA.  And in case you haven’t clocked all this stuff before – check out the user guide section on “Tagged Value Types” – really worth a read!

Its all about Design and Development (and Sharing!)

Recently I was looking at a new project for one of my clients – worth noting in the context of this post that it is a relatively small company. As you would expect the project started with an outline of what was required.  Then as normally happens, at least for me and I’m sure many others, there are a cycle of iterations with clarifications, revisions and new requirements.  Within a few days we had agreed that we both felt that there was a reasonable working specification.

[Note: as I progress through this post I’m going to raise some points as I go i.e. within context!  Point 1 – the nature of the specification is dependent on many factors with one of the most important being the nature of the relationship that exists between the client and their supplier – and this needs to be clear in your mind when you start the process.]

Clearly as part of the process of pulling the specification together I was already looking at how I would produce the required product, looking at the general design approach and what options I had as well as identifying areas of risk and how I could mitigate them.  With this information it was possible for me to put together a proposal that I could discuss (and hopefully agree) with my customer.

[Point 2at the specification stage it was necessary to do some outline design and even some coding to check out a few unknowns!]

Fortunately the client was happy and the project was started.

[Point 3 – it is worth noting that  I found out that the customer used EA to capture their specification which was auto-generated from their model.  So in this process I was able to get a working version of their model and add my own workings into the model and even reverse engineer bits of code I’d used to test a few items to include with the proposal.]

So where am I going with this ..

Well it all started the other day whilst taking my morning coffee in one of my favourite cafés, I was contemplating this new project, and what fun it should be (always good to see the fun in a project), as it not only using stuff with which I was familiar but pushed me into areas where I needed to learn some new stuff. Whilst musing it came to me that at other times when working for or with large organisations, it was all so much harder getting to this point where there was a clear specification and way forward; rather than a few days it could take weeks.

Why – simple answer – “Communication and Understanding”

So what do I mean by this and this is where the answer gets a little more complicated.

  1. Different skills, different interests – In the larger organisation there are groups of people with different skills, different interests and each group/sub-group will have their own agenda (and dare I say non-aligned objectives in their organisations).
  2. Process challenges – Many factors can influence the process, for example –  i) the type of project, ii) who or what is driving the project the specification could be product marketing or engineering  and iii) who is managing the communications between customer/supplier – which can lead to a filtering of information.
  3. Different ways of working – It surprises me that with the availability of tools many continue to use basic word processors and spreadsheets.  Why? i) For many projects there is a need for the different disciplines to interact and share information and this can drive the tools choice.  ii) A lack of knowledge of tools that are available that could meet the need to share documents and in the required digestible forms iii) Not my problem – they abdicate responsibility to an analyst and magically think their information will be captured in an excellent specification.

So what could improve the situation:

  • Having a means for each person to contribute in a way that is natural to them
  • Be able to keep information in a single place AND accessible place
  • Be able to view/review other contributors information

So what are the factors that should be addressed in trying to improve the situation:

  • A lack of context – if I writing a list of requirements I will endeavour to include information that will make it meaningful to the reader. However, there may be readers with differing interests so how can I ensure that I have included the information that is relevant to their needs.  I can’t!  The assumptions I make are based on my view of the world and may not reflect the world of others.
  • A lack of relationships between information – having established that the context may not be complete or satisfactory how can I get a sense of other related stuff that may be able to provide me as a reader with additional clues.  Yes, I could cross-reference materials but that could also be included out of context.
  • No single place for the information – If people need to work together and share information it just makes sense to being able to store the information in a form and format that is accessible to all, with each part understood by the respective parties i.e. the content and its format can be delivered as needed whilst ensuring the integrity of the whole
  • A means to capture and communicate feedback – having established that the form in which I might receive the information is less than ideal how can I provide feedback, potentially in parallel with many others, in a form that is digestible and meaningful the the author/reviewers.
  • Checking that it’s possible– As part of the development of the specification it may be necessary to verify if something is possible, there is little point in putting a specification together that is not feasible, so often worth looking at the specification cycle and the possible inclusion of some validate projects before spending too much!

If I now put my EA hat on I can suggest a tool that can do this stuff, allbeit with some challanges for some classes of user, but work arounds are possible.  For me it has the ability to capture the information on objects and their relationships (much of what we need to produce a specification and more) – providing both visual and textual content, even if some of the user haven’t got a clue what UML is!  It supports team environments (I’ve run global teams without too any issues) and probably most of all information is in a single repository.

I’m also a fan of using Wiki type systems and have used simple systems such as PmWiki as a tool to capture information with links and most importantly they provide a shared repository.  Of course, they don’t provide the range of facilities provided by EA but at least they are an improvement on some of the other approaches!

So the main point I’m leading to is why don’t more people tools that have been made for the task.  Yes, many agree to look at new ways of doing stuff but soon revert to the tools and techniques that they have used for years – and more often than not tools that have not been designed for the job in hand.  Why? Perhaps because nobody is mandating their use – why would they?

Some have and I hope that if I have influenced it there has been a positive outcome, whether measured in increased efficiency, the shear fact that it made the task possible or just makes life easier for the individuals involved.

One of the big challenges I’ve faced in organisations is the way people work, theirs and the organisations resistance to change and the general lack of investment in training on tools that could make significant improvements to the way some of the work is executed.

With my project managers hat on one of our key tasks is to get clarity on what we are trying to achieve.  In doing this we seek to ensure that ALL relevant parties are involved at the optimal time and that their inputs are clearly understood.  The better the information we have the more we can understand the project and hence better manage and mitigate risks to benefit the project.

So where is the incentive (and investment) for deploying tools?  It does happen but there are many more who could benefit.  Needless to say this is not just in the area of producing specifications or similar.

Well, I don’t have the answers but can just reflect on some of the points.  If we go back to why working for the smaller company is often so much easier:

  • It is easier to have a close working relationship with the people that matter
  • The recognise that tools can make their tasks more efficient and increase productivity
  • The management can see the benefit
  • They seek the competitive edge that tools new ways can provide
  • Sharing of information is less of a challenge
  • There is a knowledge base that can be used in the future – if needed.

Then for the larger organisation why don’t these things just happen – possibly it’s just not on the radar of the right people!

Other learnings –  many I’m sure which I’ll reflect on these in the future.

Real point of the post is that we need to review how to produce (and maintain) good specifications… Are we doing it the right way for the project? At least try and learn from potential opportunities.