Question

    (Ultra) Large-Scale Systems –Characteristics? explain in detail

How the nature of an enterprise affect complex system design? explain in detail
How an enterprise culture affects system design? explain in detail
How emergent property of an engineering systemchange enterprise culture and business? explain in detail

Answer 1

Characteristics of a ULS

Let's start of with some semblance of a definition :-) What constitutes a ULS system? Here are some characteristics given by Scale Changes Everything:

• an unbelievable amount of code (on the order of trillions of lines of code)
• immense storage needs, network connections, processing
• lots of hardware, lots of people, lots of purposes
• decentralized components
• created by aggregation, not design
• unreliable components, reliable whole
• ongoing and real-time upgrades, changes, and deployments
• lots of functionality, likely in a focused area of concern

The Web foreshadows the characteristics of ULS systems. Its scale is much larger than that of any of today’s systems of systems. Its development, oversight, and operational control are decentralized. Its stakeholders have diverse, conflicting, complex, and changing requirements. The services it provides undergo continuous evolution. The actions of the people making use of the Web influence what services are provided, and the services provided influence the actions of people. It has been designed to avoid the worst problems deriving from the heterogeneity of its elements and to be insensitive to connection failures.

But ... Security was not given much attention in its original design, and its use for purposes for which it was not initially intended ... has revealed exploitable vulnerabilities ... And although the Web is an important element of people’s work lives, it is not as critical as a ULS ... system would be.

If you previously purchased this article, Log in to Readcube.

Abstract

Ultra‐Large‐scale Systems (ULSS)1 are a major new challenge for systems and software engineering. Current engineering practice is ahead of the science — we are building systems we do not know how to characterise or analyse, and whose behaviour we cannot fully predict. ULS are characterised by complexity, dominated by emergence, and exist in a state of constant reconfiguration and evolution; all of which make untenable a reductionist approach to engineering and a “closed system” approach to specification and certification.

This paper recommends ten design principles and five design practices for ULS systems, drawing on known systems engineering practice and an understanding of how complexity science is applied in other domains. The paper offers practitioners a strategy and a practical approach to deal with ULS systems — or indeed any system that is larger scale and more complex than those they are accustomed to dealing with—and shows academics some possible routes to addressing the research challenges set out in the SEI report on ULS systems.

Design

Relevance to Design and Evolution. Fundamental to the design and
evolution of ULS systems will be explicit attention to design across logical,
spatial, physical, organizational, social, cognitive, economic, and other
aspects of the system. Attention to design is also needed across levels
of abstraction involving hardware and software and involving procurers,
acquirers, producers, integrators, trainers, and users. A key area of research
in design is therefore the need for Design of All Levels of ULS systems.
Research in design includes formulating the architectural designs of ULS
systems in terms of Design Spaces and Design Rules: design rules that structure design artifacts and design spaces around which decentralized
design activities—and even whole industry structures—may come to be
organized. Design rules generalize from traditional interface specifications
to structure design artifacts using a much broader concept of constraints
that serve to regulate decentralized design processes, largely to assure that
component parts will integrate into systems having specified properties.
We need research on designing, representing, and analyzing design spaces
and on the means by which design rules are created, validated, and changed.
The overall design activity—in some cases carried out across entire industry
sectors, including open-source projects, university projects, and individual
contributions—then acts as a complex adaptive system, strongly driven to
converge economically15 on, and to maintain, good designs. Today we have
few tested theories or practices of designing ULS systems for economic
value or of how to establish economic forces that promote good design, such
as through new contracting and acquisition structures. We therefore need
research on Harnessing Economics to Promote Good Design leading to
a deeper understanding of how to organize designs and design activities to
maximize value and on how to create economic conditions that predictably
provide incentives to create and sustain valuable designs.
Operational ULS systems will also behave as complex adaptive systems in
which feedback and control are essential to meet user and mission objectives.
We therefore need research to understand how to decentralize design activi-
ties so that they are responsive to feedback from deployed running systems.
Since ULS systems will serve different classes of users with distinct and
often conflicting interests, research is needed on Design Representation and
Analysis and reconciliation of distinct and competing interests, both offline
and online and at various levels up and down echelons.
Today’s large-scale systems are often characterized by attempts to leverage
components that were not designed to work together or that are inconsistent
with the design rules of the system architecture in which they are inserted.
The success of ULS systems will depend on significant progress being made
on ULS system Assimilation, where nonconformant components (often with
less than adequate reliability) are assimilated into architecturally coherent and
robust ULS systems. This research will focus on developing techniques that
enable analyzing, modeling, fortifying, and evolving large legacy code bases;
working with diverse data; and integrating diverse, uncertain, and unreliable
information sources into a coherent operational picture.

Emergent properties

Properties of the system as a whole rather than properties that can be derived from the properties of components of a system
Emergent properties are a consequence of the relationships between system components
They can therefore only be assessed and measured once the components have been integrated into a system.

Specifying, designing, implementing, validating, deploying and maintaining socio-technical systems.
Concerned with the services provided by the system, constraints on its construction and operation and the ways in which it is used.

Alan Kay7
famously said that the right perspective is worth 80 IQ points.8
For
40 years, we have embraced the traditional engineering perspective. The basic
premise underlying the research agenda presented in this document is that
beyond certain complexity thresholds, a traditional centralized engineering
perspective is no longer adequate nor can it be the primary means by which
ultra-complex systems are made real. Electrical and water systems are
engineered, but cities are not—although their forms are regulated by both
natural and imposed constraints. Firms are engineered, but the overall
structure of the economy is not—although it is regulated. Ecosystems exhibit
high degrees of complexity and organization, but not through engineering.
The protocols on which the Internet is based were engineered, but the Web as
a whole was not engineered—although its form is constrained by both natural
and artificial regulations. In this report, we take the position that the advances
needed for ULS systems require a change in perspective, from the satisfaction
of requirements through traditional, rational, top-down engineering to their
satisfaction by the regulation of complex, decentralized system.