Introduction to reference architecture
Introduction to reference architecture
When you install the Thinkwise Platform, there are a number of hardware requirements and guidelines for the various components. These requirements and guidelines are described here. Software requirements are listed in the Thinkwise Lifecycle policy.
The performance of Thinkwise applications depends on the hardware but to a considerable extent also on the design of your application. Tips about performance tuning your applications can be found in Performance.
If you have any additional questions regarding the installation please contact your Thinkwise representative.
Backup
The Thinkwise Software Factory is the production environment for developers. It is your responsibility to have a backup strategy in place to ensure that you can recover from any data loss.
Monitoring
The Thinkwise platform offers extensive options for monitoring the quality and continuity of Thinkwise applications. In addition to this, it is essential to also monitor the infrastructure, such as network, servers and PCs, and mobile devices with an appropriate solution.
Microsoft System Center, PRTG, Zabbix or Nagios can, for example, be used to monitor the network and resources on servers.
For Mobile Device Management you can use, for example, Microsoft Intune, Citrix XenMobile, VMWare Airwatch or MobileIron.
Remote access
Thinkwise wants to offer you optimal support. To achieve this it is necessary that Thinkwise can offer support remotely. There must therefore be a method available for remote login for authorized Thinkwise employees.
Cloud hosting
It is possible to host the Thinkwise Platform and end products in a cloud environment and access it from a Windows user interface, using cloud providers that offer (Windows) Virtual Machines.
Dedicated SQL Server cloud solutions, such as Windows Azure SQL Database, are also supported as long as the required features are available. These solutions often offer a stripped-down version of SQL Server, without support, for example, for Integration Services, CLR procedures, Full Text Search and Profiling.
Choosing Between Azure SQL Database and SQL Managed Instance
Our software requires multiple databases per environment. For most environments (such as test, acceptance, and production), at least two databases are required. In the development environment, this number is higher: by default, there are at least three databases. The number of databases can increase when developers create a branch. For each branch, a separate database is set up, which the developer must be able to create independently.
Azure SQL Database
- Suitable when only one or a few fixed environments are needed.
- Easy to scale performance up or down: resources can be adjusted relatively quickly.
- Fully managed with automatic patching, backups, and high availability.
- Less suitable when many temporary databases are required (such as in development branches).
- Offer a stripped-down version of SQL Server, without support, for example, for Integration Services, CLR procedures and Profiling.
SQL Managed Instance
- A good choice when multiple environments and many databases are required. This is especially relevant for the development environment, where a new database is created for every branch.
- Provides more SQL Server functionality and higher compatibility.
- Developers can easily create new databases themselves.
- Less flexible in scaling performance: upgrading to higher capacity is more complex and takes more time.
Other cloud providers
- In AWS and Google Cloud, there are no direct equivalents to Azure SQL Database or Managed Instance.
- The only available option is to deploy a full SQL Server instance (Infrastructure as a Service).
- This approach requires additional management effort and, unlike Azure’s PaaS offerings, you also need to account for the SQL Server licensing costs.
Summary
- For a small number of fixed environments (for example, only test and production), Azure SQL Database is the better fit due to its simplicity and flexible scaling.
- For a full DTAP setup, and especially for a development environment where new databases are required per branch, SQL Managed Instance is often the better choice. This avoids management and cost issues when working with a large number of databases.
- Compared to AWS and Google Cloud, Azure provides more flexible and cost-effective options for SQL as a service.
Database management systems
The Thinkwise Platform supports the following database management systems:
- SQL Server
- DB2 for IBM i (AS400)
- Oracle Database
The Software Factory development environment and the Intelligent Application Manager are delivered on SQL Server. If you do not have an SQL Server environment then such an environment must be set up.
The supported versions of the database management systems are described in the Lifecycle policy.
SQL Server editions
Check the release notes to see which version of SQL Server is supported by your version of the Thinkwise Platform.
All editions of SQL Server, including the free Express edition, are supported. Be aware that there are differences in the supported features regarding, for example, scheduling and database mail. A requirement for your development environment is that the Full-Text Search feature is supported and installed.
- Overview of editions and supported features
- Hardware and software requirements for installing SQL Server
.NET Framework
Check the release notes to see which version of the .NET Framework is supported by your version of the Thinkwise Platform.
Indicium Application Tier
The Thinkwise Indicium Application Tier is a required component for the Software Factory and IAM. It is an ASP .NET Core application. The preferred deployment method is using a Microsoft Internet Information Services application server. The minimum requirements with regard to the application server depend on the expected load that the Application Tier must be able to handle, for example:
- The number of concurrent users
- The size and nature of the application
- The amount of data in the application
- Organizational requirements regarding performance
Thinkwise User Interfaces
Thinkwise Graphical User Interfaces (GUIs) are available for desktop, web and mobile devices. The Software Factory development environment requires the Windows GUI.
In 2026, the Software Factory will also become available as a cloud solution with the Universal GUI.
Universal GUI
The Universal GUI requires a modern browser. See also the Lifecycle policy.
Windows GUI
The Windows GUI is a desktop client and requires the Microsoft .NET Framework. Minimum hardware requirements for the Windows GUI are:
- The Windows GUI is compatible with 64-bit environments.
The Windows GUI is also suitable for use via Remote Desktop Services or in combination with Desktop (VDI) or Application Virtualization, such as:
- Microsoft App-V
- Microsoft Remote Desktop Services (RDS)
- Citrix XenDesktop
- Citrix XenApp
- VMWare View
- VMWare ThinApp
Depending on the amount of data and the use of the application the Windows GUI requires at least 350MB RAM memory per user.
For more information about RDS server requirements, see the Microsoft documentation.
DTAP environments
In modern software development and deployment practices, the use of structured DTAP environments — Development (D), Test (T), Acceptance (A), and Production (P) — is essential for ensuring software quality, stability, and controlled delivery. Each environment serves a specific purpose in the lifecycle of an application, allowing teams to build, validate, and deploy software in a predictable and secure manner.
The DTAP model promotes a clear separation of concerns between development activities and live production usage. It provides a controlled path for changes to move from initial implementation through to final release, while minimizing the risk of defects reaching end-users. By isolating each stage of development, teams can catch issues early, involve relevant stakeholders at the right moments, and ensure compliance with technical and business requirements.
Key benefits of using DTAP environments
- Improved quality assurance through dedicated testing and validation phases
- Risk reduction by catching bugs and misconfigurations before they impact users
- Better collaboration as developers, testers, and business users work in parallel
- More reliable deployments with production-ready code validated in controlled environments
A well-structured DTAP approach forms the backbone of continuous integration and delivery pipelines and helps organizations maintain agility without compromising on quality or security.
Example DTAP setup
Example DTAP setup with separate environments for development, testing, acceptance, and production
DB2 for IBM i
When the application is hosted on a DB2/AS400, make sure you:
-
Install all drivers
-
Configure firewall ports
-
Configure the PoolUser
Ports
-
ODBC / JDBC (DRDA via DB2)
- Port 446 (TCP) → Default port for DRDA, used by ODBC and JDBC clients to connect to DB2 on the AS/400.
- Alternative: Port 448 may be used for SSL connections.
-
Telnet / 5250 Terminal (for administration and testing)
- Port 23 (TCP) → Traditional telnet access.
- Port 992 (TCP) → Telnet via SSL (secure 5250).
-
Database Host Servers (for specific access methods)
IBM i uses multiple host servers, each with its own port:- 8470–8476 (TCP) → Various functions (ODBC, file access, remote command, data queue, etc.)
- 8471 → Database access (ODBC/JDBC)
- 8475 → Remote command server
- 8476 → Data queue access
-
Other possible ports (optional, depending on setup)
- 80 / 443 → IBM Navigator for i (web interface) or web services
- FTP: 20 / 21 → For data transfer via FTP to the AS/400
Thinkwise software distribution through DTAP landscape
In a structured software development and deployment process, the DTAP model (Development, Test, Acceptance, Production) provides a reliable and secure pathway to move applications from initial design to live use. The Thinkwise platform follows this approach closely, using the Thinkwise IAM DEV and Indicium application tier.
Example of software distribution through a DTAP landscape