Niwot Ridge Resources
A Source of Information for Mission Critical Software Systems, Management Processes, and Strategies
The following publications are available for downloading. These documents represent the work product of Niwot Ridge Consulting. Some are conference papers, others are works produced for clients (then edited for publication), and others are provided for your reading enjoyment.
Designing, managing, and deploying successful software projects is one of the most significant challenges encountered by modern business organizations. Never before has Information Technology (IT) played a more important role in bringing competitive advantage to an organization. Yet, IT has never before been more complex. In the past, the mainframe paradigm provided turnkey solutions to complex business problems. The functionality was provided by the software vendor, which may have also been the hardware vendor. The business processes were adapted to this functionality. As these processes evolved it was discovered that the systems were not sufficiently flexible or adaptable to meet the new demands of business. The introduction of distributed processing provided a means to deal with the inflexibility and monolithic nature of these legacy applications.
The use of an architecture–centered development process for delivering information technology began with the introduction of client / server based systems. Early client/server and legacy mainframe applications did not provide the architectural flexibility needed to meet the changing business requirements of the modern manufacturing organization. With the introduction of Object Oriented systems, the need for an architecture–centered process became a critical success factor. Object reuse, layered system components, data abstraction, web based user interfaces, CORBA, and rapid development and deployment processes all provide economic incentives for object technologies. However, adopting the latest object oriented technology, without an adequate understanding of how this technology fits a specific architecture, risks the creation of an instant legacy system.
The role of Risk Assessment and Risk Management is to continuously Identify, Analyze, Plan, Track, Control, and Communicate the risks associated with a project. The Webster’s definition of risk is the possibility of suffering a loss. Risk in itself is not bad. Risk is essential to progress and failure is often a key part of learning. Managing risk is a key part of success. This document describes the foundations for conducting a risk assessment of a large-scale system development project. Such a project will likely include the procurement of Commercial Off The Shelf (COTS) products as well as their integration with legacy systems.
Strategy is creating fit among a company’s activities. The success of a strategy depends on doing many things well – not just a few. The things that are done well must operate within a close nit system. If there is no fit among the activities, there is no distinctive strategy and little to sustain the strategic deployment process. Management then reverts to the simpler task of overseeing independent functions. When this occurs operational effectiveness determines the relative performance of the organization.
Component-based software development introduces new sources of risk because (i) independently developed components cannot be fully trusted to conform to their published specifications and (ii) software failures are caused by systemic patterns of interaction that cannot be localized to any individual component. The need for a separate exception handling infrastructure to address these issues becomes the responsibility of the exception handling subsystem. COTS components focus on executing their own normal problem solving behavior, while their exception handling service focuses on detecting and resolving exceptions within the local COTS domain. The exception handling architecture of the integrated system is realized by adding exception handling logic to each application component using a middleware approach.
Catching errors at compile time is the ideal. The rest of the problems must be caught at run-time through some formality that allows the creator of the error to pass appropriate information to the recipient to know how to handle the error. A layered approach to detecting and resolving exceptions provided an incremental deployment strategy that allows exception handling to be added to the application components in small increments, without disrupting the existing code base.
This paper will be presented at the Winter OMG EAI Workshop in Orlando FL.
Managing the outcome of an ERP deployment is difficult at best. There are many obstacles to success, the least of which is the basic understanding that accepting an ERP system into a business is a significant disruptive event. This document describes the processes and activities involved in deploying ERP. The contributions of a consulting firm can significantly add to the probability of success. In the newspaper business domain, the successful deployment of an ERP system not only impacts the backoffice and financial operations, but also the editorial, advertising and press operations. ERP is a mission critical function of any modern newspaper and must be treated as such.
Nowadays we are seeing a number of technologies emerging in the construction of software for the publishing industry. One technology that is gaining interest from the publishing world is the use of component technologies, with CORBA and EAI as the means of assembling these components into a complete system. This a summary of a presentation given at a recent IPTC meeting.
This paper is a reissue of a work I produced in 1989. This work describes the mathematical deatils of the analysis of a Triple Modular Redundant (TMR) process control computer's diagnostic system. This paper was used in the submission of this computer to the TÜV and SINTIF agencies for certification of its use in the North Sea drilling platform environment, where an uncommanded output (non fail safe output) can occur only once in 10,000 years of operation. (This paper is being updated, so many typos or poor grammar will have most likely have been corrected.)