Reliability of an online system is a result of a series of intentional actions which can include automated ones. A reliable system should allow users to perform tasks in a predictable manner, with visible failures and a safe recovery path. It is likely that most people would consider a reliable system to be one that does nothing wrong.
However, there are many things that go wrong with an online system that are not apparent to the user.
For example, if a website is slow to load, possible causes include server problems, page assets, and the user’s internet connection. If an authorized user logs into their account on a website and cannot access certain areas of the site, the cause may involve permissions, authentication, or the intended access rules. If an asset is lost or disconnected from its source, the cause may involve a broken relationship, missing data, or storage problems. If a correction does not reach its intended destination, the cause may involve routing, source data, or a publishing failure.
Lastly, if an integration fails to complete its task, the cause may involve configuration, credentials, application changes, or unexpected data. When any of these problems occur with an online system, they are often difficult for users to identify and correct.
Therefore, it is important for developers to design online systems such that the underlying infrastructure is reliable and transparent to the user. Many aspects of developing an online system are not readily apparent to the user.
For example, the design of a website's architecture determines how it will function. A good architectural design enables developers to build a website that can be expanded in terms of features and content.
Additionally, developers must create a database that accurately reflects how the organization operates. A well-designed database provides a framework for building applications that can be used to manage the organization's operations.
Furthermore, developers must implement security measures to protect the organization's data.
Finally, developers must develop a process for migrating data from an existing online system to a new online system. Each of these steps contributes to creating an online system that is reliable and easy-to-use for users. As mentioned earlier, there are many elements of an online system that are not visible to the user. One such element is the design of a website's architecture. Architectural designs determine how a system will be organized and how its components will communicate with each other. Architectural designs establish rules regarding where authoritative information resides within a system. These designs also define how records will be identified within a system and how relationships between records will be expressed. Architectural designs define which responsibilities should be grouped together within a system and which should remain separate. Architectural designs define when human approval is required within a system and how errors will become visible within a system. Architectural designs define how history and provenance will be maintained within a system. Poor architectural designs can exist unnoticed while a system is relatively small.
However, poor architectural designs can impose constraints upon a system as its number of records, users, websites, integrations, and responsibilities grow. Good architectural designs enable developers to create a foundation that can be expanded without altering its fundamental nature.
Another element of an online system that is not visible to the user is the design of a database. Databases serve as repositories for data and can be structured in various ways depending upon how an organization views its operations. Databases can be used to store data about artists, creative projects, assets, releases, articles, organizations, songwriters, producers, etc. To create a well-designed database, developers must engage in discussions about terminology used by the organization to refer to its operations. Developers must discuss how responsibility is assigned within the organization. Developers must discuss who owns each type of asset within the organization. Developers must identify exceptions to general rules governing ownership of assets. Developers must identify real-world relationships among entities represented in the database. Developers must compare existing systems used by the organization with proposed systems. Developers must examine legacy records maintained by the organization. Developers must recognize contradictions between legacy records and proposed records. Developers must determine which distinctions among records are relevant. Data modeling is a fundamental step toward enabling reliable publishing, structured data, automation, and responsible AI.
Canonical data is an agreed-upon set of facts concerning which information should be trusted.
Establishing a canonical source of information is only the initial step toward establishing a reliable online system. After establishing a canonical source of information, organizations must determine who may establish new records and modify existing records. Organizations must establish criteria for verifying facts contained in records. Organizations must establish acceptable sources for verifying facts contained in records. Organizations must establish procedures for resolving conflicts among records. Organizations must establish procedures for documenting modifications made to records. Organizations must establish procedures for distributing records automatically. Organizations must establish procedures for maintaining records specific to particular destinations. Organizations must establish procedures for ensuring continued accuracy of records. Organizations must establish procedures for maintaining records that reflect the organization's unique perspective. Organizations must establish procedures for enabling distinct voices to coexist within a common framework. Organizations must enable users to express themselves in their own voice while maintaining factual consistency across all representations of themselves/their work.
For example, biographies may be modified without creating new histories. Songwriter credits, release dates, ownership records, and approved images should remain consistent regardless of where they appear. The online system protects accuracy while enabling users to express themselves in their own voice.
Security is an ongoing process that exists in account ownership, multi-factor authentication, certificates, permissions, secrets, updates, storage, integrations, backups, logs, and day-to-day decisions.
Developers must continually evaluate whether their online system is protected against unauthorized access. Developers must continually evaluate whether their online system is protected against misuse of resources. Developers must continually evaluate whether their online system is protected against loss or destruction of data. Developers must continually evaluate whether their online system is protected against disruption of service. Developers must continually evaluate whether their online system is protected against compromise of user accounts. Developers must continually evaluate whether their online system is protected against unauthorized modification of records. Developers must continually evaluate whether their online system is protected against unauthorized disclosure of confidential information. Developers must continually evaluate whether their online system is protected against unauthorized acquisition of proprietary information. Most security work is intended to be invisible to users. When security work is successful, users perceive a functional and trustworthy service.
Integrations enable applications developed independently to interact with one another.
However, enabling two applications to interact with one another does not necessarily create a reliable integration. Applications evolve; credentials expire; providers change interfaces; data arrives unexpectedly; and successful initial steps may be followed by failed subsequent steps.
Therefore, every operational integration requires a designated owner; documented purpose; defined authority over information exchanged between applications; monitoring capabilities; alert mechanisms; error recovery paths; duplicate detection mechanisms; error handling mechanisms; recovery plans. The invisible work associated with creating a reliable integration includes all activities that enable continued understandability of interactions between applications over time.
Testing involves evaluating whether a piece of software works as expected.
Testing must evaluate more than whether a button functions as expected. Testing must evaluate whether information is missing from a piece of software. Testing must evaluate whether duplicates can be generated by a piece of software. Testing must evaluate whether external services relied upon by a piece of software are unavailable. Testing must evaluate whether unauthorized individuals can modify records maintained by a piece of software. Testing must evaluate whether a page remains functional on a phone, with a keyboard, or at enlarged text sizes. Testing must evaluate whether structured data produced by a piece of software corresponds to what users observe. Demonstration of functionality indicates that something can work as expected. Operational testing indicates that something can be relied upon as expected.
Documentation enables preservation of organizational memory.
A piece of software becomes fragile when only one individual understands it. Documentation should describe why decisions were made regarding a piece of software; where authoritative information resides within a piece of software; how different services interact with one another within a piece of software; who owns responsibility for various aspects of a piece of software; how access to various parts of a piece of software is managed; what common errors encountered while using a piece of software indicate; how recovery should occur following an error encountered while using a piece of software. Documentation provides a foundation for AI assistance. AI can retrieve and apply knowledge more accurately when that knowledge is current, organized, and linked to an approved source.
Monitoring enables identification of failures within a piece of software.
Eventually, every meaningful piece of software will fail. The goal is to identify failures rapidly; understand impacts caused by failures; restore service safely following failures. Useful monitoring may measure availability; errors; performance; failed integrations; storage limits; expired credentials; security events; broken links; incomplete records; publication failures; unexpected changes. Alerts must reach individuals who possess authority and knowledge necessary to respond appropriately to failures.
Backups are only useful if recovery is successful.
Creating backups does not guarantee that restoration will succeed. Organizations must understand what is included in backups; how often backups are performed; how long backups are retained; who can access backups; dependencies required to restore backups; methods used to test restoration capabilities; maximum amount of data/time lost if restoration fails. Recovery also includes failures related to identity; publication rollbacks; original assets; damaged records; preservation of history. Back-up strategies should be evaluated based on their ability to resume reliable operation.
Migration is an interpretative process.
Transferring information from an older piece of software to a newer piece of software is rarely a direct transfer. Legacy data contains inaccuracies; duplicates; unexplained fields; abandoned experiments; embedded formatting; missing relationships; essential facts buried inside pages. Responsible migrations identify valid components of legacy data; components of legacy data worth retaining for historical purposes; mapping between fields in older piece of software vs. newer piece of software; reconstruction between relationships in older piece of software vs. newer piece of software; identification between components of legacy data that cannot be verified; components of legacy data that require manual review. Importing all components of legacy data results in retaining previous confusion; eliminating excessive numbers of components results in erasing organizational memory. Performance relies on image sizes; asset delivery; caching; code; database queries; external services; fonts; rendering decisions; network conditions; number of systems required to generate a page. Performance influences accessibility; visibility in search engines; conversions; energy usage; usability across devices/networks. The fastest request is often one that does not require interaction with a piece of software.
Accessibility is an aspect of reliability.
An experience delivered digitally is not reliable if substantial portions of its audience cannot utilize it. Semantic structure; readable contrast; keyboard operability; text magnification/enlargement; alternative text; easily understood labels; visible focus areas; captions/subtitles; responsive designs; unambiguous error messages must be considered throughout design/development.
Human judgment serves as glue holding together digital ecosystems.
Automation can disseminate content; convert assets; validate fields; monitor services; compare records; prepare drafts. AI can facilitate research/analysis/development/documentation/classification/content operations. Neither replaces need for humans to determine authority/source credibility/context/approval for significant modifications/ambiguity resolution/accountability. Human judgment is not an inefficient gap waiting to be eliminated. It is a component of infrastructure.
Mission HQ and Work Beneath Interface
Mission HQ is governed operating environment being developed for information/media/relationships/websites/workflows across 1st Drop Music/Free the Line/Bear Cole/their associated projects. Beneath Mission HQ’s visible interfaces are canonical data models/structured relationships/asset provenance/destination-specific content/permissions/publishing rules/integrations/migration processes/AI-assisted workflows/human review. Mission HQ has necessitated research/comparison/database design/development/migration/testing/correction/documentation/refinement. AI has enabled more rapid progression/new functionalities previously requiring larger teams. AI has not transformed process into series of prompt-based interactions requiring minimal effort. Work associated with Mission HQ has roots in decades of experience with web design/development/WordPress/infrastructure/domains/DNS/certificates/identity management/support/creative production/publishing/project leadership.
Reliability Is a Relationship
Dependable systems are rarely permanently completed. Software evolves. Providers evolve. Information expands. Users require new functionality/features. Threats evolve. New destinations/capabilities emerge. Reliability represents ongoing relationship between system/people responsible for maintaining/observing/correcting/documenting/governing/caring for system.
Make Invisible Work Intentional
Visitors rarely see database decisions/permission reviews/migration notes/security updates/monitoring rules/accessibility tests/recovery plans underlying digital experiences. Visitors experience outcomes resulting from invisible work. Invisible work transforms collection of websites/applications into reliable digital ecosystems. Invisible work warrants careful consideration when designing digital experiences similar to visible work. Read Technical Support Is Systems Design in Disguise/From WordPress Websites to Connected Digital Ecosystems. Contact info@freetheline.com to discuss digital architecture/platform reliability/website modernization/connected systems.