Overview of ISO 25010

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

Simple Network Bandwidth Calculator

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 -)

[bms-bandwidthcalculator]

Architectures References

The field of business IT Architecture is covered with many many methods, foundations, industry organizations and reference architectures. So whatever the specific domain you are active in use and re-use information already there as described a solid reference architecture.  And do not forget: When you publish your architecture document on the web, make sure to use a common creative license, so others can improve, reuse and build upon your work.

Link Categories Overview
Architecture magazines (6)Architecture Methods (12)Architecture organizations (16)Architecture Patterns (2)
Cloud (4)Example Architecture (1)Foundation Architectures (3)Guidelines (2)
Industry Architectures (6)Microservices (3)Mobile (1)Principles (4)
Reference architectures (37)Security architecture (8)Software Architecture (2)Standards (6)

 

Architecture checklists

An architecture checklist helps in the governance process. Architecture checklists can become long, complex and time consuming in usage. However the aim with this architecture checklist is that it will help you and all your stakeholders involved in a simple way when you are dealing with architecture quality and risk aspects.

This architecture checklist is composed out of some critical questions that all relate back to the main goal of doing architecture in the first place.

Simple architecture checklist questions:

  • Is your main goal covered and reached with this architecture?
  • Does the architecture address operability?
  • Does the architecture address the following quality attributes:
    • performance
    • availability
    • maintainability
    • modifiability
    • security
    • privacy
    • testability
    • operability
    • flexibility
  • Does the architecture address and use principles? E.g. business principles.
  • Can implementation risks easily be derived out of your architecture deliverables?
  • Are architecture reviews done in a structured way? Architecture reviews SHOULD be performed to increase quality, control costs and reduce risks.
  • Is it clear what assumptions are used for your architecture? (Take explicit and implicit assumptions into account!)

 

 

Application Architecture

The application architecture describes the application components of a system. Part of the application architecture is providing high level insights in the software building blocks, services and micro services that are part of the application landscape.

 

Tools for creating an application architecture

Many OSS tools for creating an application are targeted on creating software code. Although an IT architect should be able to code, most of the time architects are more concerned with designing building blocks, interfaces and implementation constrains.

Using the following tools for creating an application architecture saves time and increases the quality of your application architecture:

  • UMLet. UMLet is an open-source UML tool with a simple user interface: draw UML diagrams fast, export diagrams to eps, pdf, jpg, svg, and clipboard, share diagrams using Eclipse, and create new, custom UML elements.
  • Papyrus Modeling environment. Papyrus is an industrial-grade open source Model-Based Engineering tool. Papyrus is the base platform for several industrial modelling tools. Papyrus can be used as graphical modelling tool, but aims to support MDA (Model Driven Architecture) completely.
  • Archi. Since Archi(tm) is a real TOGAF based architecture/desing tool, Archi is a good solution for creation of an application architecture.
  • Open ModelSphere. Open ModelSphere is a powerful data, process and UML modeling tool.
  • Modelio. Modelio is a modelling environment, supporting a wide range of models and diagrams, and providing model assistance and consistency checking features. Modelio can also generate Java code.

Creating an application architecture will lead to creating internal and external interfaces. APIs form the connecting glue between modern applications. Creating good interfaces is a MUST for every good architecture. Below some open tools that can help to speed up this step:

  • Integration Principles. With this tool you can easily (re)use good integration principles for your project.
  • API Blueprint. API Blueprint is all about the design-first philosophy. API Blueprint itself is OSS and has a growing base of OSS tools based on the spec. API Blueprint supports the complete chain for interface development (design, test, create etc).
  • Swagger based tools. Swagger is a simple yet powerful representation of your RESTful API. Swagger has a large ecosystem of OSS tools that assist in creating, testing and documenting APIs.
  • RAML based tools. RESTful API Modeling Language (RAML) makes it easy to manage the whole API lifecycle from design to sharing. The RAML specification is designed for design APIs better and faster.
  • API Design and tools. For good integration architecture you SHOULD dive into design problems to get your architecture straight. Google is of course the number one company when it comes to large scale API design. So use this internal Google API design guide.

 

Application Architecture Templates

To speed up the process of creating an application architecture you SHOULD make use of one of the templates below.

 

Data Architecture

Every business, small or large SHOULD have a data architecture. In the core a data architecture gives the overview and insights into the only one real value of your IT: Information. A data architecture gives overviews, visuals and describes e.g.:

  • What data is used where and how.
  • Who owns what data.
  • How is information created from data sources.
  • Internal and external data sources used.
  • Privacy & Security aspects of data (so be sure to have an data owner)
  • What structures, objects and relations are the core of your information model?

