About eaTeamWorks
After spending much too much time struggling to create the documents our stakeholders needed using the EA RTF generator, we realized an easier answer was needed. So eaDocX was born. The world’s best selling extension for Sparx Systems Enterprise Architect. eaTeamWorks is the next step in the evolution.
Why did we write eaTeamWorks?
It all started with eaDocX.
eaDocX started out as a solution to a very specific EA problem. How to produce 1000+ pages of complicated technical design documentation – Use Cases, Domain models, sequence & state diagrams and architecture descriptions – written by 6 people, for a very smart but critical audience. And produce it in 6 different but overlapping documents, with a new version of each document every other week.
We launched – and eaDocX rapidly became the best selling EA add-in ever.
As well as adding lots of new features, working with customers gave us new ideas, which spawned other products – Model Expert and Portfolio Manager, eaSheets and Revision Manager. Now we had a family of products. But how to make it easy to use them all? The answer? eaTeamWorks.
One download, one installer. All the products, unlocked with individual keys, for maximum convenience and maximum flexibility.
As we are experienced EA users – for both Business Analysis and Architecture/Design – we know what it takes to make EA modeling teams effective and productive. Software that’s useful, simple and comprehensive. So that’s what we’ve built. We hope you enjoy using it.
Meet the team
Ian Mitchell
Business Analyst & eaDocX Developer
I graduated in 1983 from Oxford with a degree in Engineering, which means I could start from Schrödinger’s Wave Equation and prove a wheelbarrow, but couldn’t actually engineer anything.
I started out with IBM – first in their development lab in the UK. As some of the people I worked for were almost 40, this was clearly a job for old people, so I moved over to customer-facing roles building what were then called client-server systems, that were obviously going to take over the world. It’s here that I got interested in how software got built, especially Object Oriented software, which was in its early stages of commercial use.
On one project, I managed a team of 20 Smalltalk programmers – in the days when Smalltalk was cool, and was definitely going to take over the world – and co-wrote a CASE (Computer Aided Software Engineering) tool (ironically) called GOOSE – Graphical Object Oriented Solution to Everything. For this, me and my co-authors shared an IBM “Outstanding Innovation Award”, due to the huge amount of money which the project saved by using the tool. It would be great to say that the tool was then adopted by IBM, and we all went on to become rich and famous, but it didn’t, and we didn’t. It got lost in the internecine wars that are IBM product development, and we all wandered off to do other things. Sigh.
The experience did, however, give me a life-long interest in how engineering-style approaches can be used to create better business applications. Yes – I really am interested in this. (Don’t tell my children though – they already think I’m sad.)
After that I worked for a few years as a consultant and mentor for QA Training, then the UK’s largest – and best – IT training company. I looked after, and was part of, a team of trainers who went out to customer sites to give advice on adopting OO techniques. During this period I worked with dozens of customer projects - Airlines, Insurance, Banking and Government - and saw how the use of a few hours from an independent ‘expert’ could make a big difference to a project. This is why I’m a real fan of the idea of project mentors, who can stop projects from re-inventing ideas which already exist, and giving them a sounding-board for new plans.
At the end of this period, QA produced the first ever UML (Unified Modelling Language) course, and for a while this was the focus of my mentoring work, using a variety of other CASE tools. It’s at this point I started to call myself a Business Analyst. That was 10 or so years ago.
Since then, I’ve been an independent consultant, working as a BA for telecoms companies mostly in the UK, and doing occasional teaching – I wrote a UML course for a client, which I’m still adding-to and using.
It was during one of these projects that I first came across Enterprise Architect. I was the UML-specialist in a small team of BAs, who were writing the Use Cases for a telecoms system. EA was then – and still is – a fraction of the price of competing tools, and has a better user interface. If it doesn’t take over the world, I’ll be very surprised (surprisingly).
Our project also wrote its own document generator, to take the information from our EA model and produce all the documents for the project. Like many EA users have done, this was a series of Word macros, which needed a programmer to make changes, but which showed me the difference which a document generator can make to an EA project.
So, in a gap between projects, I totally re-wrote the initial generator to be an EA add-in, and eaDocX was finally born.
I’m now full-time coding and testing eaTeamWorks, as well as acting as part-time mentor¹ to some telecoms projects, and spend most days listening to BBC 6 Music. The former is proving a timely reminder of my skills as an OO programmer, and why I prefer being a business analyst.
Our hope for eaTeamWorks is that (1) every EA user will buy it - to improve their model quality (Model Expert), edit their data (eaSheets & Revision Manager) and collaborate across projects without errors (Portfolio Manager). Then (2) they’ll forget about it, and concentrate on understanding their businesses, which is a much more interesting problem. Then (3) they’ll press the ‘generate’ button in eaDocX, and get the documents they need.
...and eaTeamWorks will take over the world, and I can go and get a real job making furniture, which is much more interesting than all of the above.
Oh, and somewhere in all that, I got married to Jackie (the Ability Engineering CEO) who is a project manager and a real-life Rocket Scientist, and we have two daughters.
¹Yes- I know this adds-up to more than one job. Just look at the time stamps on my emails to see how this is done...
Jackie Mitchell
Team Rocket Scientist
I studied Physics at Oxford, before starting my career in Space - as a satellite design engineer, then project manager. I loved the technology, out of this world (!) problem solving, engineering design and manufacturing, all of this within a highly regulated and structured environment.
Being part of a multi-disciplinary team and achieving great things was hugely satisfying - even though to get our projects operational, we had to place them on a large complicated firework and light the blue touch paper...
Then an MBA, followed by founding a management training & consulting company. Several years later, back to engineering at Airbus, managing A380 wing structures and components. Again, a highly structured environment where delivery had to conform to rigorous change management and configuration control systems...
Subsequently I moved into telecoms, managing IT and IVR systems developments, contact center infrastructure changes, web platform upgrades, multi channel fulfillment and customer loyalty programs. Implementing new technology and business and organizational changes.
You could say my career has been on a permanently downward trajectory, from interplanetary missions via aircraft at 35,000 feet, to ground level with mobile phones.
But regardless of the altitude, in every case I have needed to understand the technology, the people, the processes, the politics, the business case, the risks, the operations and much more, just to deliver... and keep my stakeholders happy with the information they needed.
I was amazed, on entering IT, to discover how relatively un-structured and uncontrolled so much development was. Compared to my engineering experience, information was often incomplete and usually scattered through various departments, tools and peoples heads. Delivering projects was more an art than a science. Thinking was often unstructured leading to solutions having unexpected consequences.
But then I discovered Enterprise Architect - and how much it could have helped.
EA can hold and connect business and technical information, and eaTeamWorks makes it easy to manipulate and deliver that information accurately and quickly. So I am excited about what eaTeamWorks can do to help teams scale their use of EA, improve their productivity and deliver real business benefits with streamlined governance and project and program management.
I know what hard looks like. I am a rocket scientist! And wherever possible I want an easy life...
EA and eaTeamWorks will make that possible, give us all more time to do things we love (for me, that's more time for rugby (supporting Wales, of course), making music, and a million and one things I haven't quite got around to yet.)