Having solid business principles is key for a successful company. Small or large. Having good and solid business principles is key for developing a good architecture within solid time and cost constraints. Business principles SHOULD be defined and agreed upon within a solid process with all key business stakeholders involved.  The list with principles below can give you a head start, since these principles are collected from various successful businesses.

Be Collaborative
StatementBe Collaborative
RationaleThe saying: “If you want to go fast, go alone. If you want to go far, go together.” is attributed to an African proverb, but could easily be a mantra for technology-enabled development projects. The principle: Be Collaborative suggests strategies for leveraging and contributing to a broader commons of resource, action, and knowledge to extend the impact of development interventions.
Implications
  • Engage diverse expertise across disciplines and industries at all stages.
  • Work across sector silos to create coordinated and more holistic approaches.
  • Document work, results, processes and best practices and share them widely.
  • Publish materials under a Creative Commons license by default, with strong rationale if another licensing approach is taken.
Tag(s)business, design
Business continuity
StatementBusiness continuity of Corporate activities must be maintained, despite IT interruptions.
RationaleHardware failures, natural disasters, and lack of data integrity must not interrupt business activities.
Implications- Recoverability, redundancy, and maintenance must be approached at inception. - Applications must be assessed regarding criticality and impact on the company's mission to determine which continuity level is required and which corresponding recovery plan must be implemented. - A business continuity plan must be present/developed.
Tag(s)availability, business, continuity
Business Principle
StatementThese architectural principles will apply to all organisational units within the enterprise.
RationaleThe only way the University will be able to provide a consistent and measurable level of appropriately robust, reliable, sustainable services and quality information to decision-makers, is if all stakeholders abide by the University’s overarching principles for its technology, information and business architectures.
ImplicationsThis fundamental principle will ensure inclusion, consistency, fairness and continual alignment to the business. Without this the management of our technologies, information and business processes would be quickly undermined. Business Partners engaging with the business will work to find accommodation between interested parties around any conflicts with a principle relevant to the proposal.
Tag(s)business
Cohesiveness
StatementOur organization and business unites (and departments) shall present a consistent and unified face through a common and integrated approach to service delivery.
RationaleThe intent of this principle is to ensure that services are presented to consumers in a consistent and cohesive manner. Similarly, consumers will be presented with a common look, feel and experience regardless of what business unit service or channel they are accessing at the time. Adoption and continued use of a service by consumers will depend, to an extent, on ease of use enhanced by consistency of service delivery.
ImplicationsDepartments and Business unites will need to collaborate in the development of services. This will require open sharing of information, cross-agency planning, and understanding of whole-of-government service channels, segments and lines of business.
Tag(s)business
Compliance with Statutory Obligations
StatementEnterprise data and information management processes must comply with all relevant internal and external laws, policies, and regulations.
RationaleEnterprise policy is to abide by laws, policies, and regulations. This will not preclude business process improvements that lead to changes in policies and regulations.
ImplicationsThe enterprise must be mindful to comply with all laws, regulations, and external policies regarding the collection, retention, and management of data. Continual education, access and awareness to the rules must be maintained. Efficiency, need, and common sense are not the only drivers. Changes in the law and changes in regulations may drive changes in our processes or applications.
Tag(s)business
Create a MVP fast
StatementIf your MVP takes a year to build…it’s not an MVP.
RationaleCreating a MVP should take not more than 1 month.
ImplicationsA created MVP is not ready for sale, but ready to learn from for later stages.
Tag(s)business
1 2 3 4

CONSTRAINTS TEMPLATE

Name Constraint

Description

Definition,(What is it?)

Implications

what does it mean for the solution, what is the consequence for choices made.

Scope

Origin

who placed the constraint and why (if possible and needed)



ISO-25010-QualityTree

(Figure:source ISO25010 document)

The material of ISO is unfortunate not open. But since quality matters and ISO 25010 is used heavily for managing quality aspects within business IT systems a short overview.

Functionality

