Interface Analysis

I’m pursuing yet another certification, this time the IIBA‘s CBAP, for Certified Business Analysis Professional. I chose a 35-hours training course run as a series of interactive webinars over seven successive weekend days and during the second session this past Sunday we ended up discussing several of the 50 techniques used by Business Analysts during each phase of an effort. The students were asked to each take a separate technique (we cover a few each session) and then talk on it for ten minutes or so. I was assigned the topic of Interface Analysis.

Since I’ve spent many years working on such things I observed that I was either the best possible choice to discuss that subject — or the worst — depending on your level of enthusiasm. My enthusiasm for this particular subject is high, so I took the opportunity to describe a few things from my website (we could share screens and all interact via audio and video), mostly on this page where I describe how my experience across many industries has led me to be a well-rounded systems or process analyst in the general sense. Come to think of it, I probably spent most of my time on this page, where I describe my experience as a system architect.

I don’t remember if I had time to describe any material to the group beyond the one page but I know that I discussed a few subjects, whether explicitly or implicitly. I’ll describe my clarified thoughts here.

  • Interfaces can be used to connect:
    • processes within a single machine: via shared memory, semaphores, or other sorts of messaging
    • processes on separate machines: via serial, fiber optic, and hardwired and wireless network protocols like TCP/IP
    • processes on separate networks: via routers and long-distance connections
    • users with user interfaces of various sorts: using software GUIs and hardware switches, buttons, knobs, and so on
    • logical operations within processes: information passed between logical blocks of code or representations as parameters and objects
  • The electrical protocol and media is distinct from the information protocol.
    • RS-232 and RS-485 are examples of serial protocols, and these describe a certain set of electrical connections and signalling used to send and receive information. Ethernet is a standard networking protocol, and wired and several wireless standards exist. Arduino boards use their own serial protocol for wireless communications distinct from WiFi and TCP/IP. Optical fiber communications have their own methodology. BACnet is commonly used for building control systems.
    • HTML and XML are examples of information protocols. These can be transmitted across many different types of hardware connections, though of course TCP/IP is the most common. American Auto-Matrix publishes a protocols they call PUP (Public Unitary Protocol) and PHP (Public Host Protocol) that describe standard message formats typically transmitted over RS-232 and RS-485 connections. These are used to control, configure, and record data on networks of unit controllers attached to host controllers. An almost infinite variety of standalone message formats are defined for individual applications and I wrote many different versions.
  • Interfaces need to ensure logical consistency across time. Mutexes are one way of ensuring this.
  • Communications need to be checked for potential errors. A system I supported for Inductotherm used CRC checks to verify the accuracy and integrity of their serial messages.
  • Our course instructor felt it necessary to observe that interfaces should be kept as simple as possible. This is true, and in my enthusiasm to complete a comprehensive information dump with minimum preparation I had neglected to mention it. It should also be recognized, however, that they should be as simple as possible — but no simpler. Make sure the necessary information is relayed as required.
  • The information payload of a message (distinct from header information used in the low-level communication layer) can be compressed to greater or lesser degrees to optimize on message size, transmission time, user comprehensibility, and software processing time.

I describe several examples of inter-process communications I’ve worked with here and here.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *