April 2, 2007

"BOXES AND LINES"

I recently overheard a Business Analyst say there was more to systems architecture than drawing boxes and arrows on a piece of paper. This may be true to a degree, but the ultimate deliverable of any engineering/architectural practice is a set of drawings from which to build a product. Architects and engineers do not spend all of their time drawing diagrams; for example, they have to specify requirements and analyze such things as the stress of components to determine the suitability of materials for use in design. But aside from this, the end result of engineering or architecture, their deliverable, is a set of drawings, be it a blueprint, a floor plan, wiring diagram, plumbing, or a set of flowcharts.

Such drawings basically consist of boxes and lines. Boxes (be it squares, rectangles, polygons, circles, etc.) represent tangible objects and lines represent relationships between such objects. Flowcharts are similar; here, boxes represent specific types of processes or decisions or objects such as inputs/outputs/files, and lines represent dependencies between them (comes from/goes to).

Although drawings typically consist of geometric shapes, it is not uncommon to include tables or indices to represent decisions or to provide a cross-reference. Nonetheless, boxes and lines represent the principal means to visualize and communicate a design regardless of the structure to be built, and have been used since time immemorial.

In addition to diagramming techniques, engineers and architects have found it useful to develop models and prototypes to evaluate the overall physical aspects of their design. These are useful but let us not forget they are all ultimately based on a design of some kind (boxes and lines). From the models and prototypes, designs can be adjusted as required.

I guess what I'm driving at is that despite all of this peripheral activity, and to refute my Business Analyst friend, the principal thrust of the engineer or architect is to produce and maintain a reliable set of drawings. It all comes down to boxes and lines. Interestingly, today's analysts and programmers think drawings are "old-hat" or passé. I don't care whether you draw it with pencil and paper or by computer, documentation is an inherent part of the design process. Failure to recognize this is to deny reality.

In terms of the Information Systems industry, flowcharts have been used for years, well before the introduction of the commercial computer in business. Originally they included process diagrams; later they were used by programmers as a convenient means to document program logic. Such flowcharts typically made use of ANSI standard flowcharting symbols. But as the Structured Programming movement flourished in the late 1970's, ANSI symbols were considered archaic, and many new types of diagramming techniques emerged, including Bubble Diagrams, Data Structure Diagrams, E/R Diagrams, HIPO, VTOC, etc. (anybody remember Nassi-Schneiderman Charts?). I could argue the pros and cons of the various techniques but that is not the point. What is important is that all of these diagramming techniques acknowledged documentation as an inherent part of the design process.

Today, documentation of any kind is considered a taboo (particularly among the Agile Methodology people). Small wonder the IT Industry is experiencing the same type of problems today that we experienced 35 years ago in terms of managing design complexity.

BLUEPRINTING

It is a myth that one type of diagramming technique can be used for all development work. This would be like suggesting to use a wiring diagram to represent a floor plan. Different needs, different graphics, different purposes. There are actually four types of graphics to be used to the different levels of system design. This implies a blueprinting approach with various levels of abstraction, from general to specific. As we have discussed in the past, the "PRIDE"-Information Systems Engineering Methodology (ISEM) looks at a system as a product that can be engineered and manufactured like any other product and, as such, defines four levels of detail in a system's hierarchy:

LEVEL 1
SYSTEM

LEVEL 2
SUB-SYSTEMS (Business Processes)

LEVEL 3
PROCEDURES (Administrative and Computer)

LEVEL 4
PROGRAMS (for Computer Procedures)
OPERATIONS (for Administrative Procedures)

Four different levels, four different graphics used:

LEVEL 1
SYSTEM CONCEPT DIAGRAM - represents a freeform architectural rendering of the overall system.

LEVEL 2
SYSTEM FLOWCHART - defines the SUB-SYSTEMS of the System.

LEVEL 3
SUB-SYSTEM FLOWCHART - defines the PROCEDURES in a Sub-System (aka "Process Diagram").

LEVEL 4
COMPUTER PROCEDURE FLOWCHART - defines the PROGRAMS in a Computer Procedure.

Each level provides the specifications for the next (this is also known as "stepwise refinement"). With the exception of the System Concept Diagram, all of the flowcharts make use of ANSI standard symbols. As to the internal processing logic of a program, since there are many ways to skin a cat, the software structure diagram du jour is used, hopefully a standard one. However, a graphic may not be necessary to express the processing logic of a program. Instead, specifications may be interpreted by a program generator of some kind. Its a "fielder's choice."

CONCLUSION

Until such time as we can master the Vulcan "mind meld," whereby we can transfer knowledge telepathically, there will always be a need for documentation. Its an inherent part of the design process and the principal deliverable produced by engineers and architects. Don't deny it, accept it.

I am definitely not one for excessive documentation thereby becoming a burdensome task. Instead, documentation should be a natural byproduct of the design process. Just as blueprinting is an inherent part of the design process to architects and engineers, so should flowcharting be to system developers. And you shouldn't have to be a rocket scientist to draw a flowchart, keep it simple and try to use standard techniques for consistency instead of reinventing graphics every five minutes. As for me, I have no problem with ANSI standards; it works.

For additional information on graphics in systems design, consult the following sections from the "PRIDE" Methodologies for IRM:

"PRIDE" Flowcharting Symbols

Layered Documentation

Graphics

OUR BRYCE'S LAW OF THE WEEK therefore is... "Documentation is an inherent part of the design process."

"PRIDE" METHODOLOGIES FOR IRM

Friends, the "PRIDE" Methodologies for Information Resource Management (IRM) is a common sense solution for Enterprise Engineering, Systems Engineering, Data Base Engineering, and Project Management. The methodologies include defined work breakdown structures, deliverables, and review points that promote quality and the production of industrial-strength information systems. Building information resources is a science, not an art form. Our methodologies clearly explain the concepts that govern them, which remarkably, is derived from engineering/manufacturing practices. Now you can get these acclaimed methodologies for free at our corporate web site at: http://www.phmainstreet.com/mba/pride/

MY "PET PEEVE OF THE WEEK" IS "BIRTHDAYS"

