Business Cycle

Systems with feedback loops can have complicated, difficult to predict behavior. However, there are three basic varieties of simple feedback loop, and understanding these three types can lend insight into the behavior of more complicated loops.

The first type is positive reinforcing. These loops runaway in one direction forever, until something in the system changes and the dynamic is allowed to breakdown. The classic example is the runaway population growth of bacteria in a petri dish.

The second type is balancing. This kind of loop is characterized by equilibrium among opposing forces. It takes effort to push these systems away from their natural equilibrium point, and they tend to fall back again once the effort stops. However, they can be complicated by having multiple points of equilibrium.

The third type of feedback loop is oscillating. This is essentially a special version of the balancing type of feedback loop. As with the balancing type there is a force and an opposing force, but in this case the opposing force has a delayed response. As a result the system swings from one extreme to another, like a pendulum, as the system is dominated first by one force and then by the other. Aviators may refer to this behavior as PIO - Pilot Induced Oscillation. If there is a delay between when the pilot gives an input to the control surfaces and when the aircraft responds then the pilot will tend to give too much input and then over-correct, sending the plane into a potentially fatal oscillation. In a way, the PIO acronym puts too much blame on the pilot as this problem is really a result of the system dynamics.

I think the business cycle is the result of an oscillating feedback loop in the economy. Not much of an insight really, except that it implies that there is something structurally wrong with the economic system. Left to its own devices, the system will keep exhibiting this behavior.

The story I was taught in high school economics was that the Fed had been established to interrupt this oscillating behavior, by anticipating it and correcting for it. I was told that the Fed had been enormously successful in that role. I'm not sure that was true.

Can there be a market solution for bubbles and the Business Cycle?

Emergence

Like my good friend Justin, I'm looking for some advice on grad school. I'm currently in progress toward a Master's of Engineering in Systems Engineering, and I'm thoroughly enjoying the program. I want to pursue a PhD next, but I'm not sure what kind of program I want to enter or where I'd like to go to school.

My goals in pursuing a PhD are as follows, though not necessarily in this order:

• Learn and grow and enjoy my studies.
• Learn how to do, and actually do, meaningful research. 
• Meet more people who are both intellectual and practical - people who care about results as well as ideas.
• Increase my career choices - this is not about money, it's about being able to do work that is meaningful and significant.

My primary interests are in the concept of emergence (how organization emerges from complexity), and in how to engineer emergence. That's very broad with applications ranging from public policy, to international development, to organizational management, to the design of transportation (or other) systems.

My question is, which programs at which schools are most likely to help me achieve my goals, and allow me to study and do research relating to the engineering of emergence? The way I see it, there are many kinds of programs that touch this concept at least tangentially, and any of those might work for me as long as I was given a measure of freedom to emphasize my interest. And there are a few programs that either directly approach the topic of emergence (for example, the Systems Science program at Portland State University), or provide tools that are pertinent (economics, probability, etc.).

