Managing ICS Complexity Professor Mark Haselkorn TC 520

Standing Technical Communication on its Head From particular instance of communication out To Communication systems and environment in ------------ View these systems as an information product In almost all your technical communication classes, you focus on a particular instance of communication—a website, an article, a proposal. You work outward from that instance of communication. Who is the audience? What is the purpose? What is the available technology? How does your organization handle information? Are there standard ways of doing things that must be considered? How will your information be used and archived and repurposed? Are there political considerations? Economic? Legal? Ethical? You draw on all these considerations to do the best job of designing a particular instance of communication.   In this class we will stand technical communication on its head. We will focus on the larger systems themselves, rather than simply use them to inform the particular design decisions for an instance of communication. What are these systems? How do they work? How do they interact? How are they managed? Who manages them? Could it be done better? The goal is for you to understand the systems by which an organization communicates to itself and others as an information product, that is, as something that is designed, developed, used, maintained, and managed. Perhaps it is an information product that YOU will want to design, develop, use, maintain, and manage.

Overview General background on ICS complexity Specific situational issues (an organizational example) Lessons for managing ICS complexity

ICS Complexity ICS versus a Roof Given the nature of our visit, I couldn’t help mentally comparing the roof to the systems we had spent our day investigating. Like the roof, ICS systems are significantly impacted by funding issues, but you could point at the roof across the street. You knew what the roof was used for and you could identify the components of the roof that weren’t meeting specifications. With the ICS systems we had been discussing that day it was far from obvious where a given system was located, where it began and ended and even of what it consisted. With ICS systems it was far more difficult to point at the things that needed to be repaired or checked. It wasn’t even clear who was using an ICS system and what they were using if for.

ICS Complexity ICS is Pervasive ICS is Multi-Purpose ICS Elements are Diverse and Dynamic ICS is Less Reliable than Traditional Infrastructure ICS Elements are Interdependent

ICS is Pervasive Everywhere yet not anywhere in particular People see/touch small piece of overall system People usually seek to control their piece When there are problems, reverse is true Confusion over ownership and responsibility More an environment than a discrete machine

ICS is Multi-Purpose Not obvious who is using it or what they are using it for True at many levels (e.g. content, management) Honest differences of perspective as to the most desirable features

ICS Elements are Diverse and Dynamic Consists of a wide diversity of levels and elements, each with unique attributes and issues For example, rate of change PC environments organizational diversity

The System Hardware (RTC) BIOS Operating System I/O devices, peripherals, etc. ------------------------------------------------------- Application Software Data/Databases/DBMS Users Policies & Practice Organizations Economic Sectors Society Rollover Representation Processing Sharing Co-evolution © Mark P. Haselkorn, 1998

ICS is Less Reliable than Traditional Infrastructure High-reliability vs. COTS Programming as an art Incredible complexity Historical perspective

ICS Elements are Interdependent Compatibility System of systems Funding

Situational Issues Like documents, ICS management is situational Tied to, for example, an organization’s Mission Strategic objectives Environment Culture

Mission and Functional Objectives For example National security Information superiority Flexible capability Multi-functional Increase response capability by detaching logistics from operations Highest demand for security and information assurance

Security and Information Assurance Information value has accompanying risk Holds for all ICS levels e.g. communications, data, practice Risk TO systems from the outside versus risk FROM internal system complexities Functional strength versus security Integration of IA and CIP

Organization, Policy and Decision-making Organizational “homes” of ICS and how they contribute to policy and practice For example, Clinger-Cohen Act of 1996 “executive agency” versus distributed, frontline operational management and use Functional (stovepipe) versus cross-functional Acquisition and fielding versus use and maintenance

Personnel and Training Most important element? Market competition Job classifications and work conditions Reliance on informal training and experience Turnover

Geographic and Organizational Dispersion CONUS versus OCONUS Organizational attachments Autonomy Resources Mission-related issues International differences

Lessons for Managing ICS Complexity “Modern technology and society have become so complex that traditional ways and means are not sufficient any more but approaches of a holistic or systems, and generalist or inter-disciplinary nature become necessary.” Bertalanffy, Ludwig Von, General System Theory (Revised Edition), New York, 1998. Consider ICS management under stress—Y2K

Need for New ICS Management Strategies ICS cannot be understood and managed independent of interactions with other systems and with the environment. Increased awareness of interdependencies and shared responsibilities across and outside of an organization Manage as an organized whole

New Considerations in Problem Definition and Stratification Breakdowns in traditional management begin at the most basic, definitional levels Failure of efforts to stratify the problem Not only does technical complexity make it difficult to identify the boundaries of a given issue, but even more importantly the interplay between technical systems and their non-technical environment dynamically affect basic notion of key definitions like “critical.”

Shift in Focus from Technology to Data, Knowledge, and Mission “Computer-centric” perspective Use of data seen as separate from system But databases do many things Changes to data drive changes to technology Data problems can have disastrous implications independent of whether or not hardware and software are performing as intended “Data-centric” perspective

Aligning Operational and Strategic Management with ICS Management “Data-centric” impact not only on ICS professionals but also strategic managers Many difficulties from differences “Correct” based on technical knowledge versus “best” based on negotiated consensus Tolerance for risk But necessary to bridge the gap

Many Others Manage cross-functionally Can’t just manage what you understand Fund differently Manage people before technology More about balancing competing “goods” than choosing between right and wrong Don’t return to business as usual