Functionality: A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs.

  • Functional suitability: Degree to which a product or system provides functions that meet stated and implied needs when used underspecified conditions.
  • Functional completeness : Degree to which the set of functions covers all the specified tasks and user objectives.
  • Functional correctness : Degree to which a product or system provides the correct results with the needed degree of precision.
  • Functional appropriateness : Degree to which the functions facilitate the accomplishment of specified tasks and objectives.

Reliability

Reliability: A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time. Attributes:

  • Reliability:Degree to which a system, product or component performs specified functions under specified conditions for a specified period of time.
  • Maturity : Degree to which a system, product or component meets needs for reliability under normal operation.
  • Availability : Degree to which a system, product or component is operational and accessible when required for use.
  • Fault tolerance : Degree to which a system, product or component operates as intended despite the presence of hardware or software faults.
  • Recoverability : Degree to which, in the event of an interruption or a failure, a product or system can recover the data directly affected and re-establish the desired state of the system.

Performance Efficiency

A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions.

  • Performance efficiency: Performance relative to the amount of resources used under stated conditions.
  • Time behaviour : Degree to which the response and processing times and throughput rates of a product or system, when performing its functions, meet requirements.
    Resource utilization : Degree to which the amounts and types of resources used by a product or system, when performing its functions, meet requirements.
  • Capacity :  Degree to which the maximum limits of a product or system parameter meet requirements.

Compatibility

Compatibility:Degree to which a product, system or component can exchange information with other products, systems or components, and/or perform its required functions, while sharing the same hardware or software environment.

  • Co-existence : Degree to which a product can perform its required functions efficiently while sharing a common environment and resources with other products, without detrimental impact on any other product.
  • Interoperability : Degree to which two or more systems, products or components can exchange information and use the information that has been exchanged.

Usability

Usability:Degree to which a product or system can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

  • Appropriateness recognizability : Degree to which users can recognize whether a product or system is appropriate for their needs.
  • Learnability : Degree to which a product or system can be used by specified users to achieve specified goals of learning to use the product or system with effectiveness, efficiency, freedom from risk and satisfaction in a specified context of use.
  • Operability : Degree to which a product or system has attributes that make it easy to operate and control.
  • User error protection : Degree to which a system protects users against making errors.
  • User interface aesthetics : Degree to which a user interface enables pleasing and satisfying interaction for the user.
  • Accessibility : Degree to which a product or system can be used by people with the widest range of characteristics and capabilities to achieve a specified goal in a specified context of use.

Security

Security:Degree to which a product or system protects information and data so that persons or other products or systems have the degree of data access appropriate to their types and levels of authorization.

  • Confidentiality : Degree to which a product or system ensures that data are accessible only to those authorized to have access.
  • Integrity : Degree to which a system, product or component prevents unauthorized access to, or modification of, computer programs or data.
  • Non-repudiation : Degree to which actions or events can be proven to have taken place, so that the events or actions cannot be repudiated later.
  • Accountability : Degree to which the actions of an entity can be traced uniquely to the entity.
  • Confidentiality : Degree to which a product or system ensures that data are accessible only to those authorized to have access.
  • Authenticity : Degree to which the identity of a subject or resource can be proved to be the one claimed.

Maintainability

  • Maintainability:Degree of effectiveness and efficiency with which a product or system can be modified by the intended maintainers.
  • Modularity : Degree to which a system or computer program is composed of discrete components such that a change to one component has minimal impact on other components.
  • Reusability :Degree to which an asset can be used in more than one system, or in building other assets.
  • Analysability : Degree of effectiveness and efficiency with which it is possible to assess the impact on a product or system of an intended change to one or more of its parts, or to diagnose a product for deficiencies or causes of failures, or to identify parts to be modified.
  • Modifiability : Degree to which a product or system can be effectively and efficiently modified without introducing defects or degrading existing product quality.
  • Testability : Degree of effectiveness and efficiency with which test criteria can be established for a system, product or component and tests can be performed to determine whether those criteria have been met.

