Category: Structure & Architecture

Struktur och arkitektur är det lager som skapar ordning i komplexa tekniska miljöer. Här definieras hur system, information och komponenter hänger ihop – oberoende av leverantör, projekt eller teknikgeneration. Utan detta lager blir digitalisering snabbt fragmenterad, svår att förstå och dyr att förändra.

I detta lager handlar arbetet om att etablera gemensamma strukturer, arkitekturprinciper och standarder som gör tekniska lösningar begripliga över tid. Det omfattar informationsmodellering, systemarkitektur, referensarkitekturer och standarder som IEC 81346. Fokus ligger inte på enskilda produkter, utan på hur helheten är uppbyggd och kan vidareutvecklas.

Struktur och arkitektur fungerar som ett gemensamt språk mellan discipliner. När information, objekt och system har tydliga identiteter kan IT, OT, automation och verksamhet samverka utan missförstånd. Det är också här förutsättningarna skapas för effektiv integration, spårbar kravhantering och långsiktig förvaltning.

Artiklarna i denna kategori riktar sig till organisationer som vill minska beroenden, undvika teknisk skuld och bygga lösningar som klarar förändring. En genomtänkt struktur gör inte systemen stelare – den gör dem möjliga att förändra utan att börja om.

  • Why Standardisation Is Critical for Digitalisation, Integration and Automation

    TL;DR

    Conclusion

    Standardisation is not an administrative obstacle but the engine that makes complex digitalisation possible in practice.

    The challenge

    Without shared standards, every project creates its own structures, leading to fragmented data and fragile integrations.

    The solution

    By using established frameworks such as IEC 81346 and IEC 81355, a shared information foundation is created that holds over time.

    The effect

    A “Digital Thread” – an unbroken chain of information that makes your facilities easy to understand, manage and develop further.

    Digitalisation as Everyday Reality – and Complexity

    Digitalisation, integration and automation are today no longer future issues. They are part of everyday life in building automation, BMS, industrial automation, energy systems, infrastructure and traditional IT environments. IT systems, OT systems, control systems, sensors and digital platforms are connected over IP-based networks and share data in real time.

    Standardisation is sometimes perceived as administrative or constraining. In practice it is the opposite.

    Technically, this is rarely the biggest obstacle. Most organisations can collect data, build integrations and automate processes. The challenge arises over time. Solutions that work well at commissioning gradually become difficult to understand, change and develop further. Documentation loses currency, integrations become fragile and dependence on specific individuals increases.

    The problem is rarely the technology itself. The problem is the lack of shared structures for how systems, information and documentation are organised.

    Standardisation as Enabler, Not Constraint

    Standardisation is sometimes perceived as administrative or constraining. In practice it is the opposite. Standardisation is what makes complex technical environments possible to understand, manage and develop over time.

    When digitalisation spans multiple technology domains, there is a need for shared principles: how a system is bounded, how objects are identified, how information is classified, how traceability is ensured when systems change. Without shared standards, every project and every supplier develops its own structure. The result is fragmentation, increased management costs and integration solutions that do not scale.

    Structure Before Technology Selection

    In many digitalisation and automation initiatives, the focus lands on technology selection. Platforms, protocols and products are analysed in detail, while questions about structure, classification, metadata and document management fall into the background. This leads to systems that are technically integrated but informationally fragmented. Documentation becomes hard to use. Data loses its context. Every change requires extensive analysis.

    Standardisation in this context is not about controlling the technology, but about creating a shared information foundation that makes the technology usable over time.

    IEC 61355 and IEC 81355 as the Foundation for Documents and Information

    IEC 61355 has long been an established standard for the classification of technical documentation. IEC 81355 builds on the same basic principles but is better suited for digital information management and complex system environments. It provides clearer support for how information can be structured so that it is usable over time, regardless of technology domain. In practice, many organisations today manage existing facilities according to IEC 61355 while new projects are based on IEC 81355 – requiring a conscious strategy for information management during change and further development.

    IEC 81346 and Stable System Identity

    While IEC 61355 and IEC 81355 focus on documentation and information classification, IEC 81346 addresses how technical systems are structured and identified. The standard describes how function, product and location can be distinguished and identified in a consistent manner. The purpose is to create stable identities that hold over time, even when systems are rebuilt, relocated or further developed.

    ISO Standards for Information Management

    Beyond the IEC standards, several ISO standards complement the picture:

    • ISO 82045 – How technical documentation should be identified, version-managed and exchanged in a controlled manner
    • ISO 15489 – Information management over the entire lifecycle; documentation as business information with clear responsibility and traceability
    • ISO 19650 – How information is organised, structured and shared over the lifecycle in built and technical environments (often associated with BIM)
    • ISO/IEC 11179 – Metadata and shared concept definitions; central to master data and ensuring different systems interpret information the same way

    Digital Thread Through the Lifecycle

    The concept of a digital thread describes how information is kept together throughout the entire lifecycle – from concept and design to installation, operation, change and decommissioning. A digital thread is not a product or platform. It arises when objects, documents and data have stable identities and clear relationships. Standards for structure, documentation and metadata are what makes the digital thread possible in practice.

    Master Data, Aliases and Tag Management

    In integrated IT, OT and automation environments, the same object often appears in several systems. Different names, tags and designations are used in parallel.

    Master data covers the fundamental definitions of objects, functions and properties that must be shared regardless of system. By separating an object’s identity from its presentation in different systems, alias and tag management becomes manageable. This is a structural question rather than a technical speciality, and it is decisive for traceability and long-term integration.

    Beyond standards for document structure and metadata, there are also frameworks that address lifecycle governance and management of technical assets. The ISO 55000 series describes how organisations should manage assets across the entire lifecycle, from planning to decommissioning. IEC 62890 focuses specifically on lifecycle management of systems and products, including modernisation and change over time.

    These standards complement the IEC and ISO standards for structure and information management by clarifying how information is used as a basis for decisions in operation, change and circular asset management.

    Digitalisation as an Enabler of Circular Asset Management

    When information follows the systems through their entire lifecycle, the view of technology and products changes as well. Systems and components become managed assets with a known history.

    At the point of change or decommissioning, there is then a basis for deciding what can be reused, upgraded or recycled. Circular asset management emerges as a consequence of structured information management, not as a separate sustainability initiative.

    Digitalisation without structure often leads to shorter lifespans and increased waste of resources. Digitalisation built on standards instead creates the conditions for circular flows.

    Common Reasons It Does Not Hold Over Time

    Despite good intentions, standardisation is often introduced late, when the systems are already built. Focus lands on technical integration while information structure and responsibility are left unclear. Suppliers are allowed to use their own terminology and document structure.

    The result is solutions that work here and now, but that are difficult to maintain and develop further.

    When Structure Becomes a Long-Term Capability

    Digitalisation, integration and automation are ultimately not about more systems. They are about the capability to understand, change and manage technology over time. Standards for structure, documentation, metadata and information governance create traceability throughout the lifecycle. They enable the digital thread in practice and lay the foundation for both effective operations and circular asset management.

    Organisations that establish this foundation early are better positioned for future changes, whether driven by new technology, new requirements or increased sustainability ambitions.

    What to require in your next project

    Before selecting a platform or supplier, make these five decisions explicit:

    • Identity: define how systems, objects and locations will be identified across disciplines.
    • Information: specify required metadata, document classes and naming rules.
    • Interfaces: require open, documented interfaces and clarify ownership of each data flow.
    • Verification: turn the standards into acceptance criteria that can be tested at handover.
    • Lifecycle ownership: appoint who maintains identities, mappings and rules after commissioning.

    If one of these decisions is missing, the project is likely to create a new integration problem for operations to solve later.

    Is your digitalisation journey built on a solid foundation?

    Without shared standards, integration and automation become both costly and difficult to manage. We help you navigate between requirements specification and practical implementation to create a sustainable technical architecture.

  • Requirements Management in Technical Projects

    Requirements Management in Technical Projects

    TL;DR

    The effect

    Deliveries that actually match the order, minimised project costs and full traceability.

    The challenge

    Technical requirements are often forgotten or misinterpreted between procurement and commissioning, leading to costly changes.

    The solution

    A systematic process for requirements management that traces requirements from the first draft to final inspection.

    In complex multidisciplinary projects, requirements management is not an administrative chore – it is a critical control mechanism. Without a structured process for identifying, analysing and tracing requirements, the project risks scope creep, escalating costs and technical debt that burdens asset management for decades.

    Why Requirements Are Often the Real Cause of Problems

    In many technical projects, problems do not arise because the solution is technically deficient, but because it was never entirely clear what should actually be achieved, who owned the requirements and what role different documents played. Requirements are often documented, but they are not governing. They are difficult to verify, difficult to follow up and even more difficult to use when changes arise. In practice, they have become text, rather than a tool for governance.

    A requirement that cannot be pointed out is in practice no requirement at all.

    Requirements Start with Why the Document Exists

    One of the most fundamental mistakes in requirements work is that documents are produced without their purpose being clearly defined. In many projects, documents called requirements specifications, technical descriptions or system documents are produced without it being clear whether the document should function as governance, procurement basis, contract appendix or verification foundation.

    When the document’s purpose is not clear, the content follows suit. Requirements are mixed with background, goal formulations, explanatory text and sometimes even ready-made solution proposals.

    What Distinguishes Goals, Requirements and Descriptions

    • A business goal describes why something should be done. It expresses a desired effect or direction, but is not verifiable in a technical sense.
    • A requirement describes what should be achieved. It is directed at someone other than the person formulating it and must be unambiguous, verifiable and binding. A correctly formulated requirement contains no solutions and no reasoning about why the requirement exists.
    • A description explains how something is intended to function or be performed. It can be technical or functional, but is not a requirement unless it is explicitly formulated as a verifiable “shall” requirement.

    When goals, requirements and descriptions are mixed together, interpretative space arises. What the business perceives as binding may be perceived by the supplier as advisory.

    Why Requirements Must Be Identifiable

    A requirement that cannot be pointed out is in practice no requirement at all. For requirements to be followed up, verified and changed over time, they must be unambiguously identifiable. Each requirement needs a unique ID and/or sequence number.

    A requirement with a sequence number can be referenced, linked to test cases, change requests and documentation. This makes the requirement a manageable information object rather than a formulation in text. Numbering is therefore not administration – it is a prerequisite for requirements management over time.

    Abstraction Levels (URS, FRS, TRS)

    In professional requirements management, the terms URS, FRS and TRS are often used. These should be understood as abstraction levels rather than fixed document types:

    • URS (User Requirement Specification) – describes the business’s needs. Technology-independent but verifiable.
    • FRS (Functional Requirement Specification) – describes which functions the system must have to fulfil the URS. Functional behaviour and logic, without locking technical solutions.
    • TRS (Technical Requirement Specification) – describes the technical requirements placed on the solution: architecture, performance, interfaces, integrations and technical standards.

    Traceability as Quality Assurance

    The core of professional requirements management is traceability. Every technical requirement in a TRS must be traceable back to a business need in the URS. In the same way, every delivery must be verifiable against its original requirement.

    Without this traceability, change management becomes guesswork where consequence analysis often does not take place – which is the single largest source of technical debt being built into the facility during the construction phase.

    ISO/IEC 29148 and What Professional Requirements Management Means

    ISO/IEC 29148 describes what is required to work systematically with requirements throughout the lifecycle. The standard emphasises that requirements should be unambiguous, verifiable, traceable and consistently structured. A central principle is that requirements are not text passages, but information objects. Each requirement must be identifiable, referenceable, changeable and verifiable independently of which document it happens to be in.

    Responsibility for Requirements in Technical Projects

    Responsibility can be simplified to three main roles. The business owns “why” – they have the need and must ultimately be able to judge whether the solution fulfils its purpose. The project is responsible for translating the business’s needs into a feasible solution – developing FRS and TRS, coordinating design and managing suppliers. Suppliers are responsible for implementing according to the TRS and demonstrating that requirements are met.

    When responsibility is not clear, gaps arise where requirements fall between the cracks.

    Requirements, Verification and Validation

    The abstraction level of a requirement is directly linked to how verification and validation are carried out.

    Installation Qualification verifies that the solution is installed according to technical requirements and maps primarily to the TRS.

    Operational Qualification verifies that the system performs its specified functions and maps to the FRS.

    Performance Qualification verifies that the solution meets the business need in real operation and maps to the URS.

    This shows clearly why business requirements cannot be written by the supplier. Whoever is to approve the value must own the requirements.

    Linking requirements to tests

    • The URS is verified by the business assessing whether the need is met
    • The FRS is verified through functional testing
    • The TRS is verified through technical installation and inspection

    Verification without clear requirements becomes a check of workmanship, not of need.

    Contract Documents and the Dual Roles of Documents

    In many projects, technical descriptions and system documents are used as combined documents for requirements, function and execution. In Swedish design-build contracts (ABT 06) this is common practice, and it is not wrong in itself.

    The problem arises when these documents are expected to serve both as a description and as a verifiable requirements baseline. The requirements are there, but they are not identifiable as requirements.

    A document can contain requirements without being a requirements document. It is the role of the content, not the title of the document, that determines its function in the requirements chain.

    Common consequences of combined documents

    • Requirements cannot be traced to tests
    • Changes are handled informally
    • Discussions arise late in the project
    • Responsibility becomes unclear in a dispute

    This is not a methodology problem but a structural problem.

    Requirements as Information Objects Over the Lifecycle

    Requirements are not static. They change when the business changes, when technology is replaced and when systems are rebuilt. To handle this, requirements must be treated as information objects with a lifecycle – linked to functions, technical solutions, tests and documentation.

    Requirements work when they are separated from descriptive text, have a clear owner, can be verified, are traceable over time and are used even after the project ends. When these conditions are met, requirements become a governance tool, not administration.

    Do you have control of your requirements – all the way to commissioning?

    Inadequate requirements management is the most common reason technical projects overrun in both time and cost. In the role of technical owner’s representative and Owner’s Representative, HubMind helps you establish the structure that makes your requirements an active governance instrument for both project management, architecture and future asset management.

    When Requirements Management Becomes a Governance Tool

    A requirement is something that is to be fulfilled by someone other than the party stating it, and that can be verified.

    Everything else is a goal, a description or a solution, even if it happens to sit in the same document.

    Once this is clear, it also becomes clear why documents exist, who is responsible for what, and how technical projects can be governed through the entire lifecycle, from need to operation and change.

    Reflection

    A quick check of requirements maturity

    • Can you point to exactly which statements are requirements
    • Is it clear who owns each requirement
    • Can the requirements be verified without interpretation
    • Are the requirements used after commissioning

    If the answer to any of these questions is no, there is most likely room for improvement.

  • Digitalisation, Integration and Automation in Practice

    Digitalisation, Integration and Automation in Practice

    TL;DR

    Conclusion

    Without order in information (Digitalisation) and clear relationships (Integration), governance (Automation) will never be effective.

    Digitalisation

    is about information – making data comprehensible, traceable and useful across the entire lifecycle.

    Integration

    is about context – connecting systems and flows with clear interfaces and responsibilities.

    Automation

    is about governance – letting systems act independently based on logic and reliable data.

    Digitalisation as a Concept

    Digitalisation is one of the most used concepts in contemporary discussions about technology, business development and the future. At the same time, it is one of the most elusive. For some, digitalisation means replacing paper with systems. For others it is about data analytics, automation or new business models. In many contexts, the term is used as a catch-all for anything perceived as modern or technically advanced.

    This is why the sequence matters: first create order in information, then connect systems with clear interfaces, then let logic act on reliable data. Inverting this order leads to automation that amplifies uncertainty rather than creating clarity.

    In technical environments this becomes particularly clear. Digitalisation can refer to anything from building automation and industrial control systems to IT platforms, integrations and decision support. When the same word is used for such different things, misunderstandings easily arise between business, IT, OT and suppliers.

    Why the Concepts Are Often Mixed Up

    Digitalisation, integration and automation are closely related, but describe different things. In practice, they are often used interchangeably to describe the same initiative. A project can be described as a digitalisation project even though it is mainly about integration. Automation is sometimes used to describe remote monitoring, while integration is reduced to technical connections.

    This lack of precision leads to projects where the objectives, the work and the deliveries are never aligned. When digitalisation, integration and automation are described separately and in relation to each other, the conversation becomes more productive – for business, IT, OT and suppliers alike.

    Digitalisation in Technical Environments

    In technical environments, digitalisation primarily means making information about systems and facilities available in a structured, usable and long-term form. It is not primarily about installing new systems. It is about how information is organised, owned and used.

    Digitalisation creates the conditions for integration and automation by ensuring that data has meaning, context and traceability. Without this foundation, integration becomes a technical puzzle that must be rebuilt with every change, and automation risks acting on incorrect or misunderstood data.

    Integration as Architecture

    Integration in technical environments is not just about connecting systems. It is about creating structures where information flows in a controlled, comprehensible and maintainable way. Well-designed integration means clear interfaces, defined data flows and explicit responsibility for what is sent, received and handled in each system.

    When integration is treated as architecture rather than as individual technical connections, the result is more robust, scalable and possible to change without needing to rebuild from scratch.

    Automation as the Expression of Logic

    Automation is the layer where information and integration create visible value. Systems act on data, logic governs processes and operations are monitored and improved in real time. But automation is only as reliable as the data it acts on and the integrations that deliver that data.

    This is why the sequence matters: first create order in information (digitalisation), then connect systems with clear interfaces (integration), then let logic act on reliable data (automation). Inverting this order leads to automation that amplifies uncertainty rather than creating clarity.

    A Lifecycle Perspective

    The relationship between digitalisation, integration and automation is not static. As facilities develop, systems are replaced and new requirements arise, all three dimensions must be managed over time. This requires a lifecycle perspective where decisions today are made with an awareness of their consequences in ten years.

    Organisations that succeed with this work combine strategic thinking about information and architecture with practical execution in projects – always with the whole picture in mind, not just the current deliverable.

    Is your digitalisation built on the right sequence?

    We help organisations clarify what digitalisation, integration and automation actually mean in their specific context – and how the three can be built in a sequence that creates sustainable results rather than new technical debt.

  • IEC 81346: Start with Structure

    IEC 81346: Start with Structure

    HubMind field guide · IEC 81346

    IEC 81346.
    Start with structure.

    IEC 81346 is not primarily about naming equipment. It helps asset owners create shared structure and stable identity for technical objects throughout the lifecycle.

    Read the series

    From central idea to governed infrastructure.

    Three concise guides build on one another. Start with structure, change the view of the object, then finish with implementation and governance.

    From standard to application

    Need the structure to work in practice?

    Talk to us →
Contact us