Last week I celebrated my 39th birthday for the 15th time (you do the math). I've always found it amusing how we as humans like to celebrate birthdays. Frankly, I don't understand the hubbub surrounding it. After all, we really had nothing to do with it. Actually, we're just victims of circumstance. If anything, I always thought the mother and perhaps the father should be congratulated on a job well done, but not the child.

We love birthdays as kids. Its kind of like a surrogate-Christmas where we receive lots of presents. I always felt bad for those kids who had birthdays in December and so close to the holiday season. There ought to be a rule for these people so they can have a party a few months earlier to break things up for them.

But aside from kids, I have little use for birthdays. Anniversaries and holidays like Fathers Day and Mothers Day seem more important to me. At least I had something to do with these decisions.

Speaking of anniversaries, on April 1st, MBA celebrated its 36th anniversary in business. In the I.T. industry you're lucky if you make it past one year. I guess 36 is unimaginable to a lot of people. In fact, MBA was founded prior to the birth of most of the people in the I.T. industry today. This makes me feel a little old, but it also tells me we must have been doing something right in order to last this many years.

To mark our 36th anniversary, MBA has embarked on a new venture in the area of VoIP (Voice over Internet Protocol). We're assisting a new startup company called Tele Monalisa to offer long distance calling over the Internet. We're pretty excited about all of this as we see a big market for Internet enabled calls. Look for our press announcements to come out shortly.

Such is my Pet Peeve of the Week.

eBOOK: THE BRYCE IS RIGHT!

Folks, be sure to check out our eBook entitled, "The Bryce is Right! Empowering Managers in today's Corporate Culture." This is a frank and candid description of the state of the art in management and includes essays on the problems in management today, along with some pragmatic advice on how to deal with them. Basically, this is a condensed course in management. As such, it is suited for managers, either those aspiring to become a manager or for those who need a refresher course. It will also be of interest to young people entering the work force, and is excellent for college curriculums.

Charles Cole of Lyndhurst, OH, said it is a "Very interesting book. Good work! It reminds me of some of the early works I read by W. Edwards Deming. Too bad the American corporate gurus of his day didn't pay him heed."

And Wolf Hager of Fort Myers, FL, says it is "A very impressive publication which requires careful reading and reminds me somewhat of Peter Drucker."

The price is just $20 plus tax. For more information on our book or to order on-line, see:

http://www.phmainstreet.com/mba/bryce1.htm

We have also produced a new one-day training program of the same name. For more information on both the eBook and course, please visit our web site at:

http://www.phmainstreet.com/mba/bryce1.htm

While there, look for our MS PowerPoint presentation describing both the book and the training program.

AND FINALLY...

I received an e-mail from Kurt Davis in Cincinnati who wrote me regarding last week's essay, "The Problem with being ahead of your time."

Kurt writes:

"I've studied your PRIDE methodologies a lot and have always found them to be intellectually sound. Yes, it is robust, but more than anything it has a concrete foundation, something you don't find too often at the university level."

Thanks Kurt for your note,

Frankly, I don't think university professors teach true systems theory anymore, whether its in the business schools or computer science programs. The emphasis is still on computing and programming. As a small example, I would love to see a college prof teach someone how to build a manual system. I don't think they would know where to begin.

This past week I got into a discussion with a consultant over the nature of systems and whether they have life cycles. I contend your systems go on as long as your company remains in business (or changes its business). For example, manufacturing, banking, accounting, and customer systems have been with us for many years. The only thing that changes is their physical implementation. This brings up a point: Systems should be designed logically so they can be implemented many different ways physically (as technology changes). Unfortunately, most companies do not think this way and design them physically which requires them to be rewritten every couple of years.

Again, thanks for your e-mail. Keep those cards and letters coming.

MBA is an international management consulting firm specializing in Information Resource Management. We offer training, consulting, and writing services in the areas of Enterprise Engineering, Systems Engineering, Data Base Engineering, Project Management, Methodologies and Repositories. For information, call us at 727/786-4567. For a complete listing of my essays, see the "PRIDE" Special Subject Bulletins section of our corporate web site.

Our corporate web page is at:

http://phmainstreet.com/mba/

Management Visions is a presentation of M. Bryce & Associates, a division of M&JB Investment Company of Palm Harbor, Florida, USA. The program is produced on a weekly basis and updated on Sundays. It is available in versions for RealPlayer, Microsoft Media Player, and MP3 suitable for Podcasting. See our web site for details. You'll find our broadcast listed in several Podcast and Internet Search engines, as well as Apples' iTunes.

If you have any questions or would like to be placed on our e-mailing list to receive notification of future broadcasts, please e-mail it to timb001@phmainstreet.com

For a copy of past broadcasts, please contact me directly.

We accept MP3 files with your voice for possible inclusion in the broadcast.

There is no charge for adding a link to "Management Visions" on your web page, for details and HTML code, see the "Management Visions" web site.

Management Visions accepts advertising. For rates, please contact yours truly directly.

Copyright © 2007 by M&JB Investment Company of Palm Harbor, Florida, USA. All rights reserved. "PRIDE" is the registered trademark of M&JB Investment Company.

This is Tim Bryce reporting.

Since 1971: "Software for the finest computer - the Mind."

END

March 26, 2007

"THE PROBLEM WITH BEING AHEAD OF YOUR TIME"

Not too long ago Panasonic's corporate slogan was, "Just slightly ahead of our time." It was catchy and it inferred their products were on the cutting edge of the industry. There was only one problem with this, as Panasonic found out, people feel uncomfortable using products ahead of their time. Consequently, their slogan was changed to, "Ideas for Life." But this essay is not so much about slogans as it is about marketing products ahead of their time. The marketing graveyard is full of fine examples of products that were introduced and considered ahead of their time; for example:

• Sony's Betamax video recorder was introduced in the mid-1970's and was well regarded as a superior and quality product over its competition. The VHS format ultimately unseated the Betamax though, not because of superior quality but primarily due to cheaper costs. In less than ten years Betamax was gone.

