(Trends) No, we are not there yet… And probably never will be…

In the Information Technology field we never seem to have accomplished a task before we are rushed off and moving onto another one. We are always evolving. The question is though, “Where are we going?”.

Years ago, the strategic directions of corporations were to automate as many of their processes as possible and as soon as capable. Once, they were automated, we then had to concentrate on refining the new infrastructures and then finally, efficiency, all done along with the massive but interim changes in technology. Now that we have concentrated on efficiency we seem to have run smack into the wall of complexity at full speed. The reason for this is that corporate management directions have often taken similar paths as those promoted by many Pentagon weapon analysts… which is simply a belief in the idea of “We’ll do it with technology…” and that is about as far as upper management comes to understanding what is involved besides the costs… which are always being sought for reduction.

True weapon analysts understand that to develop a weapon it has to have a corresponding weapon to be applied against. The classic example of this situation was the building of the F-15 Strike Eagle Interceptor. We all know this plane as the long standing heavy hitter of the US Air Force. However, it was not always so. The F-15 was actually designed with the strict intention of taking on the Soviet Mig 25 Foxbat which in turn was designed to counter the US XB-70 Valkyrie high altitude bomber (1970s).

The Foxbat was a lightening, fast fighter and could outpace anything the US could throw at it when it first arrived on the scene. Thus the F-15 was born which housed some of the most powerful jet-engines ever designed. It soon caught up to the Foxbat’s speed advantage. But then something happened philosophically in the world of American weapons design. With the XB-70′s failure to be implemented (two of the prototypes crashed and all of them had trouble landing destroying the existing landing-gear assemblies each time), the US turned to low-altitude bombing with the inception of the B1 bomber.

Gone was the Mig 25′s reason for being and so to was the life expectancy of the F-15 as it was. Hence, without an enemy, the F-15 had its engine’s detuned and was re-introduced as a heavy fighter.

Because the F-15 was such an excellent design it could accommodate the role-change quite nicely but the Mig 25 couldn’t adjust as well since it was designed for straight-line, high-speed attacks on bomber formations. However, its glaring weakness is that it couldn’t perform high-speed, tight, right turns without shearing it’s wings off.

American management unfortunately has tended to follow the same analytical impulses of these early Soviet aircraft designers; matching weapon for weapon, with narrowly focused design implementations. However, over the years new forms of weapons analysis was required which eventually gave birth to the excellent Mig 31 and the highly flexible, wondrously designed Northrop “F-20 Tiger Shark”. In turn, and up to a point, corporate management has attempted to follow similar trends in terms of organizational infrastructure designs for corporate IT departments but with less success. Much of that innovation came from organizational analytical gurus Deming and Drucker who first found no interest in their theories by American management.

F-20 Tiger Shark – The Most Advanced Aircraft of its Kind in 1991

Nonetheless, the F-20 Tiger Shark was a business man’s dream come true had the design and project infrastructure concepts been applied to corporate IT organizations. The F-20 was a multi-role fighter capable of serving the US Navy, Air Force, and Marines all at once. The plane was capable of inteceptor duty, ground-support, and wide-sweeping electronic survaillence over a 1000 square-mile area all with the requirement of only a single pilot. Maintenance was only 14% of that compared to the F-16 fighter and the resultant up time was 70% higher. Furthermore this beautiful aircraft was much less expensive than the F-16 to build, procure, and incorporate. The entire project cost was approximately $800,000,000 USD and it was completely paid for by the Northrop Corporation with the expectation that there would be large-scale selling opportunities. There should have been but Reagan broke his pledges to Northrop which involved promoting the plane to foreign clients while US forces barely batted an eye at the possibilities. Everyone, simply didn’t want to be bothered changing to a new technology that would in essence close down many of the pipelines that so many defense companies were relying on for their bread-and-butter. In short, even the capabilities of the F-20 along with the prospective savings was not enough to wean most of the weapons corporations off their gravy trains. Unfortunately, this same short-sightedness was followed true to form in most American corporations… and not suprisingly, still does.

