MANAGEMENT VISIONS

Wednesday, November 29, 2006

December 4, 2006

"UNDERSTANDING GROUP DATA ELEMENTS"

In the past I have discussed the need to manage data (as well as all information resources) as a valuable resource; something to be shared and reused in order to eliminate redundancy and promote system integration. Now, our attention turns to how data should be defined. Well defined data elements are needed in order to properly design the logical data base as well as developing a suitable physical implementation.

First, let's understand how data is used; there are three purposes:

  • Indicative Data - to identify the important objects needed to run a business, be it something as tangible as a customer, employee, product, part, etc. or as intangible as an event, such as a shipment, a billing, or transaction.

  • Descriptive Data - alphanumeric values that are not strong enough to identify an object, but convey important business facts about an object, such as names, addresses, text, codes, etc.

  • Quantitative Data - numeric values that are either calculated or are calculable. Measurements and computations are typical examples: "Net-Pay," "Quantity Ordered," "Elapsed Time," "Percent of Gross," etc.

Basically, there are two types of data elements: Primary and Generated

PRIMARY data refers to data in its virgin state; as introduced to the system from an external source (such as a person or department). "Source" defines who is responsible for entering the data to a system, and who has ultimate authority for the definition of the data element its meaning).

GENERATED data refers to data that relies on other data elements in order to produce the necessary result. This type of data can involve elaborate calculations and algorithms (e.g., DD-1 + DD-2 = DD-3). "Net Pay," "Balance Amount" and "Percent Complete" are some examples of calculated data.

GROUP DATA

Most data elements easily fall into the two categories of Primary and Generated, but there is a seeming anomaly that often confuses people, namely "Group" Data Elements, such as "Credit Card Number," "Telephone Number," "Check Number," etc. Many companies treat it as a Primary value when, in reality, it is often a Generated value; let me explain.

Group data is actually a concatenation of multiple data elements. For example, "Credit Card Number" typically consists of "Financial Institution ID," "Bank Region Number," "Bank Branch Office ID," and "Account Number." The "Customer Number" on a power bill may represent such things as: "Primary Power Station," "Sub-Station," and "Account." To a communications company, a "Telephone Number" has considerable meaning and represents "Area Code," "Exchange," and "Account." There are many other examples of "group" data: such as product identification codes, bank codes, insurance policy numbers, etc.

It is a common misconception that group data elements should be used for basic groupings (keys) in logical records; THEY SHOULD NOT! Group data is used as a convenient means to describe dependencies between primary data elements. As such, a group data element provides tremendous insight into objects and views. For example, consider the objects and views associated with a "Telephone Number": "Area Code" + "Exchange" + "Account Holder" Consider the dependencies between the three views. Each has an impact on the others. Should the first view be deleted, the second and third views will also be deleted. From this perspective, the basic grouping defines dependencies and eliminates the problem of multiple occurrences.

Data elements such as "Telephone Number" and "Credit Card Number" should only be defined as group items if they truly represent a concatenation of indicative data elements representing objects. For example, "Telephone Number" is a valid group item to identify a "Communications Area" and its views for a telephone company. But if "Communication Area" is not a pertinent object to your business, there is little point in defining it as a group item. Instead, it is a simple primary value.

Another hint as to whether a data element is primary or generated, is whether the company assigns the values to it, if they do not, then it is probably a primary value.

CONCLUSION

So why do companies have group data elements? Because it is a convenient means to quickly identify the objects and views important to the business. For example, it allows companies to "roll up" data; e.g, the number of accounts within a specific area. Further, a group data element may not be suitable for logical data base design, but has been found to be a useful means in the design of the physical file design (expedites accessing data).

How many Group data elements does a company truly use? Not as many as you might think. For example, Credit Card Numbers, Bank Codes, and Telephone Numbers are primary values in my business. However, a "Customer Number" is a group item consisting of a "Contract" and "Location." It all depends on whether these are important objects your company manages, hence, "Indicative Data" is devised and assigned to uniquely identity it.

To the average programmer, there is little concern for how data is defined other than to assign a suitable program label. However, data definition is a very important consideration to Systems Engineers and Data Engineers who are charged with building major integrated systems. Think about it.

For more information on Data Definition, see:

"PRIDE"-Data Base Engineering Methodology (DBEM)

OUR BRYCE'S LAW OF THE WEEK therefore is... "Group Data tells us a lot about what objects are important to an enterprise."

"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 "COMPUTER VIRUSES"

A couple of months ago, my Windows XP computer was attacked by a virus. I believe I have good anti-virus controls in place, but nevertheless something got through causing me considerable headaches for the day. I finally was able to isolate and rid myself of it, but I found the experience very annoying. I know Microsoft and my anti-virus vendors take steps to issue updates to protect my computer, but I'm puzzled as to why Windows is so susceptible to viruses; it probably has something to do with the basic design of the operating system.

I read somewhere that Microsoft's new version of Windows, entitled Vista, is suppose to be virus proof. I'll believe it when I see it. There seems to be an unwritten challenge by the hackers out there as to who can first hack and disrupt each major release of Windows. They've been pretty successful so far and I don't expect Vista to be any different.

In the past, you've heard me talk about IBM's OS/2 operating system, which was a very stable and reliable product that was difficult to hack. I wonder why IBM was able to design effective security and Microsoft hasn't so far? Maybe they're simply being kind to companies like MacAfee and Norton who make a good buck on the anti-virus industry. Or maybe they simply don't know how to design a hack-proof operating system. Maybe both.

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 a Bernie DeMarco in Chicago who wrote me regarding last week's essay, "What exactly are we engineering anyway?"

Bernie writes:

"You make some valid points as to the characteristics of an engineer, but it seems we are stuck with the title of Software Engineer, at least in my business."

Thanks Bernie for your note,

As I mentioned in the essay, titles such as "Software Engineer" are a misnomer in most companies. I know we desire to have a fancy title to express our importance, but I find a lot of Software Engineers haven't the faintest idea what engineering is all about (which is why I wrote the article). The title "Programmer" seems too passe for a lot of people. Okay, how about "Software Specialist" instead? Kind of sounds like a crime-scene detective doesn't it? Nonetheless, it makes no pretense that it is an engineering position, nor does it imply certification. Frankly, I have no problem with the title "Programmer" and do not think any less of a person who has the title. In fact, I prefer it over the title of "Software Engineer" which I consider more suspiciously.

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 © 2006 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

Monday, November 20, 2006

November 27, 2006

"WHAT EXACTLY ARE WE ENGINEERING ANYWAY?"