• Xerox's Star computer was introduced in 1981. It was also a quality product that was ahead of its time, featuring a Graphical User Interface (GUI) that was copied by Apple, Microsoft, and just about everyone else.

• The GRiD Compass 1101 computer was released in 1982 and is the first true laptop as we understand it today, with a sleek design that included a screen that closed on top of the keyboard, a built-in modem, bubble memory, and it ran on batteries. But the product wasn't cheap and sold for upwards to $10,000 making it prohibitive to purchase for the average business person. Even worse, it didn't support the IBM PC architecture making it incompatible with popular programs of the day.

• IBM has also had its fair share of products that were ahead of its time and met premature deaths; including their Token Ring LAN which was ultimately supplanted by Ethernet. IBM's PS/2 line of computers was introduced in 1987 as a means to recapture the PC market. The PS/2 included a proprietary "Microchannel Architecture" which, although advanced and sophisticated, led to its demise from competitive "open" offerings. And finally, we have IBM's OS/2 operating system which was also introduced in the late 1980's and was the first 32-bit operating system for the PC platform. OS/2 was miles ahead of everything else (and arguably still is). Nonetheless, its strengths became its weaknesses as it was deemed too sophisticated for the average user; this coupled with aggressive marketing by Microsoft and incompetent marketing by IBM led to its doom.

LESSONS LEARNED

What can be learned from these experiences? Three things:

1. A product doesn't have to be superior in order to dominate a market; all that is required is just a little marketing hustle. You have to remember, the consumer believes all products of the same ilk are essentially the same. If it comes down to technologically superior features or cost, the consumer will always take the cheaper product. Advanced features are nice, but the consumer must believe they are warranted and add value to their lives.

2. For broad market acceptance, the product must be built on open standards. This was the hard lesson IBM learned in building its products.

Consumers prefer to be spoon-fed changes with teaspoons. It takes real visionaries to adopt new ideas and, unfortunately, they are few and far between. The consumer wants simple solutions they can easily assimilate. Remember, most people are afraid of major changes of any kind.

Let's also recognize that being first in your field is not easy in that you are ultimately inventing and cultivating your own market place. Inevitably you will make marketing mistakes along the way which copycat competitors will leap on. Further, they will offer inferior products at a greatly reduced price. We have seen this time and again in the I.T. industry alone.

The only true benefit of being the first in your field is that you have the market to yourself, at least for a while. During this period of time you should rake in as much money as possible, refine your product, and expand the market as much as possible. And if you're making money, you can be sure competitors won't be far behind.

"PRIDE"

Our company has learned these lessons the hard way. The "PRIDE" Methodologies for IRM were first introduced in 1971, beginning with our Information Systems Engineering Methodology (ISEM). And by doing so, MBA created the methodology market. I could go on and on as to all of the concepts and innovations we introduced, e.g., first commercial methodology, first to take an engineering/manufacturing approach, first data dictionary, etc., but suffice it to say people said we were years ahead of our time.

The competition wasn't far behind either, as other commercial methodologies were introduced as well as structured programming techniques and data dictionary systems. I could easily argue how "PRIDE" was superior in so many ways, but as I mentioned before, consumers are not really interested. Instead, they selected cheaper alternatives which were implemented badly. Regardless, they thought they had purchased a bargain.

Based on legal advice, we originally sold "PRIDE" as a proprietary product requiring the use of a nondisclosure agreement to be made privy to its contents. This was both good and bad. It was good in the sense it allowed us to protect the product from misappropriation (which was tested in a court of law), but it was bad in the sense we were handcuffed from disseminating information on how it worked. While MBA was restrained from public disclosure our competition propagated their products through the media. So much so, that "PRIDE" faded from public view.

As the first in the industry, we made our money early on and invested a lot of it back into the product in the form of research and development. Consequently, "PRIDE" evolved into a much larger product that now tackles issues such as Enterprise Engineering and Data Base Engineering. Frankly, it became more robust than the average person could assimilate which is one reason why, in 2004, we finally put it in the public domain through the Internet.

As I have written in the past, the market has changed considerably over the last 36 years since "PRIDE" was introduced. The people have changed, the technology has changed, but the problems haven't, e.g.; the backlog of user information requirements has gotten longer, not shorter; systems still lack integration; companies are plagued by redundant information resources; lack of documentation; fire fighting is still the common mode of operating; projects come in late and over budget, etc.

Recently, I was giving a "PRIDE" presentation to a startup company with some rather young analysts and programmers who are not as well versed in the history of the industry as I am. All they knew was basically what their college professors and instructors had taught them. I didn't do anything fancy, I just explained the basic "PRIDE" concepts such as Information Driven Design, Standard System Structure, Layered Documentation, the System/Data Relationship, IRM, etc. I kept it simple and to the point and this perplexed one of the attendees who approached me after the session and said, "I have been attending a lot of seminars and conferences lately on these subjects. I learned more in the last three hours than from all of the sessions I attended over the last five months. Where have you been?"

Naturally, I was flattered by his comments but explained how the industry lost its way over the years and is only now trying to reinvent systems theory. I told him there was really nothing new or magical in developing systems, so long as you demand precise terminology and clarity of concepts. I said, "Don't look for cryptic solutions, there is no panacea. The best solutions are the simple solutions."

As I traveled home I thought about the comments made by the class and considered where "PRIDE" stood in relation to the rest of the industry we created. By staying the course "PRIDE" may not be the best known methodology out there, but it is still light years ahead of the industry. Such is the price of being ahead of your time.

CONCLUSION

As mentioned, "PRIDE" has evolved into a substantial body of work which is one reason why we went public with it. By itself, there is enough material to make a full college curriculum out of it. And hopefully this will happen.

You can find "PRIDE" Methodologies for IRM on the Internet at:

http://www.phmainstreet.com/mba/pride/

But the other reason we put "PRIDE" in the public domain was to establish an open standard thereby overcoming one of the deficiencies I mentioned earlier.

"PRIDE" is still way ahead of itself. It will probably always be so. But as we celebrate our 36th year of business I have come to realize that "PRIDE" is so old, that it is new to those people who were born after it was introduced. As Milt liked to say, "The original and still the best."