Transferability

  • Portability:Degree of effectiveness and efficiency with which a system, product or component can be transferred from one hardware, software or other operational or usage environment to another
  • Adaptability : Degree to which a product or system can effectively and efficiently be adapted for different or evolving hardware, software or other operational or usage environments.
  • Installability : Degree of effectiveness and efficiency with which a product or system can be successfully installed and/or un-installed in a specified environment.
  • Replaceability : Degree to which a product can replace another specified software product for the same purpose in the same environment.

 

Note that when you do a critical review on ISO20510 you will find that missing in ISO25010 is:

  • Functional requirements
  • Compliance (e.g. with laws, standards) requirements
  • Documentation, Support and Training requirements and of course:
  • Project Timing requirements
  • Project Budget requirements

Having solid NFR (Non Functional Requirements) makes the difference between successful business IT projects and IT disasters. Below a list of NFR requirements that are ready to be (re)used within your project:

 

A test specification for the system must be available
Name of REQA test specification for the system must be available
TypeBusiness Requirement
despcriptionA test specification for the system must be available in order to perform test of the created system.
PriorityCould
Tag(s)Documentation, NFR
Data logging:Sensitive data is not logged in clear text by the application.
Name of REQData logging:Sensitive data is not logged in clear text by the application.
TypeImplementation
despcriptionSensitive data is not logged in clear text by the application.
PriorityCould
Tag(s)NFR, Security
Database connections, passwords, keys, or other secrets are not stored in plain text.
Name of REQDatabase connections, passwords, keys, or other secrets are not stored in plain text.
TypeBusiness
despcriptionDatabase connections, passwords, keys, or other secrets are not stored in plain text.
PriorityCould
Tag(s)NFR, Security
Disaster Recovery
Name of REQDisaster Recovery
TypeBusiness Requirement
despcriptionThe solution will be configured to be split across the two data centers where possible with failover from data center to data center in the event of a disaster, In addition, each data center needs to be able to run in a self sufficient manner should it become isolated from the other.
PriorityCould
Tag(s)NFR
Documentation must be available in an open document format
Name of REQDocumentation must be available in an open document format
TypeSystem Requirement
despcriptionAll system documentation must be made available in open document format. System documentation is (not exhausted) operational manuals, code documentation, test specs and test reports, installation manuals.
PriorityCould
Tag(s)Documentation, NFR
High Availability
Name of REQHigh Availability
TypeBusiness Requirement
despcriptionAll components should be configured in a high availability configuration to eliminate single points of failure, and minimize solution outages.
PriorityCould
Tag(s)NFR
Maintainability
Name of REQMaintainability
TypeBusiness Requirement
despcriptionThe system should allow for easy software upgrades with minimal outage. The outage should be restricted to no longer than one day, and allow for the use of a back up system for service continuity while the upgrade the taking place.
PriorityCould
Tag(s)NFR
Maintainability
Name of REQMaintainability
TypeSystem Requirement
despcriptionAny solution must be maintainable by the affected maintenance team, both initially and throughout its lifecycle. Unnecessary complexity in maintenance, such as by requiring additional / unusual skills or tools or having a complex solution design, adds risk to the solution’s supportability and must be justified.
PriorityCould
Tag(s)maintainability, NFR
Manageability
Name of REQManageability
TypeSystem Requirement
despcriptionAll solutions must be managed throughout their lifecycle, including startup, shutdown, backup, updates, security / permission changes, etc. Administrators and support personnel must be able to conduct such routine activities effectively in order to ensure that the solution does not incur excessive cost or experience unnecessary outages.
PriorityCould
Tag(s)manageability, NFR
Minimize Footprint
Name of REQMinimize Footprint
TypeBusiness Requirement
despcriptionStack multiple components within single operating system instances where possible to minimize both the number of physical and virtual servers required to run the solution.
PriorityCould
Tag(s)NFR
Service levels
Name of REQService levels
TypeSystem Requirement
despcriptionThe required service level(s) for any solution affect its design, cost, maintenance and support. As such, these must be known.
PriorityCould
Tag(s)NFR, service levels
Supportability
Name of REQSupportability
TypeIT Requirement
despcriptionAny solution must be supportable by the affected operations and maintenance teams, both initially and throughout its lifecycle. Unnecessary complexity in support, such as by requiring additional / unusual skills or tools, adds risk to the solution’s supportability and must be justified. The maintenance support team will be responsible for the success of the solution during its production life. As such, they require training, mentoring and appropriate transition measures to ensure they are able to successfully support the new component in the production environment.
PriorityCould
Tag(s)NFR, supportability
The certificate must be an X.509v3 certificate
Name of REQThe certificate must be an X.509v3 certificate
TypeBusiness
despcriptionThe certificate must be an X.509v3 certificate. The certificate must be within the valid period. The certificate must be verified and validated through authentication. The system will not issue digital certificates. Users will present trusted third party-issued certificates that are valid and verifiable by the system.
PriorityCould
Tag(s)NFR, Security
User ID must be unique and passwords must be stored in irreversible encrypted form
Name of REQUser ID must be unique and passwords must be stored in irreversible encrypted form
TypeBusiness
despcriptionUser ID must be unique. Passwords must be stored in irreversible encrypted form, and the password file cannot be viewed in unencrypted form. A password must not be displayed on the data entry/display device. Passwords must be at least eight characters long. Passwords must be composed of at least three of the following: English uppercase letters, English lowercase letters, numeric characters, and special characters. Password lifetime will not exceed 60 days Users cannot use the previous six passwords. The system will give the user a choice of alternative passwords from which to choose. Passwords must be changed by the user after initial logon.
PriorityCould
Tag(s)NFR, Security