Tools for creating a data architecture

To speed up the process for creating a data architecture you SHOULD use tools. Below is a selection of tools that will speed up the process of creating your data architecture. Be aware that data modelling and database design are two very different activities.  The emphase for a data architecture SHOULD be on the conceptual and logical data models. In general  physical data models are related to the sql or nosql storage engine used, in combination with scalability(performance) and security requirements.

  • Data Principles. Using data principles saves you time and cost. Especially in the long term. Selecting data principles you need in your project of a solid collection gives you a head start.
  • Protégé. Protégé is a free, open source ontology editor and knowledge-base framework. This open-source ontology editor and framework can be used for for building intelligent systems. The tool is developed by the Stanford Center for Biomedical Informatics Research and has a large and active community of users and developers.
  • Archi.  Archi™ GUI tool for creating an architecture, using the ArchiMate modelling™ language. Since Archi is targeted to all architecture aspects, this tool is usuable for creating conceptual, logical and physical data models too.
  • WWW SQL Designer.  This tool allows you to draw and create database schemas (E-R diagrams) directly in browser. A physical data model (sql) can also be imported and adjusted visually.
  • MySQL Workbench. MySQL Workbench enables a DBA, developer, or data architect to visually design, model, generate, and manage databases. It includes everything a data modeler needs for creating complex ER models, forward and reverse engineering, and also delivers key features for performing difficult change management and documentation tasks that normally require much time and effort.
  • JSON Schema. Nice short book that gives you help with creating your JSON Schema.

 

Data Architecture Templates

To speed up the process of create your data architecture you SHOULD make use of standardized open templates. The following templates are provided:

Business Architecture

A Business Architecture defines the structure of your organization in terms of its governance structure, business processes, business services and products, business information and stakeholders. A business architecture outlines the relation to strategic goals towards a working system. So in short a business architecture can be regarded as a blueprint of the working of an organization. By using a business architecture your organisation can handle changes and problems with less cost and in less time since you know all the important dependencies, relation and information flows.  Every successful organisation, small or large, SHOULD have a business architecture. A business architecture does not have to be fully descriptive, complete or created among a certain standard. Designing organisations and describing the working of an organisation is know to be complex and hard. However simple tools exist to create a meaningful business architecture for your organisation.

This section is created to speed up the process for creating a real business architecture.

You can use one of the following tools:

  • Business architecture template(s)
  • (Re)use  business principles
  • Modelling your business processes
  • Defining your business products

Tools for creating a business architecture

To speed up the process of creating your business architecture you can make use of one of the following tools:

  • (Generic) Business principles
  • Archi.  Archi™ GUI tool for creating a business architecture using the ArchiMate modelling™ language. The Archi tool is targeted toward all levels of Architects. The tool is MIT Licensed, so it provides a low cost solution to users who are looking for a free, open ArchiMate modelling tool.
  • Camunda Modeler. Camunda Modeler is an OSS desktop application for editing BPMN process diagrams(2.0) and DMN decision tables. It is very easy to use, which means that business analysts can use it as well as developers, working on the same diagrams. Camunda Modeler is part of an open source platform for workflow and business process management. So when you use the Camunda suite you can also use the execution engine for your processes you have modelled.
  • Protégé. Protégé is an OSS web or desktop application that can be used for building business ontologies.

Business architecture templates

Creating a business architecture means doing real business research. However for a quality business architecture it make sense to make use of a draft template. From a template you can easily add, remove or change subjects that need special attention within your context. Also since architecture documents always should be created for a clear business goal and to be used by different stakeholders, all quality documents SHOULD contain some default reusable text blocks.

 

Using business viewpoints

Viewpoints can provide benefit to address specific concerns for certain stakeholders. Below a list of most used viewpoint within a business architecture:

  • Motivation view: describes what the business achieves for itself and its stakeholders (direct and indirect value).
  • Capability view: describes how the business delivers direct and indirect value in response to the challenges of the environment.
  • Activity view: describes the day-to-day behaviour of the business.
  • Responsibility view: captures the relationships between individuals and organizations in terms of responsibilities and commitments. These  relationships and organizational interfaces may be represented as business services.

Help for creating a business architecture

 

 

Introduction