OUR BRYCE'S LAW OF THE WEEK therefore is... "Consumers prefer to be spoon-fed changes with teaspoons."

"PRIDE" METHODOLOGIES FOR IRM

Friends, the "PRIDE" Methodologies for Information Resource Management (IRM) is a common sense solution for Enterprise Engineering, Systems Engineering, Data Base Engineering, and Project Management. The methodologies include defined work breakdown structures, deliverables, and review points that promote quality and the production of industrial-strength information systems. Building information resources is a science, not an art form. Our methodologies clearly explain the concepts that govern them, which remarkably, is derived from engineering/manufacturing practices. Now you can get these acclaimed methodologies for free at our corporate web site at: http://www.phmainstreet.com/mba/pride/

MY "PET PEEVE OF THE WEEK" IS "OUR FASCINATION WITH CELEBRITIES"

For the last few weeks the country has been distracted by Anna Nicole Smith's death. I guess its been kind of slow around the news desks. Although I take no joy in her passing, I am bewildered by the media attention to someone who did little more than take off her clothes. I think Joan Rivers would call her a "tramp."

If you go to the news stands, you are bombarded by media trash talking about the dating, marriage, and divorce habits of the rich and famous, particularly Hollywood stars. I guess I'm not particularly interested in who is dating who; nor am I interested in what movie stars are adopting babies in some Godforesaken country. I guess we don't have enough orphans in this country. No, I'm more interested in inflation, the economy, the layoffs in Detroit, and the occupation of Iraq, but I don't think these are very newsworthy stories anymore.

I find it somewhat amusing how the Hollywood stars like to portray themselves as artists, even though their pictures often flop at the box office. In the old days, actors like John Wayne, Humphrey Bogart, Clark Gable, Jimmy Stewart, and Katherine Hepburn said they were making "pictures", not works of art. They just saw it as their job in life, to entertain the public. But today, the actors and actresses seem to think they are making fine art. To me, art is something that Pablo Picasso, Dali, and Leonardo da Vinci made, not what Brad Pitt, Leonardo DiCaprio, Tom Cruise, or Tom Hanks makes. Sure, they are capable actors, but definitely not artists. If their movies are art, then so are the funny papers.

To my way of thinking, there are those that make a difference in the world, be it in the workplace, performing research, inventing new ideas, or discovering unchartered waters or space; and then there are those who are suppose to entertain us on our off hours. In the Middle Ages, Kings would appoint "fools" to their court for entertainment. They were only paid a modest wage as their work was amusing, but certainly not more so than the rest of the court. But now the "fools" reign over the kingdom, as opposed to the other way around.

I'm not sure when we elevated the stature of celebrities; but it most likely was in the 20th century as the media grew and matured. Think I'm wrong? Consider this: which gets more attention these days; the Oscar presentations or the Nobel Peace prizes? Hmm, I think we have another instance of the tail wagging the dog.

Such is my Pet Peeve of the Week.

eBOOK: THE BRYCE IS RIGHT!

Folks, be sure to check out our eBook entitled, "The Bryce is Right! Empowering Managers in today's Corporate Culture." This is a frank and candid description of the state of the art in management and includes essays on the problems in management today, along with some pragmatic advice on how to deal with them. Basically, this is a condensed course in management. As such, it is suited for managers, either those aspiring to become a manager or for those who need a refresher course. It will also be of interest to young people entering the work force, and is excellent for college curriculums.

Charles Cole of Lyndhurst, OH, said it is a "Very interesting book. Good work! It reminds me of some of the early works I read by W. Edwards Deming. Too bad the American corporate gurus of his day didn't pay him heed."

And Wolf Hager of Fort Myers, FL, says it is "A very impressive publication which requires careful reading and reminds me somewhat of Peter Drucker."

The price is just $20 plus tax. For more information on our book or to order on-line, see:

http://www.phmainstreet.com/mba/bryce1.htm

We have also produced a new one-day training program of the same name. For more information on both the eBook and course, please visit our web site at:

http://www.phmainstreet.com/mba/bryce1.htm

While there, look for our MS PowerPoint presentation describing both the book and the training program.

AND FINALLY...

I received an e-mail from Jon Harris in New York who wrote me regarding last week's Pet Peeve, "Software Documentation."

Jon writes:

"I know exactly what you mean by lousy documentation. Getting our people to write understandable documentation seems to be an impossibility."

Thanks Jon for your note,

I agree. Most of today's software documentation is written after the program is produced which I think is quite strange. To me, documentation should be a natural byproduct of the development effort. In fact, the final documentation should be ready before the program is complete. But to do so, you have to be structured and disciplined first. I see documentation as a working tool, just as blueprints are used in architecture and engineering. But today's software developers don't think this way. They would rather hack away at the code as opposed to design it in any particular manner. For example, if you listen to the Agile Methodology people, documentation is the last thing they are concerned with; most think it is a complete waste of time. Consequently, they have problems not only in producing useful documentation for the end-user, but also have problems in maintaining and updating their products. As a result, they tend to rewrite their software more than is necessary. Strange. Very strange.

Again, thanks for your e-mail. Keep those cards and letters coming.

MBA is an international management consulting firm specializing in Information Resource Management. We offer training, consulting, and writing services in the areas of Enterprise Engineering, Systems Engineering, Data Base Engineering, Project Management, Methodologies and Repositories. For information, call us at 727/786-4567. For a complete listing of my essays, see the "PRIDE" Special Subject Bulletins section of our corporate web site.

Our corporate web page is at:

http://phmainstreet.com/mba/

Management Visions is a presentation of M. Bryce & Associates, a division of M&JB Investment Company of Palm Harbor, Florida, USA. The program is produced on a weekly basis and updated on Sundays. It is available in versions for RealPlayer, Microsoft Media Player, and MP3 suitable for Podcasting. See our web site for details. You'll find our broadcast listed in several Podcast and Internet Search engines, as well as Apples' iTunes.