Every serious project SHOULD have principles and/or requirements defined.  Using de-facto standards as add-on for your functional requirements can speed up your project. Below a list of sources of requirements that can speed up business IT projects:

 

Business Process Models must be based on BPMN 2.0
Name of REQBusiness Process Models must be based on BPMN 2.0
TypeBusiness Requirement
despcriptionBPMN 2.0 must be used A standard Business Process Model and Notation (BPMN) will provide businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner. Furthermore, the graphical notation will facilitate the understanding of the performance collaborations and business transactions between the organizations. See: http://www.bpmn.org/
PriorityCould
Tag(s)standard
Digital Signature Standard (DSS) (FIPS PUB 186 – 4)
Name of REQDigital Signature Standard (DSS) (FIPS PUB 186 – 4)
TypeQoS(Quality-of-Service)
despcriptionDigital Signature Standard (DSS) - FIPS PUB 186-4 This Standard defines methods for digital signature generation that can be used for the protection of binary data (commonly called a message), and for the verification and validation of those digital signatures. Three techniques are approved. (1) The Digital Signature Algorithm (DSA) is specified in this Standard. The specification includes criteria for the generation of domain parameters, for the generation of public and private key pairs, and for the generation and verification of digital signatures. (2) The RSA digital signature algorithm is specified in American National Standard (ANS) X9.31 and Public Key Cryptography Standard (PKCS) #1. FIPS 186-4 approves the use of implementations of either or both of these standards and specifies additional requirements. (3) The Elliptic Curve Digital Signature Algorithm (ECDSA) is specified in ANS X9.62. FIPS 186-4 approves the use of ECDSA and specifies additional requirements. Recommended elliptic curves for Federal Government use are provided herein. See: http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf
PriorityCould
Tag(s)Security, standard
FIPS PUB 198-1:The Keyed-Hash Message Authentication Code (HMAC)
Name of REQFIPS PUB 198-1:The Keyed-Hash Message Authentication Code (HMAC)
TypeBusiness
despcriptionFIPS PUB 198-1:The Keyed-Hash Message Authentication Code (HMAC) Providing a way to check the integrity of information transmitted over or stored in an unreliable medium is a prime necessity in the world of open computing and communications. Mechanisms that provide such integrity checks based on a secret key are usually called message authentication codes (MACs). Typically, message authentication codes are used between two parties that share a secret key in order to authenticate information transmitted between these parties. This Standard defines a MAC that uses a cryptographic hash function in conjunction with a secret key. This mechanism is called HMAC [HMAC]. HMAC shall use an Approved cryptographic hash function [FIPS180-3]. HMAC uses the secret key for the calculation and verification of the MACs. See:http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf
PriorityCould
Tag(s)Security, standard
Implementation must comply to the”Do Not Track Compliance Policy”
Name of REQImplementation must comply to the”Do Not Track Compliance Policy”
TypeImplementation
despcriptionThe website (DNS) is compliant with the privacy-friendly Do Not Track (DNT) Policy of the EFF.org organization. Reference: https://www.eff.org/dnt-policy w3c reference: http://www.w3.org/TR/tracking-dnt/
PriorityCould
Tag(s)Privacy, standard
JSON-LD
Name of REQJSON-LD
TypeImplementation
despcriptionJSON-LD is a lightweight Linked Data format. It is easy for humans to read and write. It is based on the already successful JSON format and provides a way to help JSON data interoperate at Web-scale. JSON-LD is an ideal data format for programming environments, REST Web services, and unstructured databases such as CouchDB and MongoDB. See: http://json-ld.org/
PriorityMust
Tag(s)standard
Payment Card Industry (PCI) DSS v3.1
Name of REQPayment Card Industry (PCI) DSS v3.1
TypeBusiness
despcriptionThe design/implementation must be compliant with the Payment Card Industry (PCI) Data Security Standard version 3.1 PCI DSS provides a baseline of technical and operational requirements designed to protect account data. PCI DSS applies to all entities involved in payment card processing — including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD). Detailed spec on: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf
PriorityCould
Tag(s)Security, standard
Payment Card Industry (PCI) Point – to – Point Encryption
Name of REQPayment Card Industry (PCI) Point – to – Point Encryption
TypeQoS(Quality-of-Service)
despcriptionPayment Card Industry (PCI) Point - to- Point Encryption Solution Requirements and Testing Procedures Version 2.0 (Revision 1.1) The objective of this standard is to facilitate the development, approval, and deployment of PCI-approved P2PE solutions that will increase the protection of account data by encrypting that data from the point of interaction within the encryption environment where account data is captured through to the point of decrypting that data inside the decryption environment, effectively removing clear-text account data between these two points. The requirements contained within this standard are intended for P2PE solution providers and other entities that provide P2PE components or P2PE applications for use in P2PE solutions, as well as P2PE assessors evaluating these entities. Additionally, merchants benefit from using P2PE solutions due to increased protection of account data and subsequent reduction in the presence of clear -text account data within their environments. Details specs can be found at: https://www.pcisecuritystandards.org/documents/P2PE_v2_r1-1.pdf
PriorityCould
Tag(s)Security, standard
Secure Hash Standard (SHS) – FIPS PUB 180 – 4
Name of REQSecure Hash Standard (SHS) – FIPS PUB 180 – 4
TypeImplementation
despcriptionThis Standard specifies secure hash algorithms, SHA -1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA- 512/256. All of the algorithms are iterative, one-way hash functions that can process a message to produce a condensed representation called a message digest. These algorithms enable the determination of a message’s integrity: any change to the message will, with a very high probability, result in a different message digest. The digests are used to detect whether messages have been changed since the digests were generated. See: http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf
PriorityCould
Tag(s)Security, standard
Semantic Versioning
Name of REQSemantic Versioning
TypeQoS(Quality-of-Service)
despcriptionAll version numbering must match Semver 2.0 Given a version number MAJOR.MINOR.PATCH, increment the:
  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards-compatible manner, and
  3. PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. See: http://semver.org/
