To my readers:
This will be the last Evanetics newsletter. After much consideration, I have decided to pursue a new business model that is totally outside the role of independent software consultant and trainer that I have performed these past 17 years. I want to thank all of you who have followed these newsletters for the past 2 years, and especially those who wrote me, asked wonderful questions, and challenged me to sharpen my own thinking.

Modeling for a Living

by Gary K. Evans

When someone asks me what I do for a living, and I want to have a little fun, I tell them, "I model for a living!" Invariably their eyes will scan me downward, then back up, and they get a very puzzled look. Then I say, "Oh, I model for the before photographs!" Then they get the joke, and we both have a good laugh.

But I do model for a living, just not the photographic kind of modeling. And in this last newsletter I want to share a few ideas that are closest to my passion about software - and modeling is one of my greatest professional passions.

Not only is software modeling one of my favorite activities, it is also one of the most profitable for my clients. Ivar Jacobson, author of the classic Object-Oriented Software Engineering: A Use Case Driven Approach says, "System building is model building". At least, it should be model building, and here are a few of my recommendations why you should very strongly consider serious modeling in your company or project.

Modeling is Collaborative

Well, it should be collaborative, but it is too often an exercise in isolation, which does no one any good. I led a modeling session for a very large manufacturer. When we were setting the goals of the session, the manager asked me how many product managers I would need for the session. My reply was that I wanted one product manager and two engineers from each product group. To my surprise, the teams were not planning to send a mixed group like this. I explained my reasons for why I wanted - even insisted - on both business and technical representatives in the session. They considered my request carefully and agreed. The session was so successful in the fidelity and comparative power of the models we produced that this modeling exercise gained a public notoriety of its own in the company. All I did was get multiple perspectives in the same room for 2 days. Software is a technical solution to a business problem - two sides of the same coin, if you will. Just get both sides together, preferably in front of a very large whiteboard, and build visual models of how each group sees the world: their differences and their commonalities. Then they will learn to appreciate each other's world.

Observe K.I.S.S.

No, I don't mean the KISS principle you might know. My KISS principle is: Keep It Simple...and Succeed. Many of you have heard the quotation attributed to Albert Einstein that, "Everything should be as simple as it is, but not simpler." Simple is good. But simple does not always come easily or effortlessly. Another quotation that you may not have heard is attributed to the French philosopher and mathematician Blaise Pascal: "I have made this letter longer than usual, only because I have not had the time to make it shorter". Pascal understood that simplicity and brevity are of great value, but they require time and effort. When I teach UML Modeling, my students create lots of UML diagrams. After we review the diagrams they produce in their work groups, I show them the "official" answer I provide in the courses. Quite often I hear comments such as, "That is so clear and concise. Why doesn't our diagram look like that?" To which I reply that my diagrams were produced and revised often over several years, rather than just the 45 minutes available to them in the class exercise. I will end with this last quotation that I learned when I studied creative writing many years ago: "Anyone can write, but a professional rewrites...and rewrites...and rewrites". You may have to work very hard to keep your project simple. Modeling is one essential component of project simplicity.

UML is Not the Only Notation

Flowcharts, data models, flow diagrams, UML...it's all good. Any visual representation of ideas can be a huge boost to helping understand and communicate the goals and components of a software project. UML is an industry standard visual notation, but it is not sufficient for all aspects of a software project. UML is strong in many areas, but it is still weak in representing data and data relationships, user interface design, program code, and user interface event flow. Many inexpensive UML modeling tools limit themselves to just the 13 diagrams in UML version 2.X; more expensive tools supplement these 13 diagrams with others. Choose your modeling tool - or tools - carefully. Consider what you need to model, and whether any of it is outside the confines of UML.

Being Common is a Noble Goal

Modeling collaboratively and simply offers your team a common experience, and a common vocabulary, a common understanding of the business entities and relationships, and supports a common vision on your projects. How much are you willing to pay for something like that?

On one of my favorite projects I worked with a very small team to identify the scope of the project in a brief document. We then spent a couple weeks together in a conference room lined with whiteboards. We had development and architecture members on the team, and we brought in Line Of Business experts to explain the appropriate business models, and we modeled, and re-modeled, and re-modeled. At the end of these sessions the manager stunned me when she told me, "I didn't know what I was going to get out of this modeling stuff, but what I got was a team where everyone knew exactly what needed to be done". This was priceless praise. And all we did was make sure everyone had a common experience, with common exposure to the needed information, to achieve a common vision.

Identify Unspecified Requirements and Relationships

One of the great benefits of modeling a business domain is the ability it offers to detect missing requirements. Textual specifications are a fragile form of modeling. As an example, consider the requirements statement, "A bank can have many customers". OK, that's a start, but not a complete specification. Can the bank have zero customers? And - reading this requirement in the opposite direction - How many banks can a customer have?

Visualizing business domain statements in a UML class diagram makes formulating these questions a no-brainer because the visual models must be read and vetted bi-directionally, so you have to think not only Bank-to-Customers, but also Customer-to-Banks. This is almost like free money.

Moving Forward From Here. . .

I hope you will pick up and scan some books on UML or data modeling in a book store, or on-line. In our shaky economy, having new, and better, skills can only be to your benefit and the benefit of your company. For myself, I have been writing a collection of articles on UML modeling that I still hope to complete even as I move into my new career area. Perhaps these will become a book on software modeling. Regardless, I wish each of you good fortune as you move forward in your career, and I sincerely hope that you have found some value in what we have shared in these newsletters.

Best wishes,

    Gary K. Evans