Smart people have been thinking on how to create IT architectures as long as there has been computers. Ideas come and go, however creating a good architectures can still be complex and time consuming. Especially when you try to invent the wheel for yourself. With this interactive playbook you can create your IT architecture better and faster. The focus of this architecture playbook is in on:

  1. Knowledge reuse. Why reinvent the wheel again? It is far and more fun to create a better wheel for your organisation or IT project instead! Focus on the hard complex context specific issues. Use good open tools and knowledge for the easy 80%!
  2. Easier creation of architecture documents and deliverables. This playbook has an extensive list of all(*) open tools available for creating your IT architecture or design. Using these open tools will speed up the process of creating your architecture deliverables and reduce your risks.
  3. Quality improvement. By making use of content parts provided for various architecture deliverables you will lower your business risks. Complex business IT projects will fail. Now and in future. But if you make use of proven methods and tools developed from decades of IT architecture scientific research you will lower the risk for your project. Architecture will help to make your projects more successful in terms of costs, speed and profitability.

(*) If you miss a good open tool that is also usable for IT architecture creation, do not hesitate to contribute to this open publication!

This architecture playbook is divided in the commonly used architecture sections:

  • Business
  • Data
  • Applications and of course
  • Technology Infrastructure (TI)

This playbook is primarily created for on-line usage. But also ePUB and PDF versions are available.

 

Why this architecture playbook?

Creating a business IT architecture has many benefits. However creating a complete architecture is known to be:

  • Difficult
  • Time consuming

Of course many tools have been developed the last 30 years to make creating architecture (documents) easier. However many tools force you into a very tight harness without the needed flexibility. Complex problems need flexible solutions and tools should not slow you down in creating sketches, documents and typical architecture deliverables. A one size fits tool for solving complex business IT problems does not exist. And since creating good architectures is knowledge intensive work that delivers real value for business you should be aware of vendor lock-ins and using methods and tools that do not share knowledge sharing. Open Source tools and open access documentation offer a default head start for reuse and improvement of knowledge work in IT architecture.

You can buy and read many many books on how to do architecture well. All books claim a magic method and promise ultimate success when followed. We love books and reading methods. E.g. TOGAF.  However this playbook is different. This architecture playbook is not about describing how you should create your architecture. You are free to use every method you want. This architecture playbook is all about giving you direct usable content and tools that you can use and reuse for your architecture challenge.

So this playbook brings you ultimate freedom and flexibility. You can export the results from certain tools in any desired format. In this way you can still use your architecture enterprise tool(s) that you already have invested deeply in. So use the outcome of tools within this playbook in combination with the enterprise architecture tool that are mandatory within your organisation.

 

What is in this architecture playbook?

Many good books and courses already exist that cover the why and how of (Enterprise) IT architecture. So this book will not explain aspects and concepts of the very broad field of IT architecture. This playbook is targeted on providing practical tools for creating your IT architecture or design faster and better. So the focus is 100% on the real thing by using the following leading principles:

  1. Tools that speed up creating your business IT Architecture.
  2. Templates ready to use for creating business IT Architecture documents.
  3. Collections of principles, requirements, standards and reference architecture that speed up the creation of your architecture deliverable.
  4. Collection of various Architecture OSS Tools that speed up creating your business IT architecture.
  5. Collection of architecture QA  tools to control and manage your IT projects.
  6. Collection of reusable reference architectures, foundation architecture, architecture journals and more. Knowing where you can find what in an easy way will reduce your time. So you will have more time to spend on solving your problem in your organization.

 

Caution: This architecture playbook contains OPEN material only!

This architecture playbook is created to be open. This means that:

  1. This architecture playbook is licensed using a liberal license (CC-BY-SA). This means that you can reuse remix, transform, and build upon the material in this architecture playbook for any purpose.
  2. All tools mentioned within this architecture playbook are licensed under a OSS license and all documents referenced to is licensed under an CC license whenever possible.

This gives you the opportunity to reuse and mix content from this architecture playbook the way you want. This also means that all tools mentioned to in this architecture playbook are open and free to use without costs. We believe that sharing tools and knowledge, especially knowledge for making better architectures SHOULD be free. If you want to host this Architecture Playbook on your own company site, Intranet or just want to have more information on the OSS tools: Contact Us, or visit the github repository.

Using the templates

The various templates can be downloaded in html or depending on your browser preferences directly opened in another browser tab. The templates can be easily used within various office suites (e.g. MSWord, OpenOffice, GoogleDocs). When you press [CTRL+A] and [CTRL+C] and paste the complete content into your favourite text editor with [CTRL+V] you can directly work on the various sections as outlined in the template. In case you need the template in another format of have other questions regarding using the templates: Just contact us!

Notational Conventions

This architecture playbook uses the key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”. This key words are to be interpreted as described in RFC 2119. Using these key words gives clarity and avoids confusion.