PriorityMust
Tag(s)standard
Systems must comply with BIOS Integrity Measurement Guidelines
Name of REQSystems must comply with BIOS Integrity Measurement Guidelines
TypeQoS(Quality-of-Service)
despcriptionThe systems must implement measurements as described in the NIST Special Publication 800-155 (BIOS Integrity Measurement Guidelines). Client computers such as desktops and laptops rely on the Basic Input/Output System (BIOS) to initialize their hardware during boot. The BIOS is firmware, and it can be configured. If the BIOS code or configuration is altered from the intended state, either maliciously or accidentally, the desktop or laptop may experience losses of confidentiality, integrity, and availability, including system instability, system failure, and information leakage. See: http://csrc.nist.gov/publications/drafts/800-155/draft-SP800-155_Dec2011.pdf for more information
PriorityCould
Tag(s)Security, standard
Web Hypertext Application Technology Working Group (WHATWG)
Name of REQWeb Hypertext Application Technology Working Group (WHATWG)
TypeImplementation
despcriptionThe Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications. The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born. See: https://whatwg.org/
PriorityMust
Tag(s)Browser, standard

When creating business IT documentation (e.g. IT architectures/designs) following these rules will help for producing sound documentation:

  1. Documentation should be written from the point of view of the reader, not the writer.
  2. IT Documentation should be organized for ease of reference, not ease of reading. A document may be read from cover to cover at most once, and probably never. But a document is likely to be referenced hundreds or thousands of times.
  3. Avoid repetition. Each kind of information should be recorded in exactly one place. This makes documentation easier to use and much easier to change as it evolves. It also avoids confusion.
  4. Avoid unintentional ambiguity. In some sense, the point of architecture is to be ambiguous. However unplanned ambiguity is when documentation can be interpreted in more than one way, and at least one of those ways is incorrect. A well-defined notation with precise semantics goes a long way toward eliminating whole classes of linguistic ambiguity from a document. This is one area where architecture description languages help a great deal, but using a formal language isn’t always necessary.
  5. Standardize your documentation. Use always the same templates for the same documents within your organization. Even better: Make use of de-facto standardizations that also make sense for people outside your organization, since you will be working with many people outside your organization during the life cycle of your product. A standard organization offers many benefits. It helps the reader navigate the document and find specific information quickly.
  6. Record rationale. So document decisions made. Recording rationale will save you enormous time in the long run, although it requires discipline to record in the heat of the moment. It will prevent the same discussions over and over again and everyone knows why the chosen path is taken.
  7. Keep it current. Documentation that is out of date, does not reflect truth, and does not obey its own rules for form and internal consistency will not be used. Documentation that is kept current and accurate will be used.
  8. Review documentation for fitness of purpose. Only the intended users of a document will be able to tell if it contains the right information presented in right way.
