I have been fortunate enough to have been taught various topics (related to this subheading) by some brilliant and passionate instructors—some of whom have unfortunately passed away now—each experts in their fields, and each having worked on aspects of systems development or management from different perspectives. In my tool-belt are formal systems analysis, programming, accounting, and business process optimization.

Most companies have become so entrenched in doing things “the old way” that their leaders are severely challenged, even to imagine things done differently—the “art of the possible.”

In other establishments, managers observe systems-driven results in shops similar to theirs, but remain fully unaware of the unseen factors that helped their “competition” to implement technology success.

Three launch-pillars necessary to overcome the overwhelming gravity of these organizational “black holes” lie with appropriate technology strategy and tactics: “technology architecture,” “application architecture”, and something I’ll call “organizational posture.” I don’t subscribe to any single enterprise architecture framework. I use what works, and discard what doesn’t. I’d be honored to help.

Your interfaces should be always designed to eliminate all possible nonsense, basically designed to be complete-idiot proof.

Here was a cool snippet: https://www.codeproject.com/Articles/754323/Integrity-Constraints-and-Data-Validation

It bears noting that software engineers are continuously and repeatedly astonished at how very clever complete idiots can be.

These notes will form the basis of a presentation or talk at some point. They complement my little service oriented perspective diagram. I do realize that I need to narrate them—they are here mainly for my convenience.

Boundary definitions:

1. Infrastructure: Refers to OS configuration (What
   OS-native services are run?)
2. Applications: Refer to additional non-native services
   operated?
3. Grey areas: Directory services and identity management (how
   are the services configured?)

Applications

• Application use cases, user interaction - describes the
  boundary and interaction between the system and users.
  Corresponds in some respects to a requirements model.
• Communication or interaction - describes how objects in the
  system will interact with each other to get work done.
• Application states, and the actions they support.
• Object classes, and activities supported

Minor overlap: RE: collective quantities / performance only

• Physical components required (Modems? Satellite links?)
• Deployment model

Infrastructure

• Hardware and communication device inventory
• Firmware level inventory
• Hardware and the hardware’s communication configurations,
  including (but not limited to) those of:
  • transceivers,
  • switches,
  • routers,
  • bridges,
  • hubs,
  • sensors,
  • NICS,
  • alerting and signalling systems (public safety)
• Routing configurations
• IPv4 and IPv6 configurations
• Subnet configurations
• VLANs (inventory, purpose, configurations
• Processors/IOPS/affinity/reservations/affinity (virtual fabric
  configuration)
• Array configurations
• LUN configurations
• Cluster/failover/loadbalancing configurations
• RAM/Disk technologies
• Teaming/bonding/communication configurations

An Alternative, Holistic Perspective

Use the TCP model, split at layer 3 (“Application layer”) vs.
infrastructure (MAC/PHY Link layer, Internet layer, and transport
layer). This perspective changes the above propositions slightly,
but not very significantly.

1. Infrastructure: Hardware states, routing, and OSI Layer 2
   and some OSI Layer 3 (as provided by the OS).
2. Applications: Ping ability, complex software services,
   authentication, directory configuration and services.