If you have any questions or would like to be placed on our e-mailing list to receive notification of future broadcasts, please e-mail it to timb001@phmainstreet.com

For a copy of past broadcasts, please contact me directly.

We accept MP3 files with your voice for possible inclusion in the broadcast.

There is no charge for adding a link to "Management Visions" on your web page, for details and HTML code, see the "Management Visions" web site.

Management Visions accepts advertising. For rates, please contact yours truly directly.

Copyright © 2007 by M&JB Investment Company of Palm Harbor, Florida, USA. All rights reserved. "PRIDE" is the registered trademark of M&JB Investment Company.

This is Tim Bryce reporting.

Since 1971: "Software for the finest computer - the Mind."

END

March 19, 2007

"THE RATIO OF ANALYSTS TO PROGRAMMERS"

In terms of systems development, during the 1960's and early 1970's you were either a Systems Analyst or a Programmer. Period. At the time, there were substantially more analysts than programmers (at least a 2:1 ratio). This was due, in part, to the fact that computing was just coming into its own in the corporate world and there were still people around who could look at systems in its entirety. However, there was a screaming need for people to program computers and, as such, this became the boom years of programming. If you knew COBOL, Fortran, or PL/1 you could just about right your own ticket. Salaries were good, and you could intimidate your employer simply by what you knew (you had to commit something like murder to get fired). The emphasis on programming became so great that authors rushed out voluminous books to increase programmer productivity, hence the birth of the Structured Programming movement of the late 1970's, which was followed shortly thereafter by the CASE movement (Computer Aided Software Engineering).

While programming was growing in stature, Systems Analysis was in sharp decline. Trade groups such as the Association for Systems Management (ASM) saw their membership dwindle to nothing and were forced to close their doors. The last of the old Systems Analysts either retired or were put out to pasture by corporations in the 1980's. New job titles emerged, such as Software Engineer and Analyst/Programmer. This latter title is a bit of a misnomer as the emphasis was on programming and not systems analysis.

Although programming excelled, a noticeable void began to appear in terms of people who could see systems in its totality. Writing a good program is one thing, getting it to interface with other programs to form a whole system is something entirely different. By the turn of the century, the industry started to talk about such things as "Enterprise Architecture," "Business Processes," "Business Rules," "Business Analysis," etc. Further, new conferences, trade groups, and job titles began to emerge. Today, programmers are considered a dime a dozen and the stock of a true analyst is on the rise.

All of this is indicative of the industry trying to reinvent systems theory. In reality there is nothing new here as systems analysis is systems analysis. But as companies implement these concepts and job titles again, they are a bit uncertain as to where they fit in and their relationship to other Information Technology functions.

CHARACTERISTICS

A Systems Analyst goes by many names these days; e.g., Business Analyst, Enterprise Architect, Systems Engineer (my personal preference), etc. Nonetheless, we are talking about a person whose mission is to study the information requirements of a business and design a total system solution to satisfy them. Further, the analyst is responsible for specifying the software requirements and, as such, is considered the intermediary with the programming staff. The personal characteristics of the analyst are considerably different than the programmer. Whereas the programmer tends to be more introverted and focused on technology, the analyst tends to be more business oriented and extroverted. Analysts possess good communications skills (verbal and written) to effectively work with both the end-users and the programming staff. They know how to conduct an interview and make a presentation (salesmanship). In addition, they tend to look at the bigger picture as opposed to just a portion of it, and possess an entrepreneurial spirit.

The analyst understands the business problems of the end-user and is intimate with the operation of the user's department. In other words, the analyst can comfortably walk in the shoes of the end-user. If they are doing their job properly, analysts make excellent candidates to assume responsibility in the management hierarchy. But because analysts were in decline for so many years, this hasn't happened for quite some time. The last time I heard of a systems analyst graduating to a major management position was Dan Boone who was made President and COO of Armco Steel in the late 1970's.

If systems analysis is performed correctly, programmer productivity should improve as analysts should be providing good specifications for application assignments. In the absence of systems analysts, considerable time is lost by the programmer who has to second-guess what the end-user wants. Inevitably, this leads to rewriting software over and over again. Good data and processing specs, as provided by a systems analyst, will improve programmer productivity far better than any programming tool or technique. This means programmers are the beneficiaries of good systems analysis.

This brings up an interesting point, what should be the ratio of Systems Analysts to Programmers in a development organization? Frankly, I believe there should be twice as many analysts than programmers. By concentrating on the upfront work, programming is simplified.

Let me illustrate the point by using the following triangles representing the total amount of effort in a project (as an aside, I picked this up from my customers in Japan who share my opinion):

The triangle on the left represents the traditional approach whereby there is twice the number of programmers to systems analysts. Under this approach, considerably more time is spent producing software to satisfy poorly defined requirements. The Japanese point out the bottom of the triangle is actually bottomless as it means more time is needed to complete a project. Compare it to the triangle on the right where there are twice as many analysts to programmers. Under this scenario, more time is spent analyzing the problem, designing the system, and producing better programming specs. Consequently, the programmers do not have to second-guess what has to be performed and can go about their work more productively.

The problem though is that Systems Analysis is considered to be somewhat of a nebulous concept to management. Programming, on the other hand, is more tangible and easier for people to grasp; you are either writing code and producing a program or you are not. Therefore, the mindset in management is that you are not being productive unless you are coding, hence the inclination to shortcut systems analysis. This is a key reason why Systems Analysis collapsed in the 1980's. And this is why it is necessary to provide training so management appreciates the need for systems analysis. Frankly, I have found management can be very supportive if it is presented to them properly.

CONCLUSION

Whether you call them Systems Analysts, Business Analysts, Systems Engineers, or Enterprise Architects, it is very encouraging to see this vital function being reintroduced to companies. As far as I am concerned, it was inevitable. I guess companies finally figured out you cannot satisfy your systems problems simply by using better programming tools and techniques.

We are also beginning to see the resurgence of related trade groups to replace such groups as the Association for Systems Management (ASM), for example:

The International Institute of Business Analysis

The IIBA appears to be picking up where ASM left off, including certification. Whereas ASM developed and offered the Certified Systems Professional (CSP) certification years ago, IIBA wants to create something similar.

All of this is indicative of how the industry is trying to reinvent systems theory. Whereas such systems work was well known up until the 1980's it was forgotten over the last twenty years due to the emphasis on programming. Fortunately, companies have finally realized the importance of systems work and are trying to get their houses in order. I guess what goes around, comes around.

OUR BRYCE'S LAW OF THE WEEK therefore is... "Good specifications will improve programmer productivity far better than any programming tool or technique."

"PRIDE" METHODOLOGIES FOR IRM

Friends, the "PRIDE" Methodologies for Information Resource Management (IRM) is a common sense solution for Enterprise Engineering, Systems Engineering, Data Base Engineering, and Project Management. The methodologies include defined work breakdown structures, deliverables, and review points that promote quality and the production of industrial-strength information systems. Building information resources is a science, not an art form. Our methodologies clearly explain the concepts that govern them, which remarkably, is derived from engineering/manufacturing practices. Now you can get these acclaimed methodologies for free at our corporate web site at: http://www.phmainstreet.com/mba/pride/

MY "PET PEEVE OF THE WEEK" IS "SOFTWARE DOCUMENTATION"

I've been researching Internet shopping carts and gateways to merchant accounts lately and, believe me, there are a lot of them out there these days. Not long ago you heard me complain about the lack of standards in web page design, but now I want to address the horrible state of software documentation. Back in the 1960's and 1970's, when you purchased a software package, you were lucky to get any documentation with it, mostly just source code. But frankly, I don't think we're any better off today than we were 30 - 40 years ago.

The shopping cart I've been working with is one of the most popular products out there (I won't mention the name), and it has a lot of functionality from a programming point of view, but it is a pain in the ass in terms of being able to tailor it to our needs. Oh, the facilities exist to tailor it, but the documentation is severely lacking. Consequently, you have to spend a lot of time searching for answers and experimenting to get what you want. The vendor claims the screens of the product are very intuitive and easy to use. Well, for basic shopping, maybe they're right, but if you need to adapt it to suit your specific needs, it is one of the most cumbersome products I've ever seen.

First, understand this, just because you deliver a product with a PDF file doesn't mean you have fulfilled your obligations as a vendor. The documentation we received is unstructured and difficult to wade through, regardless if you know how to search through a PDF file. Search will only help you if there is something useful for you to find. For example, there is nothing in the software's screens or documentation to explain the various field entries in terms of what should be entered, default and valid entries, its physical limitations, and how the fields are used. No, you are left to figure this out for yourself. And, to me, this is the Number One cause for slow startups in the use of shopping carts.

I believe the people who write the documentation are the same people who programmed the product, which is not a good thing, since most programmers know nothing about how to effectively communicate with human beings, only with computers. Consequently, I believe merchants are only using a fraction of the shopping cart's capabilities.

You would think by now software vendors would have their act together in terms of producing decent documentation. Think again.

Such is my Pet Peeve of the Week.

eBOOK: THE BRYCE IS RIGHT!

Folks, be sure to check out our eBook entitled, "The Bryce is Right! Empowering Managers in today's Corporate Culture." This is a frank and candid description of the state of the art in management and includes essays on the problems in management today, along with some pragmatic advice on how to deal with them. Basically, this is a condensed course in management. As such, it is suited for managers, either those aspiring to become a manager or for those who need a refresher course. It will also be of interest to young people entering the work force, and is excellent for college curriculums.

Charles Cole of Lyndhurst, OH, said it is a "Very interesting book. Good work! It reminds me of some of the early works I read by W. Edwards Deming. Too bad the American corporate gurus of his day didn't pay him heed."

And Wolf Hager of Fort Myers, FL, says it is "A very impressive publication which requires careful reading and reminds me somewhat of Peter Drucker."

The price is just $20 plus tax. For more information on our book or to order on-line, see:

http://www.phmainstreet.com/mba/bryce1.htm

We have also produced a new one-day training program of the same name. For more information on both the eBook and course, please visit our web site at:

http://www.phmainstreet.com/mba/bryce1.htm

While there, look for our MS PowerPoint presentation describing both the book and the training program.

AND FINALLY...

I received an e-mail from Jeff Fabor in Cincinnati who wrote me regarding last week's essay, "Parkinson's Law in I.T."

Jeff writes:

"Your comments on Parkinson't Law makes a lot of sense, but is there anything we can do as a consumer?"

Thanks Jeff for your note,

Good question. We've seen technology grow in leaps and bounds just in this century alone. But perhaps it is changing too fast. Too often I have seen products delivered prematurely with a lot of bugs in it. Vendors would rather have the consumer shake out their product for them as opposed to thoroughly testing it themselves. This disturbs me greatly, which is why I no longer beta-test software anymore; nor am I in a mad rush to upgrade software. Vendors such as MS don't exactly have a good track record in terms of delivering quality products on their initial release. Consequently, I now take a "wait and see" attitude. Most people like to rush out and get the latest updates in fear of "falling behind" or so they can proclaim they are "state of the art." As for me, I would rather look carefully before I leap. State of the art is whatever I want it to be, not what someone else wants it to be.

Again, thanks for your e-mail. Keep those cards and letters coming.

MBA is an international management consulting firm specializing in Information Resource Management. We offer training, consulting, and writing services in the areas of Enterprise Engineering, Systems Engineering, Data Base Engineering, Project Management, Methodologies and Repositories. For information, call us at 727/786-4567. For a complete listing of my essays, see the "PRIDE" Special Subject Bulletins section of our corporate web site.

Our corporate web page is at:

http://phmainstreet.com/mba/

Management Visions is a presentation of M. Bryce & Associates, a division of M&JB Investment Company of Palm Harbor, Florida, USA. The program is produced on a weekly basis and updated on Sundays. It is available in versions for RealPlayer, Microsoft Media Player, and MP3 suitable for Podcasting. See our web site for details. You'll find our broadcast listed in several Podcast and Internet Search engines, as well as Apples' iTunes.