Server connection bandwidth (KBS)
Pages per visitor:
Page size: bytes
Overhead margin %:
(100 is no margin)
Traffic Megabyte per day
Gigabyte per month
Visitors Visitors per second
Visitors per day
Visitors per month
Pages Pages per second
Pages per day
Pages per month
Download time per page seconds
Simultaneous visitors
at 1 page per minute
Visitors

Finding out how much traffic your web server can handle can be hard. This simple calculator gives you a head start when creating a good architecture for web server. Given the upload speed it will calculate the maximum number of visitors you can handle. To allow for peaks the calculator takes a 300% overhead margin into account.

The calculator uses the following formulas:

  • Bandwidth = ConnectionBandwidth * 100 / OverheadMargin
  • Traffic in Megabytes per day = Bandwidth * 86400 * 1000 / (8 * 1048576)
  • Traffic in Gigabytes per month = Bandwidth * 86400 * 1000 * 30.41 / (8 * 1073741824)
  • Visitors per second =Bandwidth * 1000 / (PagesPerVisitor * PageSize * 8)
  • Visitors per day = Bandwidth * 86400 * 1000 / (PagesPerVisitor * PageSize * 8)
  • Visitors per month = Bandwidth * 86400 * 1000 * 30.41 / (PagesPerVisitor * PageSize * 8)
  • Pages per second = Bandwidth * 1000 / (8 * PageSize)
  • Pages per day = Bandwidth * 86400 * 1000 / (8 * PageSize)
  • Pages per month = Bandwidth * 86400 * 1000 * 30.41 / (8 * PageSize)
  • Download time per page = PageSize * 8 / (Bandwidth * 1000)
  • Simultaneous visitors = 60 * Bandwidth * 1000 / (PageSize * 8)
