Business Drivers of Software Architecture

1
Business Drivers of Software Architecture

• Managing Development and Support
• Resource Sharing and Re-use
• Replication, Redundancy, Distribution
• including Precedence and Concurrency
• Establishing and Demonstrating Properties
• Facilitating internal visibility
• Handling anomalies and transitions
• Organizational Boundaries and Responsibilities
• Other

2
Managing Development and Support

• New developers and maintainers need to learn the
  product, how to think about it and how to work
  with itUse the software architecture as a high
  level simplification slight errors resulting
  from oversimplification are tolerable if the
  violations can be identified and explained
• Outsourcing, including subcontracting,
  collaboration, and use of COTS must be
  facilitatedLoose coupling can reduce interface
  and interaction between components, and
  well-defined interfaces can simplify acceptance
  criteria.
• Different implementation strategies and project
  management are appropriate to different aspects
  of a systemPartition the architecture into
  homogeneous subsystems
• Staffing decisionsAppropriate architectural
  partitioning can limit requirements for
  specialized skills for particular subsystems
  (e.g. speech recognition knowledge may only be
  required in part of HCI)

3
Managing Development and Support (cont.)

• Need to allow for workarounds, to avoid known
  flaws in toolsAn architecture must not too
  tightly constrain implementation choices, amongst
  other reasons because flaws in development tools
  can prevent the obvious implementation strategy
  from being followed. Less obvious choices may
  need to be used as workarounds, especially for
  third-party tools which may never be repaired.
• Need incremental delivery to in order to provide
  a marketable product before some components are
  available subsequent releases will provide more
  complete functionality as more components become
  available. Revenue from preliminary sales
  validates market existence for potential
  investors. Also accommodates fixed price or fixed
  delivery date contracts which must deliver
  incomplete functionality.Nested architectures of
  successive releases is key

4
Managing Development and Support (cont. again)

• Beyond incremental development, need evolutionary
  development in a use-and-learn cycle to adapt
  requirements and implementation to lessons
  learned from early adoptersNested architectures
  for successive releases must be adapted by the
  ability to withdraw deployed functionality.
  Typically this flattens dependency graphs
• Provide an easy method to install and use
  upgradesIf a product will change often over its
  lifetime, not only must the upgrade procedure be
  easy, and user awareness of changed facilities be
  assisted, but interoperation with data prepared
  by and for other releases must be supported.
  These require support in the architecture.
• Need metrics to measure productivity and gate
  progress paymentsIn a concurrent engineering
  environment, traditional waterfall milestones are
  not a useful measure of work performed,
  especially when the contracting agency is asked
  to provide progress payments. Metrics based on
  architectural elements treated provides a finer
  grain framework for assessing work done, and also
  provides a measure of due diligence of
  alteratives considered and potential changes
  allowed for.

5
Resource Sharing and Re-use

• Objective is to produce a commercial software
  product, i.e. one sold in essentially identical
  form to many customersSeparate common core from
  tailorable aspects and provide machinery for
  tailoring by customers and installers. Porting to
  other platforms and configuring to different
  needs are also important.
• Objective is to producing a family of related
  productsA product line is a number of products
  that share a managed set of resources. Often
  members of the family are obtained by making a
  choice between alternate components or by
  inclusion or not of optional components. Common
  core can convey benefits beyond simply reduced
  development and support costs, e.g. common
  look-and-feel reduces training time for
  customers.Evolution over time can often usefully
  be thought of as a family of products.

6
Resource Sharing and Re-use (cont.)

• Objective is to produce an internationalized
  product that can be localized to different
  culturesSeparate the parts of the application
  affected be internationalization issues from
  common parts, and provide machinery for carrying
  out localization.Internationalization issues
  include not just external representation of
  information but also what information and
  algorithms are appropriate.
• Objective is to produce a product that must be
  closely integrated into customers other
  systemsConform to industry standards for API,
  protocols, or other interfaces. Industry
  standards such as SOAP, .Net, ODBC, SAPI can
  constrain functionality, but they exploit the
  users previous knowledge as well as possibly
  improving interoperability.

7
Resource Sharing and Re-use (cont. again)

• Objective is to extend existing capabilityOften
  urgent modifications to extend existing
  capability collide with constraints in the
  original architecture. Kludging violations into
  the architecture can lead to maintenance
  problems. Revising the architecture to encompass
  the new requirements may be immediately more
  expensive, but over the longer term can result in
  savings. This is sometimes called refactoring.
• Objective is to reduce the cost of future
  enhancementsOften time-to-market and available
  financing considerations cause shortcuts to be
  taken where a more complete implementation is
  obvious, and hooks can be left to guide such
  extension should it ever be required.Systems
  need to change with time, and although the
  specific changes are not predictable, often the
  kind of changes can to some extent be predicted.

8
Resource Sharing and Re-use (cont. again)

• Objective is to produce a portable product,
  reflecting the idioms of the local platform where
  they existThe effect on the architecture can be
  significant, because although it is desirable to
  use common code as much as possible, it must be
  possible to override the common code by
  platform-specific native code when
  necessary.Architectural clashes with mative
  services are a big issue. User interface toolkits
  are a case in point, even just scroll bar
  controls
• Objective is to exploit specialized resources if
  available (whatever supplier the resources are
  provided by), but not to depend on resources
  being provided at allProbes must be provided to
  learn what resources are available, and a common
  interface used to whatever services are found.
  Default services, possibly of modest capability,
  must be provided as a fallback.

9
Resource Sharing and Re-use (cont. again)

• Objective is to package a service to be
  marketable in view of probable installed customer
  capabilitiesMost customers already have
  installed products which they are unlikely to
  replace lightly. Software packaged as an add-on
  is more likely to get market acceptance, but as
  an add-on to which existing software? Can an
  architecture be found that facilitates being an
  add-on to different products?
• Where minimizing memory space is
  paramountSeparate applications that share
  dynamically loaded components may be as useful as
  lower level techniques such as indirect threaded
  code or a high level interpreter.Minimizing RAM
  used to be paramount, but minimizing backing
  store can be critical also.

10
Replication, Redundancy, Distribution

• Objective is to provide a scalable product where
  an instance can be sized as requiredScalability,
  the ability of a product to meet the needs of
  different customers with widely differing load
  characteristics, is an essential requirement of
  many commercial software products. Beyond simply
  parametric declaration of sizes for tables and
  other data structures, introducing replication
  and remote placement of components in the
  architecture can accommodate large configurations
  without penalizing small ones.
• Objective is to support high reliability or for
  safety critical applicationsRedundancy and
  runtime consistency checking strengthen component
  reliability

11
Establishing and Demonstrating Properties

• Provide testability, i.e. reduce testing cost and
  complexityExpose examples of properties that
  need to be demonstrated. This can also reduce the
  amount of testing required.
• Support product tuningExpose properties that
  need to be monitored and provide machinery for
  parameter adjustment.
• Obtain regulatory approvalFacilitate by
  software architecture which exposes critical
  aspects to more convenient verification and
  validation
• Ensure security policies are enforcedLimit
  access to sensitive data and consequences of
  specific sensitive data
• Compliance with export controls on
  technologyPartition application so restricted
  technology is contained within a replaceable
  component for which alternate versions can be
  provided

12
Establishing and Demonstrating Properties (cont.)

• Facilitate different security models, e.g.
  privilege by user role vs. privilege by object t
  typePartition application into different
  sectionss corresponding to different models
• Bounding spread of courruptionThe original use
  of the term firewall was that architectures
  could bound how much damage could be caused by
  corrupted data
• Establishing an open third-party marketplace
  System properties are determined by
  architecture, independent of component
  implementation interface and interaction between
  components should be minimized.
• Support Plug-and-play and interoperabilityLimit
  interaction with third-party products to specific
  components and connectors
• Block software piracy by code partitioningA
  dongle is useless if a hacker can patch out
  probes for it within the application it is to
  protect. A dongle with ROM containing utility
  code so widely used throughout the application
  that patching it out is infeasible is harder to
  defeat.

13
Facilitating internal visibility

• When fully automated algorithms are not
  available, support manual steering of
  computationIf human interaction iis to be used
  to steer computation, then nternal information
  about the computational state must be formatted
  and displayed in ain insightful way, and the
  control input must also be represented
  effectively for humans. Architectural support for
  these HCI issues often is independent from
  architectural support for the computation itself
• When applications run continuously, operations
  staff oftem need to monitor progress or resource
  consumptionDisplay of current status can often
  be interpreted more intelligently in the context
  of predicted values or historical experience.
  Examples abound such as in process control,
  quality control, and project management. To
  support this, an architecture must provide
  history logging and display of internal state,
  even where these are not central to the purpose
  of the computation.

14
Handling anomalies and transitions

• For high availability and resilience to
  outagesUse compartmentalization to prevent local
  failures from propagating across the system to
  cause global failure. Separate storage pools for
  instance. The term firewalls was used in this
  context is software systems as far back as the
  1950s, much more generally than the narrow
  networking context common today
• Support corporate merger and acquisitionAmalgamat
  ing units typically have different business
  support systems,at least during the transition
  an integrated system is needed to support
  different business practices, or later to
  interpret historical business records
• Disaster recovery and loading of databases are
  examples of unusual situations for which
  provision must be madeOften such anomalous
  situations, transitions and transients are best
  handled in separate programs, rather than the
  main application
• Isolate dangerous commands to reduce risk of
  fatal blundersSome operator actions can have
  serious consequences if accidentally and
  unintentionally exercised. Undo capabilities and
  confirmation requests can reduce the risk, but
  isolation of the functionality is a safer way of
  avoiding things like accidental disk reformatting.

15
Recognizing Organizational Boundaries and
Responsibilities

• For strategic business partnerships where
  different partners provide complementary
  servicesCompatible software architectures
  improve interopertability Service-oriented
  architectures are another option.
• Partitioning a project among complementary
  partners is common businss practice, but how does
  one allow for the not unusual experience of
  shifting partner relationships?The partition
  which is a single partners responsibility should
  be a viable product in its own right, and should
  have an architecture that provides for
  independent completion.
• Where applications incorporate third-party
  services that are priced or a fee-for-service
  basisIt may be appropriate for the software
  architecture to provide buffering, caching, and
  proxies in order to control charges by these
  third parties
• Post-delivery error reportingWhen a run-time
  error is discovered by an application, the most
  relevant information for the support organization
  is often available internally, and can be
  packaged automatically for shipment to the
  support organization. However, the purchaser of
  the software is often suspicious of autonomous
  attempts by the software to report to the
  developer, and would prefer to inspect any such
  communications before it is sent, to ensure
  proprietary information is not divulged. This
  affects the structure of the error reporting
  system.