Posts

Showing posts with the label Design

System Complexity with various types of contract and subscription types.

Image
Consumers often want to change to auto-renewing contracts or subscriptions in the middle of a  subscription or contract period. Automating these modifications varies in complexity taking into account the dollar amounts of the services, customer expectations, regulatory requirements, business cycles, or legacy processing overhead like paper billing. This presentation walks through a variety of ways of handling intra-period modifications. Video on YouTube These images were used in the Video They exist here for review Monthly with cancellation at renewal This is the simplest of subscriptions.  The contract is simple.  Cancellations happen at the end of the subscription period, usually monthly.  There might be rate adjustments if you change the plan in the middle of the month but some services just ignore that or only upgrade at renewal.  Simple prepay with changes at renewal This plan's payment cycle and subscription length are the same.  Changes happen...

Did anyone dogfood this experience? A bog standard gate experience gone bad.

Image
I had a consulting job at a company that got new gates.  The new gates have a different experience between doors and based on whether you are going in or out. Between 1000 and 4000 people use the gates per day. A back-of-the-napkin analysis says this interface costs the company $300/day or over $80,000 per year plus any frustration. They often pause at this gate system to deal with the interface inconsistencies.  3000 people * 5 seconds / 3600 sec/hr * $80/hour fully loaded * 5 d/w * 50 w/y The gate system as a use case They bought a combined entry/exit system. Looks good from here. Here is a different set of gates by the same vendor in the same building.  I was going to say that these were on the way out but this picture is also on the way in. Bi-directional gate control - flow optimization The gates support traffic in both directions.  Each turnstile has two card readers, one for each direction through the gate. The card reader is "right-handed" on entry and "left-...

Baked-in Runtime Falure Identification and Remediation

Image
Web and other API-based applications are made up of some set of services, data stores and compute dependencies or partner business systems. We need some way of continually monitoring the components in isolation and in situ so that we can have automation repair or heal certain types of problems. Different control plane components have different requirements for the components that they manage. This means the instrumentation may be subtly different, shallower, or more detailed in order for the different control planes to take action for their particular needs.  Health checks are one technique for determining the current health of a component. They are in-service test endpoints or very specific external code that exercise some capability of a specific instance of a component service.  Each control plane or remediation touchpoint needs to be examined to understand what their actual area of concern is. This is refined into a set of health checks. Then the problems that can be ident...

Bug for Bug Compatability in IT systems.

Image
A new system that behaves exactly like the existing system in order to allay fears and, retain all the existing interfaces, data meanings, and testing approaches. The new system's business behavior is identical and all interfaces are the same or easily adaptable. That compatibility extends to all the idiosyncracies of the previous system including all the workarounds that were put in to support other systems or rules that may or may not still be valid. This is a design of least surprise. Video https://youtu.be/npcuWeKnkj0 Slides Speaker notes to be added Video Revision History Created 2023 02

Non Functional Requirements Component Type Applicability

Image
Non Functional Requirements (NFR) define the constraints or the way Functional Requirements are implemented. NFRs are categorized as different types of constraints.  Those categories are great for the enterprise but don't really help determine which NFRs apply in any given Business Feature. One way to remedy this is to create a second type of categorization that identifies which NFRs apply for a given component type, The individual NFRs in a category may only apply to certain deployable types. Related Video: https://youtu.be/S4MKvpNNcNo Blog (Related):  https://joe.blog.freemansoft.com/2022/06/non-functional-requirements-nfrs-in.html Classic NFR Categorization NFRs are generally grouped with related constraints.  You can find a variety of categorization taxonomies with a quick internet search.  From Wikipedia: Non-functional requirements are often mistakenly called the "quality attributes" of a syst...

Non Functional Requirements - NFRs - in Software Systems

Image
NFRs are requirements that do not relate to business functionality. They relate to attributes like reliability, efficiency, and portability. Non Functional Requirements are architecturally significant requirements because they impact the system architecture. They are properties of a system that sit outside of specific business features or functionality. NFRs are sometimes called constraints. Other times they are called Quality Attributes. Constraints generally change the shape of architecture or design. Capturing NFRs early is part of a shift left where we surface the non-business value needs earlier in the process. Non-functional requirements impact the system as a whole and are cross-cutting across business features. when the non-functional requirements are done well, you may eliminate 50 to 80 percent of product defects.   Credit: Jamsoft Project efforts really need to be explicit about capturing their NFRs and updating them. Everyone has been on projects where some techni...