A few years ago, I knew an IT Manager in New England who worked for a pharmaceutical company. At the time, he was staffing up for a major systems project and was trying to recruit programmers for the assignment. The salaries he was offering were very generous (perhaps too much). Nonetheless, I remember he had one candidate who was qualified for the job, liked the money, but turned the IT Manager down claiming he didn't like the job title; he insisted on being called a "Software Engineer" as opposed to a mere "Programmer." The IT Manager was not in a position to change job titles and, consequently, the two couldn't come to terms.

I thought this particularly odd as I knew the assignment and had met the candidate. How the two had anything to do with the engineering of software is beyond me. Although large in scope, the application was basically a "meatball" operation with a simple data base. Further, some simple visual programming tools were to be used. In other words, it was unlikely the programmer was going to have to roll up his sleeves and dive deep into any source code. As to the candidate, he claimed a good track record with other companies, but I saw nothing in his portfolio that led me to believe he was a certified engineer by anyone's standards.

The industry has been talking about "software engineering" for the last three decades. The term is primarily used by programmers who are desperately seeking credibility in an industry that changes daily. Frankly, people use the term "engineer" to make themselves appear more important than they really are.

Now we are hearing terms like "Enterprise Engineer" and "Data Base Engineer", etc. Are these legitimate concepts or just another passing fad? Let's take a look.

UNDERSTANDING ENGINEERING

In simple terms, engineering is the planning, design and development of an object; e.g., buildings, products, machinery, etc. Different branches of engineering have been devised and are based on the subject areas they address; for example, civil, chemical, electrical, mechanical, are but a few. Within any engineering discipline, there are three objectives :

1. To produce a RELIABLE product or object that will satisfy requirements and perform according to specifications.

2. To produce a product or object that is easy to MAINTAIN and MODIFY.

3. To physically implement the product or object in the most PRACTICAL, EFFICIENT, and COST EFFECTIVE manner possible.

To this end, engineering applies scientific knowledge towards these objectives. This last point is critical; it means there are agreed upon scientific principles that can be taught and used in a consistent manner. And this is where the problem lies. There are very few agreed upon scientific principles in the systems development world. Most development organizations operate under the "Tower of Babel" phenomenon where confusion reigns, producing inconsistent results. So much so, that we can hardly call it a science and, hence, terms like "engineering" are invalid. A science is based on governing principles that are generally accepted by an industry and can be taught to others. Heck, this industry can't even differentiate between "data" and "information" or "systems" and "software," let alone establish a full-bodied science. Quite frankly, the industry's terminology is sloppy and its concepts lack consistency.

Nonetheless, we must persevere if we are ever to gain any legitimacy.

Back in 1970, my father, Milt Bryce, was the keynote speaker for the Data Processing Management Association's (DPMA) annual conference in Seattle, Washington. During his speech, he discussed the lack of standards in the industry and called upon DPMA (later to become the AITP) to establish such standards. Although his talk was well received by the attendees, regretfully, DPMA didn't respond to the challenge and nothing was accomplished. Further, little has been produced along these lines by standards groups such as ISO or ANSI, or any other trade group.

This is why, 34 years after Milt's speech in Seattle, we finally put the "PRIDE" Methodologies for IRM in the public domain via the Internet; so that the industry has a solid starting point for establishing standards. "PRIDE" has been used all over the world in just about every field of endeavor imaginable. Further, it has survived several generations of competition. All of this has forced us to fine tune the concepts and terminology in "PRIDE," making it a battle-tested approach suitable for standardization.

Under "PRIDE", we believe Information Resource Management (IRM) to be a science based on some very sound and fundamental principles which are fully articulated in the product. With such a strong governing foundation, it is our contention that Information Resources can be engineered. In fact, we see four engineering disciplines, each with a different focus on the IRM puzzle:

ENTERPRISE ENGINEERING - is that branch concerned with developing logical and physical models of the business. This includes documenting and analyzing business functions, administrative relationships, and performing an organizational analysis. Based on this, Enterprise Engineering is also used to identify information requirements and establish the priorities for business objectives, along with their supporting projects.

INFORMATION SYSTEMS ENGINEERING - is that branch concerned with the design and development of enterprise-wide systems, complete with business processes. This is based on a standard system architecture that is designed, developed and implemented in a manner similar to the development of any product. Further, a blueprinting approach is used for document systems.

SOFTWARE ENGINEERING - is considered a subset of Information Systems Engineering and is concerned with the design and development of the software components in an Information System.

DATA BASE ENGINEERING - is that branch concerned with design and development of the corporate data base, both logically and physically.

Like all other engineering disciplines, these four IRM practices have the following objectives:

1. To produce a RELIABLE product or object that will satisfy requirements and perform according to specifications.

2. To produce a product or object that is easy to MAINTAIN and MODIFY.

3. To physically implement the product or object in the most PRACTICAL, EFFICIENT, and COST EFFECTIVE manner possible.

In other words, I believe it is legitimate to use the term "engineering" as long there is a science supporting it (whereby concepts and terminology are fully defined and accepted). If there is no governing science supporting it, use of the term 'engineering' is fraudulent and misleading.

CERTIFICATION

Normally in any engineering discipline, a person must be certified to claim the title and work in such a capacity, such as the title "PE" (Professional Engineer)." Certification is used to define a person's level of expertise. Since engineering is based on science, and the study of science is an ongoing process, the engineer must periodically renew their certification. As long as we resist certification, we will continue to be viewed as illegitimate misfits by management.

CONCLUSION

Use of the terms "engineering" and "engineer" are flippantly used throughout the computer industry. So much so, such terms are no longer taken seriously by management.

As long as we continue to argue over the concepts and terminology of this profession we will never be taken seriously by corporate management. Instead, we will be seen as nothing but a bunch of boobs rearranging the deck chairs on the Titanic.

This is sad as there are many of us in the industry who honestly believe it to be a legitimate profession based on scientific principles.

OUR BRYCE'S LAW OF THE WEEK therefore is... "If there is no governing science supporting it, use of the term 'engineering' is fraudulent and misleading."

"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/

IN OUR "DOWN THE ROAD" SECTION

The Association of Management Consulting Firms will be holding their 60th Annual Meeting on December 6th-8th at the Harvard Club in New York City. For information, contact AMCF headquarters in New York at 212/551-7887 or visit their web page at: http://www.amcf.org/

If you have got an upcoming IRM related event you want mentioned, please e-mail the date, time and location of the event to timb001@phmainstreet.com

"BRYCE MANAGEMENT ANALYSIS" SERVICE

We've just introduced a new free service for managers to perform a self-analysis of their style of management, including leadership and corporate culture. Check it out at:

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

MBA DAILY PRODUCTIVITY ANALYZER INTRODUCED

Also be sure to check out our new "MBA Daily Productivity Analyzer" which is a free calculator to evaluate a person's personal productivity during the day. It is also available at our corporate web site.

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

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

Its been a long time since the United States had twice a day delivery of our mail; now I'm lucky if I get twice a week mail service from our post office. We moved into our current offices about five years ago. We're located on the edge of the Dunedin postal territory and we're just less than a mile from the Palm Harbor post office (both Dunedin and Palm Harbor are in the Tampa Bay metropolitan area). This has confused our customers for a number of years. Whereas we are situated within the city limits of Palm Harbor, we're zoned for the Dunedin post office. Don't ask me why, they just do things a little different down here.

Ever since we moved in, I noticed our letter carrier would deliver our mail at his leisure. Some days we would get mail, some days we wouldn't. Its not uncommon for us not to see our letter carrier for several days. This became so irritating, we renting a post office box at the Palm Harbor post office which we can easily get to. The mailman still comes by at his leisure, usually late in the day. But a couple of years ago, he had an accident which incapacitated him. For several months he was replaced by substitutes who did a marvelous job of delivering the mail; they were prompt and actually quite pleasant. Well inevitably, our guy got better and returned to work and our regular mail service was interrupted again.

I've called the Dunedin post office a couple of times to talk to the supervisor and complain about our letter carrier's performance. He always comes to his defense and says it must be our problem, not the letter carrier's. In other words, he had no intention of correcting the problem. I guess the postal workers are a pretty tight fraternity.

All I can say is, thank God we've got the Palm Harbor post office box, otherwise we wouldn't get any mail.

Such is my Pet Peeve of the Week.

NEW eBOOK: THE BRYCE IS RIGHT!

Folks, we've just released a new book on management 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 just 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 new MS PowerPoint presentation describing both the book and the training program.

AND FINALLY...

I received an e-mail from an AC Kemper in Ohio who wrote me regarding last week's pet peeve, "How does the O.S. affect productivity?"

AC writes:

"I'm also surprised how people blindly follow Microsoft. Any time I talk about other products, all I get are blank stares. People think MS is the center of the universe and simply don't know there are other better solutions out there. BTW, I also liked your comments about VMS and OS/2; they were some very fine products."

Thanks AC for your note,