Where I go to school matters for a lot of reasons, but most importantly because of the second two items on my bulleted list above. I want to work with high quality people and I want my degree to open doors for me. That said, there are some boundaries that I would like to stay within (though I'd consider going beyond them for the right program or the right school). Ideally I would like to stay in the western U.S., and I have a strong preference for the Pacific coast states. I'd also like to avoid the Los Angeles basin if at all possible (but I'd go there for the right program).

What insights do you have into schools, programs, and faculty that might be useful to me? What cautions can you provide about whether or not pursuing a PhD is likely to help me achieve my goals?

Modularization of Systems

1.       Define the system requirements.

2.       Select a system concept. A system concept is a well-developed description of how the system will achieve its function.

3.       Map the system as a set of discrete functions.

4.       Decide the level of modularity at the system level – which functions will be packaged together into one module, and which will singly form a module. Module designers may opt to further modularize below their level in the design, as expedient.

5.       Define each module in terms of its inputs and outputs.

6.       Define minimum performance requirements for each module.

7.       Define all of the inter-module interfaces, and create an Interface Control Document (ICD) for each interface. Remember to include serviceability in interface design. Interfaces must be designed in accordance with the performance requirements for the associated modules.

8.       Define the interfaces between the system and the external environment, including users/operators and other systems. These interfaces to the external environment may be modules in their own right.

9.        Define limits for each module’s physical envelope (size and shape), thermal properties, electromagnetic properties, emittance/effluence, and resistance to environmental factors (moisture, vibration, dust, heat, exposure to radiant energy, bumps and rough handling, etc.)

Modularity

Modularity is a powerful concept. There’s more in it than is immediately visible.

In this very interesting paper, the authors argue that a poor understanding of the implications of modularity nearly killed IBM. IBM created a modular computer because the modularity made it easier for them to manage the design process. But IBM’s executives failed to recognize that a modular design makes it possible to experiment with many more system configurations, at low cost and with low risk. They didn’t leverage this advantage of modularity but their competitors did, and quickly found that there were many ‘flavors’ of IBM compatible PC that were possible and desirable.

The modularization of the design of the computer led to a rapid decentralization of the computer industry, and a corresponding increase in innovation and growth in market value. IBM lost market hegemony and nearly disappeared altogether as hundreds of new specialist firms sprang up, each producing modules rather than entire computer systems with unique architectures. No single firm has ever come near to the market dominance once enjoyed by IBM.

Modularization is made possible by the creation of standardized system architectures, with design rules and interface specifications. Standards are a first step toward modularization. Open standards and open system architectures make it easier and less risky to innovate. This opens the door to massive competition.

There is a tradeoff that modern technology companies face: Use proprietary standards and tightly-bound system architectures to avoid competition, or use open standards and modular designs to enable rapid innovation and free support from your competitors (in the form of their innovations that make your products more valuable), but risk being eaten alive. I think the obvious answer is that with complex systems the benefits of modularity and open standards are so great that the proprietary model is not viable in a competitive market. Even well-funded and powerful firms simply cannot compete in innovation and quality with the huge and dynamic markets that grow up around a good open architecture. That’s why Apple computers are now being built from IBM compatible parts.

Systems Engineering - A Description

Systems Engineering is a structured approach to the development of complex, engineered systems.

The Whole System Approach

·         Top-down design, optimizing for system effectiveness not necessarily component effectiveness.

o   E.g. Metallic structures on spacecraft can magnify radiation hazards. Metal may be the best choice for the frame component, but may not be the best choice for the system.

·         Design the right system.

·         Systems design is inherently interdisciplinary. Systems Engineers must possess and cultivate broad technical knowledge.

·         Manage subsystem interactions.

Project Management

·         Manage cost, resource utilization, and scheduling constraints from an engineering standpoint.

·         Collect voice of customer, communicate with stakeholders, manage and coordinate suppliers.

·         Prepare and maintain a current Systems Engineering Management Plan (SEMP) as the primary controlling document for all system development activities.

The Iterative Design and Evaluation Method

·         The Systems Engineering method is an iterative process by which a system concept is developed and refined with continual evaluation against requirements, until a completed and functional system design is produced that meets the goals established for the system.

• The steps in the Systems Engineering method include:

1.       Develop system performance and cost requirements.

2.       Develop multiple system concepts that can satisfy most or all of the requirements.

3.       Select a concept and begin the design/evaluation loop.

a.       At the outset of the design/evaluation loop, the system concept has poor definition. Each pass through the loop increases the detail of the design.

b.      Also, at the outset there are many risks and unknowns. As the detail is added to the design, frequent evaluation of the design through testing and simulation identifies problems that are then corrected in subsequent design iterations. In this way risk is diminished on each pass through the loop

c.       The design/evaluation loop concludes when a system design that satisfies the performance and cost requirements is complete, and when all risks relevant to the design have been abated or effectively managed.

4.       Produce and implement the system.

Risk Management

·         Systems design carries risk inherently. Consequently, risk management is an important part of the Systems Engineering method.

·         Some common systems risks are:

o   Interdependencies between subsystems magnify effects of point failures.

o   Complex system behavior may be difficult to model or predict (greater than the sum of its parts).

o   System dynamics are strongly characterized by bottlenecks, load variations, and feedback loops.

o   New failure modes arise due to novel design, new technology, or increased complexity.

Interface Design

·         The Systems Engineer (or team) is wholly responsible for the specification and design of interfaces.

o   Create and maintain current Interface Control Documents (ICDs) for all system interfaces.

·         Interfaces carry material, information and energy between components. Interface types include:

o   Mechanical

o   Electrical

o   Data

·         Interfaces are loaded junctions exposed to hazards from more than one direction.

·         Interfaces are sensitive to peak loads, and are natural bottlenecks that can limit system performance.

·         Interfaces can be the source of unintended feedback loops.

·         The more complex a system is the more critical interface design becomes.

UPDATE - Presentation available here.

Systems Engineering

The New Hampshire Business Review is reporting that the University of New Hampshire will begin offering a certificate in Software Systems Engineering. From the article:


“Engineers who are successful at this ‘big picture’ work are rare, yet the demand for these skills is high...”


I think this is exactly correct, and not just in software design. Systems Engineering is one of the few academic disciplines, and the only engineering discipline, that is moving toward greater generalism. The increasing depth of technological knowledge has driven specialization at an increasing rate, and at a heavy cost to technical breadth. Additionally, the increasing specialization has tended to drive natural-born generalists from the ranks of those who pursue engineering degrees. The result is a serious lack of interdisciplinary competence and large world view that is essential to the complex engineering projects that are driving civilization's next big developments. Think of the projects to re-engineer energy production, to redesign cities and transportation at a conceptual level, and even to engineer society and government for the improved welfare of all citizens (we desperately need Economists to start thinking of themselves as Engineers - specifically Systems Engineers - and not as Scientists). 

The emergence of Systems Engineering is a direct and deliberate response to all of these trends. It got its start in the space program, but it has applications far beyond.

Addendum: The University of Illionis is offering a new Master of Science in Finacial Engineering degree through their Systems Engineering department. It's fascinating to me to see a university marrying its Business and Engineering departments in this way.