Five Reasons Why You Need More Than Visio and PowerPoint to do Real Architecture Modeling

Top 5 Reasons

Visualization is any technique for creating images, diagrams, or animations to communicate a message.  Humans have been creating visualizations since the cave paintings of prehistoric times. Have we evolved or, as Enterprise Architects, are we still just creating artwork to hang on the wall?

In software and system development, the equivalent of cave paintings are drawings on a chalkboard, some of the boards so big they required ladders to access it all.  There is even a picture circulating on the internet, suggesting it is NASA scientists planning orbits before PowerPoint.  It is disturbing that someone felt the need to fake a picture like this, and even more disturbing that they felt PowerPoint would have been an acceptable tool for doing this kind of engineering work. 

Office tools like PowerPoint and Visio have their place in supporting business conversations, but they are not the right tools for doing real architecture and engineering work.  Architecture professionals need the right modeling tools to do their jobs effectively. Many organizations start with Visio or PowerPoint as diagramming tools but realize the need a true modeling platform like Sparx Systems Enterprise Architect (EA).  The following are five reasons why you need more than Visio or Point to do “real” architecture work.

Data Consistency

Using Visio or PowerPoint, it is nearly impossible to maintain consistency in model elements when multiple diagrams are describing the system being developed.  For example, are these three elements intended to be the same thing?

data consistency - enterprise architecture

Each time an element needs to appear on a diagram, it becomes a new element.  Even if it is cut and pasted from another diagram, the possibility that there will be a divergence in the description of the two items is high.  In addition, Visio does not understand UML or other modeling languages, therefore, a developer can create diagrams that do not make any sense with relationships that violate the language rules. 

In EA, an element is created once and reused on as many diagrams as necessary.  If it is changed in the model for any reason, it is automatically changed on every diagram in which it appears.  Typos can be corrected, or attributes can be added one time, and all the places where the element is used are up to date without any searching or manual intervention on the modelers part.  Like Visio, developers can create diagrams that violate language rules in EA, but along the way, EA provides guidance as to what is correct. Assuming the language rules weren’t being bent for a specific purpose, validation rules can help determine where the violations are.

Teamwork

Visio and PowerPoint are file-based tools.  As such, they don’t support multiple users working on the same set of diagrams at the same time.  If the development team consists of more than one developer, then they each need their own copy of the file to work concurrently.  If the team decides to keep everything in a single file, then only one person can work on the diagrams at a time.  In either of those scenarios, project productivity is reduced. 

Enterprise Architecture

When there is a single file being updated, then there is the potential for developers waiting their turn or worse yet, guessing about the changes that are in-work and causing unnecessary rework. When there are multiple files in flight, then at some point, they must be brought back together and reviewed to ensure they are not only aligned but are complete and coherent.  Working in EA such alignment and coherence is almost a side effect of building the model because micro-reviews are happening each time the model is extended.  EA models use a database repository. Multiple developers can work concurrently and never have to guess about the current status of the model.  They just have to look at it.

Searchability

A file-based product like Visio can’t provide the search capability that EA can.  As any model grows in size and complexity, developers need to be able to create focused searches to locate elements.  In EA, you can search for things based on the element name as you might in Visio, but there is a long list of means to focus or filter a search.  For example, you can limit searches to an element property or a particular element type.  Again, the ability to focus a search increases productivity over global search mechanisms.  In addition to focusing your searches, EA provides the ability to organize them in several ways to make it easier to review all of the search responses.

Integration

As a modeling tool, EA anticipates the need to collaborate and integrate with other types of development tools.  When I draw a rectangle in Visio, the tool doesn’t know if I intend that rectangle to represent a requirement, or a class, or an interface.  EA, on the other hand, not only knows the difference but understands that I may need to import or export those elements for processing or management by other types of tools in the development tool chain.  EA has integrations with multiple types of version control tools, along with the ability to import elements from legacy and office tools using various file formats such as CSV and XML.

Automation

When you are working with EA, you are creating a model and not just a set of disconnected drawings. That provides you with many opportunities for automating parts of the development. EA has an open API and a built-in scripting capability that can be used to automate common tasks related to process or construction.  For example, if your process requires that every requirement is traced to the class or component where that requirement is satisfied, you could examine each requirement to verify that part of the process.  Or, you could execute a script against the relevant part of the model that returns a list of requirements for which the satisfies relationship doesn’t exist. 

Automation in enterprise architecture

In building your model, there will be times when creating relationships between sets of elements is necessary.  A simple script can be written that creates the relationships and makes them visible on a diagram.  Automation doesn’t end at scripting.  EA also has the capability to execute behavioral descriptions, like activity, sequence, and state machine diagrams.  The automation of the model serves as a means to verify and validate your work.

A diagram created in Visio or PowerPoint is a visualization of some concept.  But that concept is in someone’s head and has no formal foundation.  A model, such as you can build in EA, has a foundation in a set of semantic definitions and diagrams are views of the modeled concepts. We are not cavemen creating paintings on a cave wall.  We are not here to create corporate artwork to decorate our offices.  Architects are here to help organizations explain how complex systems and processes work and to help leaders understand what needs to change in order to achieve some sort of goal.  For Architects to be successful in this charter, they need to have the right set of modeling tools, and the world’s leading architecture modeling tool is Sparx Systems Enterprise Architect.

If you need to upgrade the tools your architects use or upgrade their skills and productivity, Sparx Services North America is here to help.  Contact us, and we’d be happy to talk with you about your unique needs. Together, we can help your architects create more value for your organization. 

Summary:

Five Reasons Why You Need More Than Visio and PowerPoint to do Real Architecture Modeling

Office tools like PowerPoint and Visio have their place in supporting business conversations, but they are not the right tools for doing real architecture and engineering work. Architecture professionals need the right modeling tools to do their jobs effectively. Many organizations start with Visio or PowerPoint as diagramming tools but realize the need a true modeling platform like Sparx Systems Enterprise Architect (EA). The following are five reasons why you need more than Visio or Point to do “real” architecture work. 1. Data Consistency 2. Teamwork 3. Searchability 4. Integration 5. Automation.

Share on facebook
Share on twitter
Share on linkedin
J.D. Baker

J.D. Baker

J.D. Baker is a Software/Systems Engineer with interest and expertise in enterprise architecture, requirements development, software/system architecture and system design processes and methodologies that support Model-Based Engineering. He has used UML as a leader of development teams since 1999 and Sparx Systems Enterprise Architect since 2001. He provides training and mentoring in software and system architecture, systems engineering, software development, iterative/agile development, object-oriented analysis and design, the Unified Modeling Language (UML), the UML Profile for Systems Engineering (SysML), use case driven requirements, and process improvement. He is an elected member of the Architecture Board at the OMG. He has participated in the development of UML, OMG SysML, the UML Profile for BPMN Processes and the UML Profile for DoDAF and MODAF. J.D. holds many industry certifications, including OMG Certified System Modeling Professional (OCSMP), OMG Certified UML Professional (OCUP), Sun Certified Java Programmer, and he holds certificates as an SEI Software Architecture Professional and ATAM Evaluator.