I like to call Microsoft the "Howard Johnson's" of the I.T. industry (with apologies to Howard Johnson's). They are never the best, nor the worst, just predictably mediocre, but they sure know how to sell their products. I always chuckle when I hear people describe Bill Gates as a technical genius; a Marketing genius, Yes, but a technical genius? Hardly. Microsoft's forte has been their ability to study market trends, understand the consumer, and manipulate the consumers' interests accordingly.

Having seen a lot of things over the years, I have never seen anything Microsoft has done to be "state of the art." As a small example, the upcoming release of Windows Vista is supposed to include speech enablement so you can issue commands to your computer. I'm sure we'll see a lot of marketing glitz over this feature alone. Nonetheless, speech enablement was included in OS/2 Warp version 4 ten years ago. Maybe MS will do a better job of selling the concept than IBM did.

And, Yes, I also enjoyed VMS. It was a great o.s.; industrial-strength, easy to use and learn, and had some incredible features. It was on VMS that I began to use e-mail and their e-telephone, which was back in the early 1980's.

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 © 2006 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

Wednesday, November 15, 2006

November 20, 2006

"TESTING 1, 2, 3..."

Have you ever noticed how poorly commercial software is being tested by the major vendors these days? I have. Normally, shoddy workmanship results in clients distrusting the products and vendors. Surprisingly, this is not the case in the IT Industry. Instead of holding vendors accountable by their customers, sloppy workmanship has become an acceptable form of behavior in this field.

Let me share with you the standard approach to testing as used by today's software companies:

1. Announce a general release of the product to the press.

2. Write a section of code and test/debug it.

3. Assemble the code and issue it to customers in "Beta" form.

4. Let the customers play with it and report problems as they occur.

5. From this, the vendor develops and prioritizes a punchlist of corrections.

6. The punchlist is addressed with the product delivery date in mind.

7. The first release of the product is issued with much fanfare (even though the punchlist has not been fully corrected).

8. More errors are reported by the customer base and added to the punchlist.

9. The second release of the product is issued as a fixpak. This release, in reality, represents the finished product.

The intent of beta code is more for public relations and publicity as opposed to delivering a viable product offering. Instead of thoroughly testing their products themselves, vendors let their customers do it for them. It shouldn't be this way.

I don't have a problem with the beta-test concept as such, so long as the vendor has legitimately tested the product themselves prior to issuing the release. They're not. Is it that they are incapable of testing it themselves? Maybe. Most likely though, it is cheaper to have outsiders test it for you. However, beta testing represents a disorganized test of the product. Something much more structured should be done prior to this by the vendor.

A SYSTEM IS A PRODUCT - THE "EXPLOSION/IMPLOSION" PROCESS

As we have discussed on more than one occasion in these bulletins, a system is a product that can be engineered and manufactured like any other product. Let's think about the design of a product, such as an automobile. The overall product is first broken down into a series of assemblies, such as the chassis, body, engine, drive train, and so on. Each assembly is then "exploded" (sub-divided) into subassemblies, and components.

After the product has been divided top-down into its assemblies, parallel teams of designers concurrently refine their portion of the product with little interaction between assembly design teams.

Parts such as nuts and bolts are carefully identified, classified, and reused not only within the product but with other products. One classic example of this is years ago when General Motors was able to slip a Pontiac Engine into an Oldsmobile. This demonstrated the power of standardization and reusability of parts.

After a product has been fully designed, the product assembly line "implodes" the product (bottom-up) with components making up subassemblies, and then the subassemblies into assemblies, and then assemblies into the final product. Again, think about the assembly line for automobiles where the pieces and parts of the car are built in smaller increments until the final assemblies are put together and the key is turned and the car is driven off the assembly line.

This approach to product design is obviously an old one, but it can be easily adapted to the design and development of an information system.

Under "PRIDE"-ISEM an information system is a 4-level hierarchical structure consisting of the system (representing the product) which is decomposed into sub-systems representing business processes. Each sub-system is divided into procedures (both administrative and computer). Administrative procedures are broken into operational steps or manual tasks. Computer procedures are broken into programs.

As in the product analogy, the system is designed top-down into sub-systems. Once this has been done, parallel teams of designers can work concurrently developing separate sub-systems.

When the final pieces and parts have been designed, they are developed and tested "bottom-up." For example, unit tests are performed on programs, a string test of the programs within a computer procedure is then performed; this is followed by a test of all of the procedures in each sub-system, and finally parallel testing of all of the sub-systems in the system is performed. If successful, the key is turned and the car is driven off of the assembly line.

The so-called "parts" of the system-product are the data components representing data elements, records, and files. Like product parts, the data resources should be carefully identified, classified, and reused not only within the system, but with other systems, thereby promoting integration.

The point is, like products, systems are designed by explosion (top-down if you will) and tested and implemented by implosion (or bottom-up).

TOP-DOWN TEST PLANS

The early phases of "PRIDE"-ISEM are primarily used to design the system into refined components. They are also used to specify the testing criteria for the later phases; to illustrate.

PHASE 2 - SYSTEM DESIGN - The Test Plan at this level will be used later in Phase 8 and should cover how parallel testing of the sub-systems should be performed. Key file maintenance sub-systems should be tested and installed prior to simple "read-only" sub-systems.

PHASE 3 - SUB-SYSTEM DESIGN - The Test Plan at this level will be used later in Phase 7 and should address human/machine interaction. Since inputs and outputs should be fully defined by this phase, the Test Plan should include:

- Design standards to be observed for Graphical User Interfaces and report layouts. This includes the use of Help text.

- Default values and validation rules for collecting data.

- Ease of use (intuitiveness).

- The processing of optional parameters.

- Verify the overall processing logic.

- Benchmark tests.

PHASE 4-II - SOFTWARE ENGINEERING - The Test Plan at this level will be used later in Phase 6 and should check operational dependencies between programs and stress testing. Input/File/Output layouts should be verified as well as volume testing. The assemblage of test data should be included.

BOTTOM-UP TESTING

The remaining phases in "PRIDE"-ISEM are used to test the system from the bottom-up.

PHASE 5 - SOFTWARE MANUFACTURING - Following the production of the executable program, the programmer assembles pertinent test data to test and debug the individual program. To do so, the programmer consults the Test Plan, Program Specifications, and pertinent Software Structure Diagrams resulting from Phase 4-II. This becomes the "road map" for testing the program.

There are a variety of testing and debugging tools available on the market. Use of such tools should be encouraged.

When the program has been tested to the satisfaction of the programmer, the results are reviewed with the computer procedure designer and Quality Assurance. This review assures that all standards have been followed, and the program has been tested to conform to specifications. The test data is saved for later reference and the test results are filed for future reference.

PHASE 6 - SOFTWARE TESTING - The purpose of this phase is to test and correct errors in the overall computer procedure. This is sometimes called a "string test," "job stream test," or "stress test." Whereas the "unit test" performed in Phase 5 was concerned with data format, the emphasis in Phase 6 is on volume testing.

It is the objective of the Computer Procedure Designer to assure that the procedure meets the sub-system specifications. In addition to testing for correct processing logic, they also check the operational considerations of timing, restart, etc.

Following testing, the results are reviewed with Quality Assurance and the Sub-System Designer. This assures compliance with all standards and that the Sub-System requirements are met. When the testing is satisfactorily accomplished, the test data is filed for future reference.

PHASE 7 - SUB-SYSTEM TEST - Testing in Phase 7 is performed in a similar manner as in Phase 6, except at a higher level. Whereas Phase 6 "Software Testing," is performed by Software Engineering for all of the programs within the computer procedure, Phase 7 is performed by Systems Engineering for all of the procedures in the sub-system, both administrative and computer.

During Computer Procedure Design, Software Engineering prepared the computer procedure that will be used by DP Operations. In order to test this procedure, it is recommended that DP Operations actually perform the tests under Software Engineering's direction. In this way, the operating procedures are tested along with the programs used to implement the procedure. Often the operating people will point out areas for procedure improvement.

During Phase 3, Systems Engineering specified a testing criteria for the overall sub-system. This included the validation of input/output processing, along with anticipated transaction volume for the sub-system. Phase 7, therefore, is used to verify the test criteria and benchmarks.

Following Phase 7, the sub-system is essentially ready for operation. However, considerable care should be exercised to avoid a premature installation of the sub-system for day-to-day operation. This situation could cause panic conditions if other parts of the system are not ready. This is why Phase 8 is used to release sub-systems.

PHASE 8 - SYSTEM OPERATION - A final test of the system is performed where the various sub-systems are tested in parallel. This is similar to the testing in Phases 6 and 7, but at the highest level. It is not uncommon to invite user personnel and DP operations to participate in the test. The Administrative Procedure Manuals and Computer Run Books, as created in the various Phases 4-I's and 4-II's, are used as part of the formal walk-through. The test data as created in previous phases is assembled and used as the basis for the test. Where available, actual data should be tested to simulate actual system situations. If any errors are discovered, they are corrected immediately and testing is resumed. Changes to the sub-systems may also be proposed; however, these should be considered carefully. In some instances, it may be more appropriate to suspend any modifications or improvements temporarily until use of the new system has settled into routine operation.

CONCLUSION

Whether you use our "PRIDE"-ISEM or not, the concept of defining refined levels of test plans "top-down", and performing corresponding tests "bottom-up" is a simple and effective approach. It offers a structure that is easy to manage and provides for a rigorous test of the system. Test data generators and debugging aids are useful and should be encouraged, but simple organization and a methodical approach to testing can have a more dramatic effect. Following this, if you still want to perform a beta test, you have my blessing.

Always remember this, most beta test programs are designed more for promoting the product as opposed to actually testing it. Think about it; its a "no-brainer" for the vendor. Customers begin to talk about the product while assuming the testing costs of the vendor. Even if something were to go wrong (and frequently does), the vendor is not liable and simply shrugs off the snafus due to beta code.

I used to beta-test software products for vendors, but I no longer have the time nor inclination to do the manufacturer's work for them anymore. Further, I no longer rush out to buy the latest release of "any" software product; I have been burned too many times by the vendors. As far as I'm concerned, the software vendors really need to clean up their act when it comes to testing. If they really want us to test their products for them, let us know where we should send the bill.

OUR BRYCE'S LAW OF THE WEEK therefore is... "Most beta test programs are designed more for promoting the product as opposed to actually testing it."

"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/

IN OUR "DOWN THE ROAD" SECTION

The Association of Management Consulting Firms will be holding their 60th Annual Meeting on December 6th-8th at the Harvard Club in New York City. For information, contact AMCF headquarters in New York at 212/551-7887 or visit their web page at: http://www.amcf.org/

If you have got an upcoming IRM related event you want mentioned, please e-mail the date, time and location of the event to timb001@phmainstreet.com

"BRYCE MANAGEMENT ANALYSIS" SERVICE

We've just introduced a new free service for managers to perform a self-analysis of their style of management, including leadership and corporate culture. Check it out at:

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

MBA DAILY PRODUCTIVITY ANALYZER INTRODUCED

Also be sure to check out our new "MBA Daily Productivity Analyzer" which is a free calculator to evaluate a person's personal productivity during the day. It is also available at our corporate web site.

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

MY "PET PEEVE OF THE WEEK" IS "HOW DOES THE O.S. AFFECT PRODUCTIVITY?"

I've seen a lot of operating systems over the years. I would have to say my favorite character based system was VMS which was used on the DEC VAX. Hewlett Packard's MPE was a close second. Both were reliable operating systems that ran well for a number of years. On the desktop, my favorite was IBM's OS/2 which was way ahead of its time. It was very reliable and ran smoothly. In fact, I've still got a few OS/2 based machines in the office that have run quietly and uninterrupted for many years.

Then we come to Microsoft Windows. I've watched it grow and evolve over the years, from version 3.x to Win95, 98, NT, 2000, XP, and now Vista is in the offing. As you probably know, I've never been a fan of Microsoft products. Having seen other platforms and knowing how other programs work, I know how primitive MS products can be. Unfortunately, most people don't. Nonetheless, MS remains the standard on the desktop and will be with us for a long time.

I've been using Windows XP for some time now and I like to consider myself a power user of the computer. During the average day, I'll be doing a lot of basic text processing as well as word processing, designing and updating web pages, desktop publishing, creating and updating spreadsheets and data bases, recording or listening to multimedia (these podcasts for example), scanning images and burning CD's, as well as extensively using the Internet, such as e-mail, traveling the web, FTP transfer, and VoIP. Its quite common for me to have many things going on at one time. So much so that people wonder how I keep track of things, but I manage. The last thing I need is an operating system that is going to slow me down.

Having seen other operating systems first hand, I felt a noticeable loss in productivity going into the Windows world. Not only did I find MS apps clunky and awkward to use, I found the operating system unreliable. Even now, I can count on Windows crashing or locking up at least once or twice a week, of course at the most inconvenient time during the day. I run backups regularly to cover myself as I have become very paranoid about all of this. Basically, I feel I am being restrained by Microsoft. And its not just me; I know a lot of people, both friends and business associates who are becoming increasingly frustrated with Windows.

This got me thinking about how Microsoft truly affects productivity in the office these days. If we do not have faith in the operating system, that it might crash and burn, this will affect our work habits. For example, instead of doing our job, we find ourselves doing many more "saves" and backups of important data; that we find ourselves waiting agonizingly for the computer to reboot, or waiting for a program to run while Windows struggles with multitasking and memory management. These little "inconveniences" add up and distract us from focusing on our job. In my small office alone, I estimate that at least 10% of our time is distracted due to the nuances of Microsoft products. Let's assume this 10% is correct and equally applicable to big business. This would mean Microsoft products are having not only an adverse effect on productivity in the corporate world, but it is also having an adverse affect on our economy as well.

I find Microsoft's television ads amusing as they portray their products as "State-of-the-art" and models of efficiency. To me, Microsoft does not improve productivity in the workplace, it is actually an impediment. Maybe they're right when they call it "Windoze" as opposed to "Windows."

Such is my Pet Peeve of the Week.

NEW eBOOK: THE BRYCE IS RIGHT!

Folks, we've just released a new book on management 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 just 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 new MS PowerPoint presentation describing both the book and the training program.

AND FINALLY...

I received an e-mail from a Bob Carlson in Los Angeles who wrote me regarding last week's essay on "Evaluating Purchased Packages."

Bob writes:

"I listened carefully to your November 13th broadcast and it all sounded good, but what you described sounded like overkill to me."

Thanks Bob for your note,

I guess its a matter of how much money you are willing to risk on a packaged solution. For small PC based apps priced at under $100, you probably won't do it. But for the major applications involving hundreds of thousands of dollars, or perhaps millions, it is hardly overkill; it is time well spent. In this industry, I have found there tends to be an inclination to leap before we look. Also, we're easily persuaded by facade as opposed to substance. All I was trying to point out by the essay is that there is a right way and a wrong way to evaluate purchased packages. So, is it really overkill? Hardly.

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 © 2006 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

Wednesday, November 08, 2006

November 13, 2006

"EVALUATING PURCHASED PACKAGES"

The use of commercial software products to fulfill all or parts of our Information Systems has been with us for some time. The 1970's marked the rise of such products, particularly in the banking industry. Now, thirty years later, you can find off-the-shelf software for just about everything from manufacturing, to order processing, to human resource management, etc. In fact, the trend (most notably in the United States) is to purchase commercial software and modify it for the nuances of the customer as opposed to developing whole systems internally. However, mixed results often occur. As one manager in General Electric recently told me, "My most recent experience, which is somewhat of a surprise, is that the new platform has less functionality than the 25 year old in-house system it replaced." In other words, his new "packaged" system now features state-of-the-art technology but doesn't adequately fulfill his business needs.

Nonetheless, commercial software packages can be a viable alternative for producing parts of an information system if applied intelligently. Whether to purchase a software package or build your own is often a difficult decision for companies to make. The purpose of this article is to provide evaluation guidelines when making this decision.

OVERVIEW

Packages are developed by vendors to provide general solutions to typical application areas and the package is usually described as being a complete information system. In reality, they are only tested computer programs or procedures that are sometimes accompanied by user procedures for input preparation. Because of this, the overall system, sub-system and administrative procedures may have to be added to convert a package into an information system before installation can be accomplished.

As with any other information system, the first objective must be to clearly define the business problem and information requirements. This sounds rather obvious but it is too often accomplished in a superficial manner. This problem is alleviated through the proper execution of "PRIDE"-ISEM Phase 1, "System Study & Evaluation."

During Phase 1, the project scope is defined, information requirements are specified, and a rough design of the overall system architecture is produced. When this is done, various approaches to implementing the system are now considered; e.g., build a new system, modify an existing system, purchase a package, or combinations of the above.

Failure to do this upfront work can come back to haunt a company. To illustrate, not long ago I was working with a major electronics manufacturing company in New Jersey who had purchased a Payroll system for a million dollars (which they considered cheap at the time). However, they had a devil of a time modifying it to suit their needs. Since they didn't properly define their information requirements or produce a rough design of what they wanted, this project turned into a nightmare. They ultimately spent another $2.5 million changing the package to suit their needs. Afterwards, they realized it would have been considerably cheaper to develop the whole thing in-house themselves.

HOW TO EVALUATE A PACKAGE

The first step for Systems Engineering is to determine the availability of packaged products to solve the business problem. A list of packages may be created by reviewing the advertisements in various trade journals and by checking with publishers which provide lists of available products. Most of the listing services provide descriptions of each package that assist in generally determining if the package covers the required areas.

There is a variety of publications that routinely prints product descriptions of various software packages:

* AUERBACH PUBLICATIONS (Pennsauken, NJ)

* CDW (Vernon Hills, IL)

* CompUSA

* COMPUTERWORLD'S BUYER GUIDES (Framingham, MA)

* IBM Products & Services

* PROGRAMMER'S PARADISE (Shrewsbury, NJ)

* PROVANTAGE CORPORATION (North Canton, OH)

* SOFTMART (Exton, PA)

Computer hardware vendors are also an excellent source for information about software products.

When the prospective list is completed, each vendor is contacted for sales materials. It will be helpful to provide each vendor with the project scope and information requirements, then ask that they demonstrate how their package fits your specific needs. Systems Engineering should also provide the vendor with a list of other questions to be answered. These questions should be as specific as possible so they will be easily understood and properly answered by the vendors.

It is important to discuss the business problem to be solved and the information to be produced. Avoid telling the vendor how the product should be programmed, defining techniques to be used and other such technical requirements. There are many ways of implementing software and being too specific in these areas may cause you to miss an excellent solution for evaluation. Since the vendor is in this business and you are not, it is possible they may know something you do not. Some junior or inexperienced analysts sometimes write specifications only to showcase their knowledge of a subject which in fact may be very limited.

Some suggested questions are as follows:

1. What business problems does the product address?

2. What documentation is provided for the User (Administrative Procedures), Systems Engineering (general systems documentation), Software Engineering (program documentation) and DP Operations (specific to the organization's hardware/ software configuration)?

3. Will the documentation provided be customized to meet installation standards?

4. What normal hardware/software configuration is required?

5. What is the cost of the product?

6. Does the package provide sufficient Data Base information to interface with other applications? If not, can they be provided and at what cost (if any)?

7. What education is required and the costs associated with this?

8. What materials or forms are required and the costs associated with them?

9. What changes to the product are required to meet the Information Requirements furnished?

10. Does the vendor provide modifications to the product or at an additional charge? If so, what type of modifications are typical?

11. Is there any maintenance or other on-going charge for use of the product? If so, elaborate on each specific charge.

12. Are there any other costs involved with installing and operating the product? If so, elaborate on each specific charge.

Also, has the vendor supplied a copy of the contract and a list of references.

A matrix or chart should be prepared by Systems Engineering to graphically compare the various packages strengths and weaknesses. The product criteria, product implementation and vendor evaluation should be one part of the matrix/chart while the vendors are the other. Then a grading scale is developed. In doing so, consider the possibility that some items may be more important than others.

Product integrity points to consider are:

1. Flexibility of product in application.

2. Integration with other applications.

3. Utilizes (or is adaptable to) organization standards.

4. Warranty.

5. Features.

Product implementation points to consider are:

1. Easy of use.

2. Not be an administrative burden.

3. Have wide acceptance in the industry.

4. Have an effective implementation program.

5. Easy to install.

6. Have organized reference and instructional materials.

7. Provide for vendor consulting to assure the proper use of the product.

8. Easy to maintain after initial implementation.

9. Have a standard bill of materials and services.

10. Have a well-defined maintenance program.

11. Have an effective "hands-on" training program.

Vendor evaluation points to consider are:

1. Have a good corporate reputation for reliability.

2. Have a professional attitude and a high credibility rating in the industry.

3. Reflect financial stability.

4. Provide for a staff with in-depth knowledge and background.

5. Provide for professional corporate facilities.

6. Be able to provide for a demonstration of the product.

7. "Practice what it preaches" - the vendor uses the product themselves.

8. Have an intimate knowledge of their products.

9. Be totally committed to the support of the product.

10. Provide additional services to support the product.

11. Easily accessible and available to its clientele.

12. Maintain effective communications with users.

13. Have long range plans for the support and development of the product.

14. Have long range corporate objectives.

After the materials are received from the vendors, Systems Engineering should carefully review all items provided. Delete vendors from the prospective list if their package does not even come close to satisfying the requirements. Then contact some of the references for the remaining vendors. When calling a reference, ask specific questions. Have a list of questions prepared before the call and carefully record the answers either during the call or immediately after the call is completed.

Some suggested questions are as follows:

1. Does the product perform as stated?

2. Did the vendor provide file layouts or do they have some other means to conveniently interface with the product?

3. Was the documentation as complete and correct as stated?

4. Did the product require more, less or about the same amount of modification originally planned?

5. Does the product require an inordinate amount of maintenance?

6. When a problem arises, does the vendor service the problem?

7. If the vendor services the problem, is the response prompt?

8. Who executes the required modifications?

9. Were there any problems encountered during implementation? If so, what were the problems, how were they resolved and by whom?

10. Is the customer generally pleased with the product?

11. Was the cost of the product as stated or were there hidden costs (elaborate)?

12. Would the reference allow your organization to visit their site to see how the package is operating?

After the preliminary investigation, the findings are reviewed, the list of prospective packages for further study is prepared and the matrix/chart is updated. Each of the remaining vendors is contacted and a sales presentation is scheduled. Each vendor should be asked to supply their documentation for evaluation, either privately or in the presence of their representative. It is often best to review the documentation with a representative present since questions can be answered as they arise.

One very important and often overlooked point to consider is in the Data Base area. A clear definition of elements is essential, otherwise, reports produced from the package will be meaningless. Quite often, the vendor's description is different from that of the purchaser, e.g., "ORDER DATE" could mean the date an item was ordered by the customer, the date the order was received, or the date the order was processed. There are three choices at this point.

Since the package is used to implement the system, it should be documented like any other system, hence it is a consideration in the selection process. The System, Sub-Systems, Procedures, Operations, Inputs, Outputs, Files, Records and Data Elements are required to be documented using the organization's standards.

When a sales presentation is scheduled, Systems Engineering should assure that all appropriate decision making personnel will be present. This group would include selected Users, the project team, Systems Resource Management, Data Resource Management, and DP Operations.

During the sales presentation, carefully review all of the material presented. Be prepared to resolve all possible questions during the presentation. After the formal presentation, carefully review the product documentation. Make use of the checklist to determine the completeness of documentation provided by the package and which components must be developed or supplements prepared in-house.

After the sales presentation process is completed, the findings are again reviewed and any unqualified packages are removed from the prospect list. Now Systems Engineering must evaluate which of the remaining packages will best fit the User's needs. It would be a good idea to have the users involved in this process and any presentations that are conducted.

When this process is completed, Systems Engineering and Project Management prepares a "make versus buy" comparative analysis. This becomes the basis for the purchasing decision.

When approval is received, the Purchase Agreement should be reviewed by the organization's legal counsel. Since this review process may take a reasonable length of time, agreements should be submitted for review as early as possible. Remember that the agreement must state specifically all of the items that have been agreed to by both parties. Most contracts state 'this is the only agreement between the two parties and all other agreements either verbal or written are not valid'. Obtain legal assistance with this part of the agreement preparation.

It is important that the agreement contain a complete "bill of materials and services" that accompanies the purchase of the product. This lists the specific materials that come with the product, e.g., manuals, forms, object code, source code, etc., along with the services provided, e.g., training and consulting. This list eliminates any confusion as to what exactly is to be delivered by the vendor and points out any hidden costs.

The package payment schedule should coincide with the delivery of the various parts of the package and the installation process. To assure the schedule is followed, the agreement should stipulate periodic review points where all concerned can discuss progress and assess project status. All of this may, on the surface, appear to be too much control, however, this is identical to the control expected for 'in-house' development.

As with any other newly implemented Information System, an audit should be executed to assure that the product performs as expected and the economic benefits are realized. The audit report should analyze the estimated development costs versus the actual costs.

CONCLUSION

The decision to purchase a package to reduce development time and costs, can produce satisfying results for a company if it does its homework and goes in with its eyes wide open. If it doesn't, disaster will inevitably follow.

Today we are hearing a lot about On-Demand computing and SOA (Service Oriented Architecture) to implement whole systems for companies. It all sounds nice but I do not see how it is any different than purchased packages. As such, companies should treat today's SOA solutions in the same manner as mentioned above. A package is a package, regardless if it is purchased "off-the-shelf" or implemented via a third party on the Internet.

OUR BRYCE'S LAW OF THE WEEK therefore is...
"An elegant solution to the wrong problem solves nothing."

"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/

IN OUR "DOWN THE ROAD" SECTION

The Association of Management Consulting Firms will be holding their 60th Annual Meeting on December 6th-8th at the Harvard Club in New York City. For information, contact AMCF headquarters in New York at 212/551-7887 or visit their web page at: http://www.amcf.org/

If you have got an upcoming IRM related event you want mentioned, please e-mail the date, time and location of the event to timb001@phmainstreet.com

"BRYCE MANAGEMENT ANALYSIS" SERVICE

We've just introduced a new free service for managers to perform a self-analysis of their style of management, including leadership and corporate culture. Check it out at:

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

MBA DAILY PRODUCTIVITY ANALYZER INTRODUCED

Also be sure to check out our new "MBA Daily Productivity Analyzer" which is a free calculator to evaluate a person's personal productivity during the day. It is also available at our corporate web site.

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

MY "PET PEEVE OF THE WEEK" IS "CAMPAIGN RHETORIC"

Boy am I glad the U.S. midterm elections are over. I never saw so much eye pollution as I did recently in the American television ads. I think I saw more attack ads than ads describing what the candidates actually stood for. There was more misinformation than anything else. So much so, that the public didn't know what to believe.

Something else that bothers me is the phrase, "I'll fight for you." This really hints at the divisiness of the country. Do we really need a lot of fighting or do we need some calm logical discourse to work through our problems? If you listen to the ads carefully, you would get the impression that America is at war with itself. Maybe we are and just don't know it.

Instead of the negative sound bites on the television and the spin by the media, I wish we had nothing more than a profile of each candidate listing their credentials, their record, and where they stand on the issues. It seems to me that the only ones that capitalize on today's campaign advertising is the media.

I also wish the media would keep their opinions to themselves and let the voters decide for themselves as opposed to influencing us.

Down in my neck of the woods, we have the St. Petersburg Times, a large and powerful newspaper. I don't agree with most of their editorials. Frankly, I think they are way out in left field. Nonetheless, prior to each election they publish a box in their editorial section listing their endorsements and recommendations for how we should vote. I dutifully cut this box out of the newspaper and take it with me to my voting precinct. It make an excellent reference for how to vote. Everything they recommend, I vote against.

Like I said, I'm greatly relieved the elections are over; now I can get back to watching all of the drug and car ads on TV.

Such is my Pet Peeve of the Week.

NEW eBOOK: THE BRYCE IS RIGHT!

Folks, we've just released a new book on management 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 just 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 new MS PowerPoint presentation describing both the book and the training program.

AND FINALLY...

I received an e-mail from a Martin Dimond in Ohio who wrote me regarding last week's essy on "Methods of Processing."


Martin writes:

"I am having problems digesting your concept that all processing involves the use of transactions. Can you please explain this further."

Thanks Martin for your note,

First, understand this, "transactions" does not mean old technology. We have been recording transactions well before the advent of the computer in such things as journals and spreadsheets. Basically, we're trying to record any significant event in a process. Perhaps the best way to think of a transaction is when we record product orders, shipments, and the debits and credits in a bank account. Interactive processing has clouded the issue somewhat, particularly in the area of graphics, multimedia, and video games. Nonetheless, they are all processing some type of transaction the moment we record the event in part or in full, be it a score, a sound bite, or a graphical shape, Not all transactions come in ASCII text form, some are done in binary.

Consider this, the concept of "Undo" would not be possible with the concept of a transaction.

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 © 2006 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

Wednesday, November 01, 2006

November 6, 2006

"METHODS OF PROCESSING"

As you travel around the I.T. industry, be it in a discussion group or attending a software conference, the general consensus is that all processing must be "SOA", "interactive" or "real-time"; and "batch" processing is considered passé. Is it possible developers are overlooking other more important and inherent properties of processing? Frankly, I believe we are more enamored with the slick terminology of the industry as opposed to having a clear understanding of how processing works. Let's consider how data is truly processed.

TRANSACTIONS

In the past I have described the generic structure of an Information System, such as sub-systems, procedures, and programs. Sub-systems represent business processes that exist in specific time frames, such as daily, weekly, monthly, or upon request. Basically, there are three types of sub-systems:

* "Maintenance" sub-systems are used to collect data
* "Display" sub-systems to reference data; and:
* A combination of "Maintenance and Display" to read/write to the data base.

Files associated with each sub-system are assigned in terms of how they are Created, Updated, or Referenced (C/U/R).

This scenario implies the use of some form of transaction, whether to request an output, or to input data to a file. From this perspective, a transaction is an exchange event from one object to another. A transaction always has some form of action associated with it. For output reporting, "request," "display," "print," "extract," "search," etc. are common transactions. For input, "new," "add," "change," "delete," "update," "charge," "credit," "debit," "deposit," etc. are typical transactions.

Over the years, transaction processing has come to mean "batch" processing as associated with 80 column records (anyone remember punch cards?), and typically relate to payroll, inventory or order processing. Not true. ALL processing involves the use of transactions, either one at a time (as in "interactive") or in groups ("batch").

What then becomes important is the volume of transactions and the speed they must be processed (as specified by timing). This will determine the physical constraints of the equipment to be used. "Batch" processing has the advantage of processing high volumes of transactions within a relatively short period of time per transaction. "Interactive" processing has the advantage of processing individual transactions quickly.

Some might argue there are exceptions to this rule, such as video games, graphics packages, screen savers, etc. Let's consider each individually: Video games write transactions to maintain player scores, graphics packages write a transaction every time you use the "Save/Cut/Copy/Paste" functions, and screen savers record preferred settings. All of these transactions must be written in specific formats. Understand this, if a program uses a clipboard or some other computer file, it is writing transactions to it. A program without any form of transaction serves no useful business purpose.

The tendency to be more concerned with the techniques of processing than with the problems to be solved can cause systems to be physically implemented in ways resulting in higher operating costs. The governing issues should be, "What is the business problem to be solved?" and, "How effective is the processing method concerning the value and timing of the information to be produced?" Programming techniques have little value in these areas. Consider, for example, that batch processing will always be a viable solution for information systems design regardless of the direction technology moves. This method of processing is analogous to many manufacturing operations where products are more economically manufactured in groups or batches - as opposed to one at a time. The point is, this situation will always be true regardless of how close the costs become between the two methods. For example, can you imagine preparing the corporate payroll "interactively" (one check at a time)? Technology should implement the logical business solutions to the problem and not be a platform to display technical elegance.

FORMS OF PROCESSING

There are three basic constructs for any processing, computer or otherwise (e.g., manual): sequence, iteration, and choice.

SEQUENCE - This type of processing represents a continuous series of steps, for example: we execute step 1 before executing step 2, before executing step 3.

ITERATION - Represents repetition until a certain condition is met.

CHOICE - Permits the selection of processing paths based on prescribed criteria. It also allows for parallelism.

Obviously, these processing constructs can be combined in many different ways to process data. All procedures, programs, and steps consist of combinations of these constructs.

TIMING

As previously mentioned, timing plays a substantial role in the design of a system, which is derived from the information requirements to be supported. Timing ultimately dictates when data is to be collected, stored, and retrieved. By using timing as a design parameter, we can synchronize the data base to serve all systems, not just one.

Timing (frequency, offset, and response time) dictates how often processing must occur, when each process is to start, and how fast it must process data. Without timing, processing will be awkward and cumbersome to perform. Since all business processes exist within a time frame anyway, why not use this as part of our design criteria from the outset as opposed to trying to synchronize the data base afterwards?

CONCLUSION

Transactions, processing constructs, and timing greatly influences the design of any process. For example, if a sub-system is needed upon request within a couple of seconds, then an "interactive" application is a likely solution. Conversely, if a sub-system is needed on a monthly basis to process voluminous transactions, then a "batch" process is a likelihood. However, if a sub-system is needed to process numerous transactions instantaneously, it may not be physically possible to do so (or practical).

All of this ultimately means the design of the process is ultimately based on the volume of transactions and the time required to process them. Buzzwords like "on-line," "real-time," "interactive," and "batch" only cloud the issue.

As an aside, it is interesting to see how such terminology has become a part of our vernacular. For example, the terms "on-line" and "off-line" really date back to the old days of computing. They were used to indicate whether a device was connected directly to a computer or not. As an example, the UNIVAC I had "off-line" card-to-tape and tape-to-printer devices. When the next generation was produced, the card reader and printer were connected directly "on-line" to the computer. Today "on-line/off-line" generally means if a person is logged on to a computer network or not.

But what is more important from a design point of view: our slick vocabulary or a true understanding of the fundamentals of processing? I think the latter. What do you think?

OUR BRYCE'S LAW OF THE WEEK therefore is...
"A program without any form of transaction serves no useful business purpose."

"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/

IN OUR "DOWN THE ROAD" SECTION

The Association of Management Consulting Firms will be holding their 60th Annual Meeting on December 6th-8th at the Harvard Club in New York City. For information, contact AMCF headquarters in New York at 212/551-7887 or visit their web page at: http://www.amcf.org/

If you have got an upcoming IRM related event you want mentioned, please e-mail the date, time and location of the event to timb001@phmainstreet.com

"BRYCE MANAGEMENT ANALYSIS" SERVICE

We've just introduced a new free service for managers to perform a self-analysis of their style of management, including leadership and corporate culture. Check it out at:

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

MBA DAILY PRODUCTIVITY ANALYZER INTRODUCED

Also be sure to check out our new "MBA Daily Productivity Analyzer" which is a free calculator to evaluate a person's personal productivity during the day. It is also available at our corporate web site.

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

MY "PET PEEVE OF THE WEEK" IS "TRAFFIC LIGHTS"

I'm sure a lot of you have a pet traffic light you abhor. Mine is about a mile from my office and I can always count on it to screw up traffic no matter what direction you approach it. It almost seems like my car has a homing device which the traffic light senses and changes the signal. I guess I'm getting a little paranoid about this. I don't mind stopping to await my turn in line, but I start to lose patience when a traffic light routinely stops me no matter what the circumstance is.

I wonder what sadistic mind programs the traffic lights? Sometimes I get the feeling someone has embedded a random number generator in the timer to cause the light to change erratically, either that or squirrels have nested in the main control panel.

Has anyone in the Transportation Department ever heard of motion detectors? I've got some simple motion detectors on my outside lights at home; they're cheap and work just fine. Wouldn't it be nice if traffic lights had motion sensors to keep track of traffic volume and adjust the timing of lights accordingly? That would make a lot of sense to me and do away with the problem that really burns me; that of coming to a four way traffic light where nobody is moving.

If you hear in the news of a Florida man shooting out traffic lights, you'll know I finally snapped.

Such is my Pet Peeve of the Week.

NEW eBOOK: THE BRYCE IS RIGHT!

Folks, we've just released a new book on management 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 just 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 new MS PowerPoint presentation describing both the book and the training program.

AND FINALLY...

I received an e-mail from a Kurt Davis in Cincinnati who wrote me regarding last week's Pet Peeve entitled, "Dude."


Kurt writes:

"I found your commentary amusing. Actually, I'm not surprised by the use of the word "Dude" as most of the young people are text messaging these days and have developed a new language."

Thanks Kurt for your note,

Yes, you are absolutely right. If you read some of the emails today, the younger people are using a new form of shorthand to communicate as expeditiously as possible. However, this shorthand can be irritating when you are addressing someone you don't know. Years ago, when I was in High School, we all took typing classes where we learned to write business letters. Unfortunately, the typing classes of yesteryear have been replaced by what is today called "keyboarding" and here the emphasis is on how to use the computer and a word processing package. Rarely, if ever, do the students learn how to type an appropriate business letter. This has resulted in a new generation of office worker who can move like grease lightning on the keyboard, but are at a loss as to how to address someone or construct a proper sentence. Spell-checkers and grammar-checkers are nice, but is anyone using them? I wonder.

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 © 2006 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