Messages

1

General Board / Re: Anyone know of a Business Analyst community?

« on: October 15, 2002, 11:28:54 pm »

You'll get over the rash once you break the itch/scratch cycle!

You also try www.brcommunity.com which is the business rules community.

2

General Board / Re: Anyone know of a Business Analyst community?

« on: October 11, 2002, 08:10:06 am »

Although it's not business analysis it may be worth looking at...

http://groups.yahoo.com/group/dm-discuss/

The group is very active and may have some topics that are of interest, the topics listed in the group description are...

"Business Rules * Data Administration * Data Management * Data Mining * Data Model Patterns * Data Modeling * Data Quality * Data Warehouses * Database Administration * Database Design * Enterprise Architecture * Enterprise Models * Extensible Markup Language (XML) * Information Management * Intellectual Capital * Internet * Intranet * Knowledge Discovery * Knowledge Management * Meta Data * Object Orientation * Repositories * Unified Modeling Language (UML) * Universal Data Models"

3

General Board / Re: Bugs in EA

« on: July 05, 2002, 08:41:52 am »

Having used several "main stream" modelling tools, my subjective impression is that there have been less bugs in EA than others.  The response when a bug is found and to new features is exceptional, as is the rate of improvement of product capability.  I find it hard to believe that this would  have been sustained for the length of time it has been if the underlying structure of the code was poor or the quality of testing was poor.

We have copies of other vendors tools on our machines that are 20 times the price of EA.  We are so frustrated with their lack of functionality and poor support that only use them if a client insists.

4

General Board / Re: UML 1.4

« on: February 22, 2002, 09:58:09 am »

Keeping both EAP files and executables in line is basic configuration management.  The EAP files are development artefacts just as code is and should be under CM.  The operational environment, eg the development toolset, should be managed too using standard deployment tools.  There is an art to getting the balance between the level of control needed to ensure that the toolset is stable and giving developers the freedom to develop productively.

5

General Board / Re: UML 1.4

« on: February 21, 2002, 02:03:17 am »

Rusty

I agree in principle with what you say.

However, I think there are more important battles to fight than standards especially in large organisations. For example, getting people to talk one another is more important than using tools, using any tool is more important than using a specific tool, productivity and quality are more improtant than standards.  All these are interrelated but we need get the priorities right and deliver better long term value to the organisations that we work for.  While we discuss standards, someone has just won the business argument with Powerpoint!

Regarding the product, working towards the standards as they emerge is good enough for me.  But, I want speed and flexibility first so that I can get on with the job rather than fight the tool.  The story that EA has to tell is much bigger and better than the tired old standards arguments.

I also want EA to sell well so that the product can continue to grow.  On this point, standards may be important.  Maybe, others with experience of corporate procurement could give their twopenn'eth.

6

General Board / Re: UML 1.4

« on: February 16, 2002, 06:47:01 am »

I now run an architecture and strategy consultancy, previously I was Head of Architecture at 2 FTSE 100 companies.  Both as a consultant and as an architecture manager, I have evaluated CASE tools.

Standards add value through consistency which aids learning and communication, and allows tools to communicate.  EA has both these aspects covered.

In reality, beyond this the question of standards is (and should be) low on the list of priorities.  The level of coverage in EA, Geoffrey's statement of intent and his record of delivery will satisfy most architecture managers.

EA is, in my judgement, significantly more productive than the other tools that I have used, its functionality is more accessible, and at about 5% of the price of the competition it is a no brainer to buy.

I guess the problems are likely to lie with some methods managers.  Development and architecture managers should be swayed by the practical issues of delivering the right systems faster and to higher quality.  This is where EA scores and is where an evaluation should focus.

7

General Board / Re: Cost-benefit analysis of EA

« on: February 21, 2002, 01:40:44 pm »

Look at ...

Ease of learning
Ease of use
Speed of use
Flexibility eg extensions into requirements modelling, project management
Interoperability eg import/export, APIs
Quality of support
Responsiveness to enhancement requests
Responsiveness to faults
Product architecture
User forums
Documentation
Training
Consultancy
Standards compliance
Integration with other tools

IMHO, EA wins on most of these but not all.  Its important that you work out what is important and why.

8

General Board / Re: Issues Issues

« on: February 22, 2002, 08:15:55 am »

Reporting is something I'm very interested in.  In particular, "what affects" and "what is affected by" impact analysis reports eg if a requirements object is changed, which use cases, which classes, etc are affected?  In reverse, this is ... if I change a class, who do I need to tell ... this may be other developers or it may be users who requested a requirement.

The need here is to be able to selectively follow any type of relationship between any types of model object.