If you have any questions or would like to be placed on our e-mailing list to receive notification of future broadcasts, please e-mail it to timb001@phmainstreet.com

For a copy of past broadcasts, please contact me directly.

We accept MP3 files with your voice for possible inclusion in the broadcast.

There is no charge for adding a link to "Management Visions" on your web page, for details and HTML code, see the "Management Visions" web site.

Management Visions accepts advertising. For rates, please contact yours truly directly.

Copyright © 2007 by M&JB Investment Company of Palm Harbor, Florida, USA. All rights reserved. "PRIDE" is the registered trademark of M&JB Investment Company.

This is Tim Bryce reporting.

Since 1971: "Software for the finest computer - the Mind."

END

March 12, 2007

"PARKINSON'S LAW IN I.T."

Ever wonder why our computers typically last no more than three years? Many contend it is because of the fast pace of technological advancements. Maybe. But I tend to believe there is a little more to it than just that, namely "Parkinson's Law." For those of you who may have forgotten, "Parkinson's Law" was devised by C. Northcote Parkinson, noted British historian and author. His original book, "Parkinson's Law: The Pursuit of Progress," was introduced in 1958 and was a top-selling management book for a number of years (it is still sold today). The book was based on his experience with the British Civil Service. Among his key observation's was that "work expands so as to fill the time available for its completion." Basically, he suggests that people make work in order to rationalize their employment. Consequently, managers create bureaucracies and superfluous work to justify their existence, not because it is really needed.

As an aside, CEO's clearly understood Parkinson's Law, which became the driving force behind the flattening of corporations in the 1990's, such as General Electric under Jack Welch's reign.

AS APPLIED TO INFORMATION TECHNOLOGY

Whereas Parkinson was primarily concerned with people, his law is equally applicable to machines, particularly computers; for example, Parkinson's Law can be applied to computing in terms of "Data expands to fill the space available for storage." Years ago I had a Compaq Presario computer with 50mb of disk space, which I considered substantial at the time. I never dreamt I would be able to fill up the hard drive. But, of course, I did (as well as other PC's I have had over the years). My current PC has a hard drive with a capacity of 224gb and though I'm a long way from filling it up, inevitably I know I will for two reasons: I now feel more comfortable with downloading large multimedia files (MP3, AVI, WMV, etc.), PDF files, data base files, and other larger file formats, and; Second, because developers have become sloppy in programming.

Back when memory and disk space were at a premium, there was great concern over the efficient use of computer resources. Program code was written very tightly and consideration was given to file size. For example, establishing a simple file index was scrutinized carefully. But as the computer capacity grew and hardware prices declined, developers became less interested in efficient programming. To illustrate, not too long ago packaged software installation programs were delivered on 3.5" diskettes. Today, it is not uncommon to use multiple CD's to install the same products. This means that as computer hardware capacity increases, software becomes more bloated. This is but one example of Parkinson's Law as applied in computing.

As another example, let's consider data transmission lines as used in networking. It doesn't seem long ago we were using 14.4 baud modems over telephone lines. I remember when we doubled the speed to 28.8 and then 56.4. It seemed like the sky was the limit with every increase. But eventually performance seemed to slow to a crawl. Was it because the technology was aging or was it because our web pages were becoming bigger and more complicated requiring greater data volume over the lines? Frankly, it was the latter. Today, DSL and cable are commonplace in households as well as in business and "dial-up" is rapidly becoming a thing of the past. But as data volume increases with the number of subscribers, will we ever hit a wall in terms of capacity with DSL and cable? Undoubtedly. Again, more due to Parkinson's Law then anything else.

Make no mistake, computer hardware and software vendors are acutely aware of the role of Parkinson's Law. It is what allows them to build-in planned obsolescence into their products. As consumers reach capacity, they can either add additional capacity or, more likely, purchase new computers.

There is undoubtedly an incestuous relationship between hardware and software vendors. Hardware enhancements are primarily implemented to increase capacity in order to overcome software inefficiencies, and software vendors make their products more bloated as hardware enhancements are introduced. To illustrate the point, is it a coincidence that every major release of Windows requires additional hardware support? Hardly. This is done more by design than by accident.

CONCLUSION

Parkinson's Law is just as much a part of computer technology as it is in the corporate world. But what would happen if we decided to "flatten" computer technology in the same manner that Jack Welch flattened G.E.? Keep in mind, Welch did so to eliminate bureaucracy and force his workers to become more efficient and focus on the true problems at hand. By flattening the "bloatware" we would probably get a lot more mileage out of our computers. But I guess that wouldn't be good for selling computers (or the economy).

I guess Parkinson's Law and the vicious circle of computing will be with us for quite some time.

OUR BRYCE'S LAW OF THE WEEK therefore is... "As computer hardware capacity increases, software becomes more bloated."

"PRIDE" METHODOLOGIES FOR IRM

Friends, the "PRIDE" Methodologies for Information Resource Management (IRM) is a common sense solution for Enterprise Engineering, Systems Engineering, Data Base Engineering, and Project Management. The methodologies include defined work breakdown structures, deliverables, and review points that promote quality and the production of industrial-strength information systems. Building information resources is a science, not an art form. Our methodologies clearly explain the concepts that govern them, which remarkably, is derived from engineering/manufacturing practices. Now you can get these acclaimed methodologies for free at our corporate web site at: http://www.phmainstreet.com/mba/pride/

MY "PET PEEVE OF THE WEEK" IS "INFLATION"

