HomePage simple models. any drawing tool. shared understanding.

Main / About

Mission of AgileDraw

The primary goal of AgileDraw is to serve as the simplest modeling technique that is pleasingly natural, provides design freedom, requires the most basic tools, promotes modeling creativity, fosters better communication, and complements existing standards. A secondary goal for AgileDraw is to give developers the confidence to do freeform modeling.

Our Group

AgileDraw was founded in March, 2006. This effort is currently evolving with the contributions of many industry thought leaders listed below (click here for details):

Click here to learn about what we are up to and/or have planned.

AgileDraw Principles

AgileDraw adopts and relates to many of the principles of Agile Modeling, by Scott Ambler (http://www.agilemodeling.com/principles.htm). The core principles of AgileDraw are:

  1. Simple: Many complex models can be communicated using a set of simple shapes, connectors and minimal notations. Shapes denote the type of entity, connectors denote the relationships and notations to decorate and add additional constraints and meaning.
  2. Less is more: In many cases, models with large number of artifacts, relationships, and constraints eventually become so complex that most of developers simply refuse to use them. Furthermore, as software changes, it is hard to update the models. Keeping the models light and clean is an effective way to manage complexity.
  3. Light-weight tools: Modeling should not require sophisticated tools and products. An easy to use diagramming tool and a pragmatic approach where the team can collaborate, exchange and modify the models is all you need. (See http://www.agilemodeling.com/essays/simpleTools.htm)
  4. Easy to understand: AgileDraw maintains its simplicity by using an intuitive approach to modeling that also makes it easy for users to understand the design and concepts behind the model.

The Rationale For AgileDraw

The last thing we need is yet another technique or standard, particularly when it has taken so long to define a common standard such as the Unified Modeling Language (UML). However, as you will see from reading this page, AgileDraw works exceptionally well for high-level conceptual modeling, marketing your ideas to others, or as a precursor to UML, test-driven development, and/or other methods. The beauty of AgileDraw diagrams is that these can be drawn using almost any presentation/drawing tool (e.g. PowerPoint, Visio, OpenOffice.org).

Rationale Behind Modeling

  • "Models provide abstractions of a physical system that allow engineers to reason about that system by ignoring extraneous details while focusing on relevant ones" 1
  • "Because many aspects of a system might be of interest, you can use various modeling concepts and notations to highlight one or more particular perspectives, or views, of that system, depending on what is relevant at any point in time" 1
  • "Models help people understand and communicate complex ideas. Many different kinds of elements can be modeled, depending on the context. These offer different views of the world that must ultimately be reconciled." 1

(Click here to read the full article, titled An introduction to Model Driven Architecture by Alan Brown, IBM staff, 17 Feb 2004)

Playing Devil's Advocate: Answering Hard Questions First!

Questions

  • Is there even a real need/problem to address? Or, are we reinventing the wheel?
  • Deja vu? Is this the 80-90s all over? (battle of methodologies and notations.)
  • Do people love existing standards (e.g. UML) already that they don't want another technique?
  • Is this the most ridiculous idea you have seen?
  • Do we ride the Agile momentum and call this AgileDraw? Or, make it independent?

Answers

AgileDraw does not reinvent the wheel. Here is why.

Giving Credit Where It Is Due

AgileDraw doesn't introduce any new concepts, rather it builds on and/or complements the following methods and philosophies:

Complementary To Other Methods ("drawing" on years of work)

The following sections look how AgileDraw will leverage existing standards (e.g. UML) and methods from the past (e.g. Coad, Yourdan, DeMarco, Martin) to avoid reinventing the wheel while leveraging years of work already done. Of course, AgileDraw looks to the future by aligning itself with the Agile Manifesto and the more further out philosophies such as OMG's MDA.

The AgileDraw and UML Harmony

The following reflect our thoughts on the Unified Modeling Language (UML):

  • UML For Forward/Reverse Engineering - UML is a useful technique for low-level, physical design details on the front-end of a project (i.e. forward engineering). It is also good for reverse engineering class diagrams. However, it doesn't work well for conceptual modeling (e.g. informal and quick design sessions on the whiteboard or paper) and you cannot really communicate effectively with a customer using UML diagrams.

  • UML Not Meant For "Marketecture" Diagrams - UML diagrams tend to be very low-level technical diagrams. In short, they cannot be used to wow people! For example, you might want to market your work to your peers (e.g. sell your idea), customers, upper management, websites, white papers, etc.

  • UML Usage – The following global poll, http://visualpatterns.com/polls.jsp, reflects that only 2 to 3 UML diagrams are typically used (of the 13) – note, various user groups from around the world participated in this poll (800+ votes as of April 5th, 2006).

  • UML Is Notation Driven - UML is somewhat notation-heavy for designing applications at a conceptual level or discussions with business users. Often developer get caught up in perfect UML diagrams instead of focusing on the content or shared communication.

  • MDA Could Go Somewhere - MDA/UML needs to work things out on its own; either MDA will be CASE tools from the 80s all over again (Part 2, the sequel) or it'll be our future; after all, we did go from punch cards to assembly to C to Java (VM), so anything is possible!

  • Simplistic Elegance! – Many developers dislike launching and using, typically heavy-weight, UML tools! They prefer using simpler tools such as PowerPoint, Visio, OpenOffice, etc. Like Kent Beck writes in Extreme Programming Explained (2nd Edition), "What is the simplest thing that could possibly work?"; or Scott W. Ambler writes on agilemodeling.com, "your goal is to build a shared understanding, it isn't to write detailed documentation." Furthermore, freeform diagrams can be visually appealing and virtually notation-free since they focus on the content and not the notation or tools.

Having said all this, UML definitely has a place and we are glad it is there; after all, it took years of notation and methodology war to come up with a good, common standard -- this is forward progress. We also feel that OMG's MDA is a wonderful idea that could actually take off (we hope it does). We just do not feel UML is good for freeform designing.

In summary, AgileDraw fills a gap, that is, higher, conceptual and "marketing" modeling and also complements UML, as demonstrated in this table.

Activity Level Best Technique Examples
Discovering business concepts/objectsConceptualAgileDrawDomain model
High-level architectureConceptualAgileDrawFree-form architecture
Explore high-level designConceptualAgileDrawProof-of-concept, key classes, etc.
ImplementationPhysicalUMLDetailed class diagrams for object and replacement for ER diagrams
Reverse engineeringPhysicalUML Get instant idea of system (e.g. blueprint)
Continuous software construction snapshot (a new idea; whitepaper/essay on the way)PhysicalUMLAutomated reverse engineering.

Alignment with Agile Manifesto

Principles From agilemanifesto.org How AgileDraw Aligns
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.AgileDraw chooses the simplest form of diagrams which users can relate to and marketing departments can use.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.Given the simplicity of AgileDraw, it is easier and more pleasant to either maintain diagrams or simply throw them away and recreate if needed.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.Instead of wasting time with big up front design (BDUF), you can use AgileDraw to get a shared understanding and move on to coding quickly and delivering frequently.
Business people and developers must work together daily throughout the project.Precisely! This is exactly why AgileDraw is diagramming technique targeted towards higher level conceptual and business use.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.I honestly believe if you give someone UML tools to diagram versus using simple tools with a free-form, fun and colorful approach, they might be a bit more motivated.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.AgileDraw doesn't get in the way by introducing confusing notations. The concepts behind AgileDraw are the bare minimum to do basic sketching and high-level diagramming that all stakeholders can relate to.
Working software is the primary measure of progress.Exactly! This is one of the values behind AgileDraw that code (working software) is the best source of progress and documentation (e.g. by using reverse engineering to generate pretty UML diagrams).
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.Constant pace is about iterative development in short iterations (e.g. 1 to 3 weeks). Since minimal design is done at the beginning of each iteration, having an agile modeling technique comes in handy and keeps the pace of the project constantly moving without slowing it down with cumbersome tools and complex, un-maintainable diagrams.
Continuous attention to technical excellence and good design enhances agility.Good design from refactoring on a daily basis. Agile draw helps with some minimal sketch work on the whiteboard, for example. Technical excellence comes from focusing on what matters (the code) and delivering a solid product each time while supporting the customer, not getting bogged down in complex diagramming notations and overkill processes.
Simplicity--the art of maximizing the amount of work not done--is essential.Simplicity is what Agile draw is all about!
The best architectures, requirements, and designs emerge from self-organizing teams.Self-organizing teams often work as groups, brain-storming around a whiteboard in a conference room or notepad in a cafeteria, having a simple sketching technique such as Agile draw is key.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.Agile draw can be used to free-form sketching to see if how to improve on previous architecture, design or more.

A Tribute To the Past

Many brilliant software engineers and methodologists paved the path for us by introducing innovative ideas that lead us to this point, some of these include:

  • Grady Booch
  • Peter Chen
  • Edward Yourdon
  • Peter Coad
  • Tom DeMarco
  • James Martin and O'Dell
  • James Rumbaugh
  • Nassi-Schneiderman (N-S) diagrams

Agile draw plans to borrow concepts from some of the above methods. At the very least, we will study the above techniques to learn from them.

Alignment With OMG's Model-Driven Architecture (MDA)

If the MDA vision every becomes a reality (I hope it does but I'm skeptical), AgileDraw will continue to compliment it since AgileDraw is about conceptual modeling (e.g. on the whiteboard) and it helps to grasp some high-level concepts before jumping on the computer to begin architecting/designing with the MDA.


source: http://www-128.ibm.com/developerworks/rational/library/3100.html

Alignment With Agile Modeling (Scott W. Ambler, agilemodeling.com)

The following excerpts from Agile Modeling and Agile Model Driven Development (AMDD), were taken into consideration for AgileDraw. Furthermore, AgileDraw works particularly well during AMDD's initiial modeling efforts and/or model storming.

Alignment With Extreme Programming (XP; extremeprogramming.org)

As discussed in under When/Where To Use AgileDraw, AgileDraw works perfectly with the XP approach of Test-Driven Development (TDD) and/or prove it with code.

Alignment With High-Assurance Design (Clifford Berg, assuredbydesign.com)

AgileDraw provides guidelines for use of colors and/or domain specific icons (see learn it page; using these techniques, high-risk and/or high-availability components of a software application can be highlighted using colors and special icons in AgileDraw style models based on the recommendations provided in Cliff Berg's book.

Spreading The Word About AgileDraw

If you would like to spread the word about AgileDraw, here are some suggestions:

  • Tell a friend
  • Discuss in online groups (e.g. Yahoo)
  • Present this technique to user groups, conferences, and so on.
  • Write articles around this combining it with Agile methods/processes

Main / About
© Visual Patterns, Inc. All rights reserved.