The Community Blog for Business Analysts

David Wright
David Wright

Cascade Day 12 - Principle #10: Models are better than text

#10. Models are better than text.

I would like to think that by this point in time, this principle no longer requires justification. It has been at least a few years since I last saw a dense “SRD” or “SDD” document (SYSTEM REQUIREMENTS DOCUMENT, SYSTEM DESIGN DOCUMENT).  I must offer my respect to the many talented people who labored to produce these documents over the decades; these documents were at least a step up from no Requirements or Design artifacts at all.

Consider what a ‘model’ really is in general; it is a representation of a finished product in a scaled down version; engineers have been literally creating models of what they are going to build for centuries, for such reasons as testing out problems on a small scale, and for presenting a view of the end result to whomever may be paying for it. 

At this point, though, let us abandon any other aspect of physical engineering as an analogy for Information Systems development. Software is different; while tools and bridges and buildings have been created to either extend or protect the physical capabilities of human beings, Information Systems are created to extend the our mental capabilities, to help our thinking.

Given that, software can still be engineered, but it is a different type of Engineering. Software or Information Engineering has existed as a known concept since the 1970’s, although anyone who thought to call themselves a software engineer usually incurred the wrath, or at least disdain, of the established Engineering Disciplines and Schools. I am not an engineer, would not claim to be one, but my understanding is that traditional engineering is addressing software within its disciplines. In the future, as software becomes even more critical to our well-being and safety, it may be that those who design and create software will have to be accredited engineers, just like the ones who design and build bridges. I think history shows that quite a few early bridges and other structures were prone to collapse before engineering principles started to prevent it. Software is only a half-century old, so even in the age of internet speed and high change, more time will be needed to bring software in line with other long time products.

In the meantime, it should be a goal all of us in the IT business to adopt useful aspects of engineering to improve the quality of software, and modeling is a key concept to adopt. It almost frightens me that many still promote programming as an art form, that code can be beautiful or exquisite in some way. Well, even the most obscure art needs an audience to appreciate it, and it can’t just be other artists. Software is a product to be used, not admired, so if anything, programmers of the past 50 years have been more like craftsmen, using individual skills and experience to produce useful ‘objects’ for society to use. The problem is that demand continues to out-strip programmer output (remember the backlog!), so improved, repeatable and transferable methods are needed to transform software development from a craft to a true industry.

This entry was published on Jun 02, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  0 members liked this article

Related Articles

COMMENTS

Only registered users may post comments.


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.



Modern Analyst Blog Latests

Jarett Hailes
Jarett Hailes
As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
2 Responses
Howard Podeswa
Howard Podeswa
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
12 Responses
Adrian M.
Adrian M.
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN
1 Responses
Featured Digital Library Resources 
Copyright 2006-2018 by Modern Analyst Media LLC