Back in the presidential election of 1972, the country was still embroiled in the Viet Nam War. But domestically, the big campaign issue was inflation (does anyone remember Nixon's WIN buttons - "Whip Inflation Now"). At the time, people were incensed by the spiraling cost of living. But people don't seem to be too concerned about inflation anymore and take it in stride. The talking heads on television don't talk about it anymore, nor do the newspapers. I'm just wondering when we became jaded about inflation.

We all know that gas prices keep creeping up, which has effected just about everyone's pocketbook and has caused other companies to raise their prices, such as restaurants, retailers, and so on. But when is someone going to do anything about it? Let me give you an example, I just received my quarterly garbage bill from Waste Management who suddenly announced a $20 increase in their service which I considered outrageous. I contacted their competitors to see if I could get a better price elsewhere but found they had also raised their prices on a comparable level. Most of my neighbors said, "Oh well, its simply a sign of the times," and resigned themselves to paying the increase. Its not that I can't afford the increase but I finally said "enough is enough" and canceled my service. I'm now bagging my own garbage and disposing it in my office dumpster.

I'm just wondering what ever happened to the outrage by the consumer over inflationary prices and when someone will do something about it. As a consumer, the only leverage we have is to simply say, "No." If enough people did, companies would be forced to start addressing the problem. And believe me, this can work. Let me give you an example; down here in Florida you may have heard of the outrageous insurance premiums we have had to pay since the hurricanes hit us a couple of years ago. Since then, we have been living with inordinate price hikes. The latest trick is to sell separate policies; one for liability and fire, and another for windstorm damage. Interestingly, the insurance companies have tied the latter to the former. In other words, you can't have a liability and fire policy without windstorm coverage. This has caused insurance prices to double and triple. But this has started to change though as more and more people are starting to say "No" to the insurance companies. To illustrate, I'm involved with a consortium of nonprofit organizations that maintain their own buildings. One by one they started to drop their insurance carriers and shop elsewhere. This became so prevalent that the big insurance companies finally dropped the stipulation of mandating windstorm coverage. All of this because people finally got fed up and said "No."

I don't think most people understand the power of the consumer. Only when the consumer's ire finally rises does anything seem to happen. And perhaps this is what is needed to whip inflation - not just some cute campaign buttons. But when is this finally going to happen? We'll don't hold your breath for government to do anything about it, regardless of the political party you are affiliated with. It will only happen when the consumer finally recognizes his power and decides to flex his muscles by saying, "enough is enough."

Maybe we need a few more people bagging their own garbage for a while.

Such is my Pet Peeve of the Week.

eBOOK: THE BRYCE IS RIGHT!

Folks, be sure to check out our eBook entitled, "The Bryce is Right! Empowering Managers in today's Corporate Culture." This is a frank and candid description of the state of the art in management and includes essays on the problems in management today, along with some pragmatic advice on how to deal with them. Basically, this is a condensed course in management. As such, it is suited for managers, either those aspiring to become a manager or for those who need a refresher course. It will also be of interest to young people entering the work force, and is excellent for college curriculums.

Charles Cole of Lyndhurst, OH, said it is a "Very interesting book. Good work! It reminds me of some of the early works I read by W. Edwards Deming. Too bad the American corporate gurus of his day didn't pay him heed."

And Wolf Hager of Fort Myers, FL, says it is "A very impressive publication which requires careful reading and reminds me somewhat of Peter Drucker."

The price is just $20 plus tax. For more information on our book or to order on-line, see:

http://www.phmainstreet.com/mba/bryce1.htm

We have also produced a new one-day training program of the same name. For more information on both the eBook and course, please visit our web site at:

http://www.phmainstreet.com/mba/bryce1.htm

While there, look for our MS PowerPoint presentation describing both the book and the training program.

AND FINALLY...

I received an e-mail from Mike Jones in Wyoming who wrote me regarding last week's essay, "Diagnosing System Problems."

Mike writes:

"Thanks for the tips on solving problems, but quite often I see I.T. people attacking the wrong problems and are easily sidetracked."

Thanks Mike for your note,

You bring up a good point, there is a great temptation to attack symptoms in the I.T. world as opposed to true problems. I have seen this in software design, system design, and in management. Let me give you an example, whenever you see a situation where projects are coming in consistently late and over budget, the knee-jerk reaction is to bring in more Project Management. To me, this is attacking the symptom, not the root problem. Even if you get the most sophisticated Project Management software, projects will still come in late and over budget. Why? Because people don't know how to do their jobs properly in the first place. Instead, they should be concentrating on process management, or as I like to call it, their "methodology" for performing work.

Let's consider a manufacturing facility for a moment. Without a defined asembly line in place, no amount of project management will correct the problem; people will still not be performing their work assignments the right way or in a concerted manner. Only after the assembly line has been defined and people trained in their responsibilities can you affix a project management system. To me, project management is the "dials and gauges" to an automobile. Without the automobile though, they are useless. Having a Project Management system without a methodology is like attaching a speedometer to an orange crate; it measures nothing.

So, to answer your point, Yes, you are right, people have a natural inclination to attack symptoms and not problems.

Again, thanks for your e-mail. Keep those cards and letters coming.

MBA is an international management consulting firm specializing in Information Resource Management. We offer training, consulting, and writing services in the areas of Enterprise Engineering, Systems Engineering, Data Base Engineering, Project Management, Methodologies and Repositories. For information, call us at 727/786-4567. For a complete listing of my essays, see the "PRIDE" Special Subject Bulletins section of our corporate web site.

Our corporate web page is at:

http://phmainstreet.com/mba/

Management Visions is a presentation of M. Bryce & Associates, a division of M&JB Investment Company of Palm Harbor, Florida, USA. The program is produced on a weekly basis and updated on Sundays. It is available in versions for RealPlayer, Microsoft Media Player, and MP3 suitable for Podcasting. See our web site for details. You'll find our broadcast listed in several Podcast and Internet Search engines, as well as Apples' iTunes.

If you have any questions or would like to be placed on our e-mailing list to receive notification of future broadcasts, please e-mail it to timb001@phmainstreet.com

For a copy of past broadcasts, please contact me directly.

We accept MP3 files with your voice for possible inclusion in the broadcast.

There is no charge for adding a link to "Management Visions" on your web page, for details and HTML code, see the "Management Visions" web site.

Management Visions accepts advertising. For rates, please contact yours truly directly.

Copyright © 2007 by M&JB Investment Company of Palm Harbor, Florida, USA. All rights reserved. "PRIDE" is the registered trademark of M&JB Investment Company.

This is Tim Bryce reporting.

Since 1971: "Software for the finest computer - the Mind."

END