The result of these trends has been from the standpoint of most analytical observers of corporate IT organizations that the corresponding strategic directions for these areas have been more or less similarly focused with limited foresight. The results have been in total, a serious case of multiple, disparate implementations many at cross-purposes with each other and practically all with poor review and oversight. One of the the worst cases reported of this situation in the financial world was in the 1990s during a study of several major New York banks’ IT departments. Here it was found that systems control was so poor that a good portion of the running applications had no corresponding source-code.

Thrown together at increasing speeds with degenerating disciplines since the 1990s, American development processes are fast becoming ever more incoherent while maintenance projects don’t even rate a tick on the charts. The subsequent result has been systems of limited capability, flexibility, and as a result, life expectancy all evolving from a patch-work set of requirements all falling under various lifecycle frameworkes that are only used to the extent that it appears as if disciplined protocols are being followed. Though this may appear fine on paper, the story down in the “trenches” is most often a completely different case. This is all very similar to the limited design strategies of the Mig 25 when business keeps demanding the elegance of the F-20. It simply can’t happen without management understanding Information Technology beyond it being a cost-center.

Of course, all of this can be easily blamed on unknowledgeable management whether they be at the top of the ladder or down near the trenches where the technical staff is. And many articles in the technical journals have contributed unrelenting in this vein. Senior or upper management does in fact have a large share in the responsibility in all this. For starters, they are often very unknowledgable about most things outside of their narrow focus on their business and know little if anything about what is really going on beneath it. This comes from all of the layers of management that is usually “featherbedded’ into many corporations. Further, much of corporate management has little comprehension of the extensive technical knowledge and capabilities that are required to implement the technologies that support their requests. What is worse is that for the most part they simply don’t care. Had management such knowledge they would be quite hesitant with their attempts to turn many career technicians into business analysts with the subsequent technical tasks being downgraded to nothing more than a commodity status all with the intent towards saving money. The sloppiness of the implementations at the technical levels is testament to the results of this trend along with the subsequent outsourcing.

The resulting chain-reactive result is that lower level technical managers follow the examples set by pushing technicians to do more with less since they themselves often have little recourse but to work within the limited project development criteria offered to them mostly the result of limited budgets.

The only remedy for such situations is for technical staff to reapprise the original role of IT departments which were not only development centers but acted as gate-keepers to the multitude of incoming requests. Here the longer term concerns that should be a part of every technician’s mindset could become a brake to the many rush-to-build responses that more often than not create cumulative, detrimental situations within production processes. However, with increasing competitive pressures rising daily, the only result that many can concentrate on, similar to the concerns of immediate management, is “just getting the job done” for fear of losing a job.

Today, if a user needs something ASAP, everything is dropped to get the job done with the idea that that the user’s request are always dominant since it is related to the company’s bottom-line. If a new system is to be developed, most design processes are so ad-hoc that little if any consistency is evident owing much to the lack of formalized tools to assist in such endeavors. Maintenance requests are simply thrown about like so many chores to be done with a sense of urgency that is a result of poor planning and control. Documentation efforts are made so mundane and tedious that one of the most vital aspects of software development is left as an after-thought. The result of this last is that in most cases true technical documentation is non-existent leaving training of new project members to that of a level of tribal story-telling as information is passed down the employee generations on the staff. The best that technical management has to offer is often to request that existing code be reviewed along with table definitions on a corresponding database. Without the technical “why” or “how” of anything the “what” becomes somewhat irrelevant.

For all the creative talent that still is within the technical areas, corporate IT departments have been reduced to nothing more than assembly-line processes, which for most of the brightest technical personnel, simply creates terrible situations of boredom with little hope of more interesting endeavors. So as management attempts to make things more efficient on paper the exact opposite results are being created in the very areas where creativity and quality should be flourishing.

