Whenever I'm asked to discuss the subject of Information Systems in the corporate world, I am inevitably asked, "Where does the programmer fit in?" I think this is an odd question as I see programming as only a small part of the overall puzzle. People are startled when I mention this, particularly programmers, who tend to see themselves as the center of the systems universe. I counter by asking, "What exactly does a programmer do?" After much discussion, we end up with the same answer, "a programmer takes human understandable specifications and converts it to a machine executable program, either by writing and compiling source code or through some interpreter capable of generating the program." This, in turn, leads to an interesting discussion as to what is meant by "requirements" (it seems everyone has their own spin on this). More importantly, it leads to a discussion as to what exactly a system is.
I like to follow this by posing the question, "How many programs make up a system? One? Two? Three? Is a suite of programs a system?" Again, after much discussion we conclude there is no finite number of programs in a system, it is as many as satisfies the system's needs (and again we're back to "requirements").
I finally ask if a system can be implemented without computer assistance (without programs). The programmers typically balk at this one, but grudgingly admit an information system can be implemented manually or through the use of other equipment. Actually, information systems have been used for hundreds of years, well before the advent of the computer. As one of our more famous Bryce's Laws points out, "The first on-line, real-time, interactive, data base system was double-entry bookkeeping which was developed by the merchants of Venice in 1200 A.D." In other words, computer programming is but one way to implement an information system, but certainly not the only way. This premise implies information systems are much larger in scope than programming, and that systems have two dimensions, a logical side and a physical side. The logical side defines the various business processes comprising the system (aka, "sub-systems"). These processes can be implemented through manual processing, use of other equipment, with computer assistance, or combinations of all three. The physical processing changes more dynamically than the logical simply because technology changes.
To pull this all together requires a type of person more knowledgeable about the business than about computers. Historically, this type of function has been referred to as a "Systems Analyst" or more recently a "Business Analyst." Regardless, the analyst is a precursor to the programmer. In the absence of an analyst, programmers must try to understand the overall system architecture, a talent they are not necessarily well versed in.
The day a company starts its business is the day when its systems are born. Even a company in name only requires systems support in order to report to the government on their activity (or inactivity). As businesses begin, a "natural" system is devised whereby work is distributed among employees, hopefully in a cohesive manner. Without orchestration though, there is a tendency for the natural system to develop inconsistencies and redundant work effort, particularly if the business blossoms. Data duplication is unavoidable thereby causing inconsistencies in information. If the information is "dirty" inferior business actions and decisions will ensue thereby causing an adverse affect on the company's bottom-line.
The point is, no amount of elegant programming can solve a system problem without someone who understands the overall system architecture, someone who understands how the business works. Attacking systems development without such orchestration, such as one program at a time, will not produce the desired results. That would be like trying to build a bridge without a set of blueprints; it would probably be disjointed and one end would likely not connect with the other in the middle. I for one would not want to travel across such a bridge. Yet, this is precisely what is happening throughout corporate America today. If we built bridges the same way we build systems in this country, this would be a nation run by ferryboats. If you consider how counterproductive it would be to try and build a bridge without a set of blueprints, you get a good idea how counterproductive a lot of systems development organizations are. A lot of time and money is lost simply trying to deduce what is to be built in a concerted manner.
It is the Analyst's job to understand the business, not the programmer's.
It is the Analyst's job to develop and maintain the system architecture, not the programmer's.
It is the Analyst's job to develop the specifications for programming, not the programmer's.
It is the Analyst's job to develop the data specifications for the Data Base Administrator, not the programmer's.
And it is the Analyst's job to test and install systems, not the programmer's (although they should be performing unit and string tests of their software prior to system tests).
Programmers should be consulted to review the feasibility of a system design, but make no mistake, it is up to the Analyst to develop such plans. And if the Analyst performs his job properly, he will greatly simplify the life of the programmer, thereby making that person more productive. Regrettably, corporate management has little appreciation for the Analyst's duties and responsibilities. Consequently, the Analyst is pressured to short stroke his work effort and turn it over to programming prematurely, thereby causing the programmers to act on poorly defined specifications which inevitably results in project delays and increased development costs.
So, is the tail wagging the dog in your company or the other way around? Do you have a sufficient number of Analysts to properly design systems before turning the specifications over to programming? Consider this, if done properly true programming should take no more than 15% of your development time and costs. If you are expending more than this, I suspect you do not have enough Analysts.
Remember this, anytime you have a systems development project involving multiple business processes, multiple people, and multiple programs, you damn well better design a system architecture first.
Keep the Faith!
Note: All trademarks both marked and unmarked belong to their respective companies.
Author: Time Bryce
Tim Bryce is a writer and the Managing Director of M. Bryce & Associates (MBA) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at [email protected]
For Tim's columns, see:
http://www.phmainstreet.com/timbryce.htm
Copyright © 2011 by Tim Bryce. All rights reserved.