Design Principles

Designing solutions means they fit the future. Design for tomorrow, not today, but keeping them fit for a longer time, able to handle future changes. Designs to support agility and flexibility.

Contact Us

DOMAIN BASED ARCHITECTURE

Reduced complexity

Integration kills flexibility

New service models

Less investments, less hardware dependency

Platform based

Make the most of it, get the most out of it

Clear governance

Ownership of data and solutions

Strategic choices that co-shape an IT Strategy

Independent of the choices on the Governance of the Company, there is an identifiable minimum footprint of shared IT (in a Group consellation)
Basic Connectivity
Clear decision-making guidelines and protocols and an escalation process for decision resolution procedures
Secure Identity and Access Management
Financial Consolidation – delivering a transparent bottom line to the shareholders.
IT should be organized close to the business, which translates into a “decentral IT unless…” principle. The unless is defined by clear:
- Economies of scales
- Economies of skills
- Strategic group interest
To contribute to the competitiveness. use modern solutions available in the market (leading edge technology, but not “bleeding edge”)
Cloud first.
- Reduce complexity, hardware footprint, spike-investments
- Limit forced disturbance of the landscape (upgrades)
- Follow the (technical) solution improvement
- Have more predictable IT-cost
- Are more (easily) scalable and Quicker scalable (up or down), with shorter response times
- Support standardization within an application
A single vendor strategy (as much as possible), within Domains as well as overarching. This brings (implicit) complexity reduction: In interfaces (because these will be native), in the number of applications, In usability (because user interfaces will be similar)
Use existing best practices. If there are excellent experiences in the company, re-use these instead of going outside for something new
Buy, not build. Self-development as well as customization of purchased software should be strictly avoided. Exceptions should have a very strong business reason supported by a business case that is calculated over at least 5 years including operational costs in full