To accommodate this up-tick in development and task-completion speed one would think that better protocols would be put in place to accommodate such requirements realistically and make technical tasks more efficient to implement. Instead most companies, have horrendous auditing tools to detail every one of a developer’s actions and requests both of which add enormous amounts of time and even confusion to what should be basically easily used methodologies.

Management should get a good dose of working with the systems that they foster on their development staffs and be exposed to having to deal with the multiple organizational infrastructures simply to get anything accomplished beyond the project team. They wouldn’t be so much in the dark as to what is actually going wrong in the levels below them.

Today’s level of technical complexity and incomprehensibility is not only a result of the increasing demands placed upon the shoulders of career technical personnel but also a result of the changing nature of American society. Shortcuts are taken more often in speech patterns which mirror the way people are beginning to interact with each other in other venues. Take email for example; entirely new ways of constructing sentences out of daily lingo instead of explicit structures is becoming more commonplace in personal lives. Lower thresholds of literacy are being accepted as the norm as a number of reports have already demonstrated. Concerns over competencies are being raised throughout the American educational system as a result of corporate concerns for competitiveness. On top of this, employment markets are undergoing constant trauma from the changing priorities and necessities of large corporations all attempting to refine themselves to be able to maintain parity with the competition. And all of this comes down the tubes into the technical divisions that are trying to cope with greater ambiguities while attempting to incorporate ever more precision into their results. The task is simply impossible.

The result for most companies is that where they have arrived is at a juncture where their software development areas are subsumed with… let’s be blunt here… junk! Just pick up any good technical journal and on any given day you can read about the immense technical problems plaguing corporations from security vulnerabilities, to vendor issues, to the search for better ways to implement systems development.

Intertwined with all of this is the constant emphasis on careerism both at the existing management levels and within the ranks of IT personnel who have no desire to remain at the “bits & bytes” levels. Emphasis on careerism has all but destroyed the cohesiveness of the US Armed Forces in the upper echelons. And though the understanding of the results are well known, the “up or out” mantra for military officers is still pretty much the existing prospect for most of them. American business has not been immune to such sociology and it has caused as much havoc within IT as outside of it.

Inside IT few are any longer proud to be career technicians who understand the scientific nature of their work. Why should they be when management is constantly reminding them that they can be outsourced since technical work is nothing more than a commodity item? And yet they are expected to produce high quality technical results under a shamble of contradicting situations with growing levels of ambiguity in their interactions among each other.

There is simply no such thing as developing at high rates of speed with a high sense of accuracy without strict disciplines in place that are part of clearly demarked organizational infrastructures which has task development that is modularized enough to allow for such implementations. This has in fact been accomplished by such companies as British Telecom that has completely re-oriented its entire software development divisions against high-speed development. However, to do that, they have had to redevelop their way of thinking about development along with their methodologies. This “Just get it done!” attitude simply has no way to survive in such an environment. In essence, companies like British Telecom have taken to the design concepts of the F-20 while many companies in the US are still suffering with the way the Mig 25 was implemented.

see… http://www.cioinsight.com/article2/0,1540,2090741,00.asp?kc=CMCIOEMNL020707EP18

Unfortunately, many American firms are simply not prepared to handle software development in such a manner since there is as of yet no conception as to how to slow things down to speed them up; a paradox in systems development that has proven itself over and over again in the past 30 years. In many industries most personnel work as if they have blinders on with only a slight opening that has dollar signs always in full view. If this weren’t the case, there would be a lot more discussion concerning process improvement models such as CMMI and others and less concern over what is constantly going wrong with the software development process.

So the question remains, “Are we there yet?”… Is American business at the point where it can look at their systems and see a set of extensible, well designed components and services interacting with each other that can support the long-term needs of American corporations?… No they aren’t and if they don’t begin incorporating quality software development principals along with clear organizational structures in IT that also provide secure career paths for technical personnel and better tools and methodologies to accomplish their tasks with they never will be… but someone else will…

Steve Naidamast
Black Falcon Software, Inc.