Time 13 years, 352 days, 5 hours

Making high level and detailed calculations of network links is crucial for a good functioning system. Use the (very simple) calculator below to start with. And remember: 1 kbyte = 8 kbit -)

Integration principles are used within successful business IT projects. (Re)use the integration principles from the collection below.

Do not hesitate to add your data principles to this list so everyone can benefit. Click here to add your contribution.

Accessible
StatementData is available to the widest range of users for the widest range of purposes.
Rationale
Implications
Tag(s)data, Integration
Documentation
StatementDocumentation
RationaleIt is well documented that documentation is an important characteristic for making software components reusable. Documentation for software is essential for any future use or modification and critical for maintainability. Programmers are unlikely to reuse software that is not well-documented or commented since it makes it harder to understand and maintain. Documentation should be self-contained, adaptable and extensible. Specific documentation for reuse of the component enhances the chances for usage of the component in future.
Implications
Tag(s)design, Integration, Software, Software development
Interoperability
StatementSoftware and hardware should conform to defined standards that promote interoperability for data, applications, and technology.
Rationale(Open) Standards help ensure consistency, thus improving the ability to manage systems and improve user satisfaction, and protect existing IT investments, thus maximizing return on investment and reducing costs. (Open) Standards for interoperability additionally help ensure support from multiple vendors for their products, and facilitate supply chain integration.
Implications(Open) Interoperability standards and industry standards will be followed unless there is a compelling business reason to implement a non-standard solution. A process for setting standards, reviewing and revising them periodically, and granting exceptions must be established. The existing used standards used within IT platforms and applications must be identified and documented.
Tag(s)Integration
Machine processable
StatementData is reasonably structured to allow automated processing.
Rationale
Implications
Tag(s)data, design, Integration
Prefer Real-time Data Exchange
StatementData exchange speed and latency must be based on business need, with a preference for real-time exchange to improve the delivery of services.
Rationale
  • Decisions made based on old data have lower accuracy and may lead to errors and/or inconsistencies.
  • Users/Services expect the most recent data to be available in their work processes.
Implications
  • All changes to data are processed immediately and are distributed to all other IT systems that use the data.
  • Where data capture systems and the authoritative source for data are different, data must be shared with the authoritative source at the speed required by the most timesensitive usage of the data. This includes all data that is encompassed in a given transaction.
  • Data exchange speeds will often be driven by the needs of the most time sensitive usage of the data.
Tag(s)Integration
Primary data
StatementData is as collected at the source, with the highest possible level of granularity, not in aggregate or modified forms.
Rationale
Implications
Tag(s)data, Integration
1 2

Principles are used within successful business IT projects. A principle is a qualitative statement of intent that should be met by the architecture.

Do not hesitate to add your data principles to this list so everyone can benefit. Click here to add your contribution.

Accessible
StatementData is available to the widest range of users for the widest range of purposes.
Rationale
Implications
Tag(s)data, Integration
Machine processable
StatementData is reasonably structured to allow automated processing.
Rationale
Implications
Tag(s)data, design, Integration
Primary data
StatementData is as collected at the source, with the highest possible level of granularity, not in aggregate or modified forms.
Rationale
Implications
Tag(s)data, Integration
Timely
StatementData is made available as quickly as necessary to preserve the value of the data.
Rationale
Implications
Tag(s)data, Integration