nl There is also a DUTCH VERSION of this site

Jul 2014
UX/UI has no business rules
Jun 2014
Technical debt: a time related issue
Solution shaping workshops: this is where the magic happens
May 2014
Architecture life cycle
Project managers and architects
Sep 2013
Using ArchiMate for describing infrastructures
Jul 2013
Kruchten’s 4+1 views for solution architecture
Jun 2013
The SEI stack of solution architecture frameworks
TOGAF and infrastructure architecture
May 2013
The Zachman framework
An introduction to architecture frameworks
Apr 2013
How to handle a Distributed Denial of Service (DDoS) attack
Architecture Principles
Mar 2013
Views and viewpoints explained
Stakeholders and their concerns
Skills of a solution architect architect
Feb 2013
Solution architects versus enterprise architects
Definition of IT Architecture
Dec 2012
Infrastructure Architecture - Infrastructure Building Blocks and Concepts
What is Big Data?
How to make your IT "Greener"
What is Cloud computing and IaaS?
Purchasing of IT infrastructure technologies and services
IDS/IPS systems
IP Protocol (IPv4) classes and subnets
Infrastructure Architecture - Course materials
Nov 2012
Introduction to Bring Your Own Device (BYOD)
IT Infrastructure Architecture model
Jan 2012
Book general available
Oct 2011
Fire prevention in the datacenter
Sep 2011
Where to build your datacenter
Jul 2011
Availability - Fall-back, hot site, warm site
Reliabilty of infrastructure components
Jun 2011
Human factors in availability of systems
Business Continuity Management (BCM) and Disaster Recovery Plan (DRP)
May 2011
Performance - Design for use
Performance concepts - Load balancing
Performance concepts - Scaling
Apr 2011
Performance concept - Caching
Perceived performance
Mar 2011
Ethical hacking
Feb 2011
Computer crime
Introduction to Cryptography
Jan 2011
Introduction to Risk management
The history of UNIX and Linux
Dec 2010
The history of Microsoft Windows
The history of Novell NetWare
Nov 2010
The history of operating systems - MS-DOS
Oct 2010
The history of Storage
The history of Networking
Sep 2010
History of servers
Jun 2010
Tips for getting your ITAC certificate
Apr 2010
Studying TOGAF
Is your data safe in the cloud?
Mar 2010
Proof of concept
Who needs a consistent backup?
Feb 2010
Measuring Enterprise Architecture Maturity
Jan 2010
Human factors in security
Dec 2009
Master Certified IT Architect
ITAC certification
Sep 2009
Human factors in security
Google outage
Apr 2009
SAS 70
Jan 2009
TOGAF 9 - What's new?
DYA: Development without architecture
Oct 2008
Spam is big business
Sep 2008
Why IT projects fail
Power and cooling
Aug 2008
Let system administrators participate in projects
The 7 Habits of Highly Effective People
Jul 2008
Jun 2008
A meeting with John Zachman
ITAC - IT Architect certification
May 2008
Personal Information is Personal Property
The Irresistible Forces Meet the Movable Objects
Apr 2008
Hardeningscheck and hack testing for new servers
Mar 2008
Knowledge management
Information Lifecycle Management - What is ILM
Jan 2008
LEAP: The Redmond trip
LEAP: The last Dutch masterclasses
Dec 2007
What do system administrators do?
Is software ever finished?
Nov 2007
SCADA systems
LEAP - Halfway through the Dutch masterclasses
Oct 2007
Securing data: The Castle versus the Tank
Sep 2007
Non-functional requirements
LEAP - Microsoft Lead Enterprise Architect Program
Aug 2007
Reasons for making backups
Log analysis - Use your logging information
Jul 2007
Archivering data - more than backup
Jun 2007
Patterns in IT architecture
May 2007
Layers in IT security
High performance clusters and grids
Apr 2007
Zachman architecture model
High Availability clusters
Feb 2007
Monitoring by system administrators
What is VMS?
Jan 2007
IT Architecture certifications
Storage Area Networks (SAN)
Dec 2006
Documentation for system administrators
Nov 2006
Presentations: PowerPoint sheets are not enough
Oct 2006
99,999% availability
Sep 2006
Linux certification: RHCE and LPI
Aug 2006
IT Infrastructure model

Ruth Malan
Gaudi site
XR Magazine
Esther Barthel's site on virtualization


XML: RSS Feed 
XML: Atom Feed 

UX/UI has no business rules

Friday 18 July 2014

I am involved in a project that designs a browser based application. The customer has very specific ideas about the way the UI/UX aspects. As Forrester states: “Ultimately any service must meet the customer’s needs, be easy to use and enjoyable – the three facets of customer experience.”

UI (User Interface) and UX (User Experience) are related concepts. In practice the difference is fuzzy, to say the least. In theory, UI is about the buttons, drop-down lists, colors, and other elements on a user interface, while UX is about the whole user experience (like how easy can one switch between tasks, or how responsive a user interface is to user actions). UX is mostly about the joy of using a user interface.

I found that it can be hard to define the demarcation point between the UI/UX part and the rest of the application. In older applications, there was no real border between both. But splitting the UI/UX layer from the rest of the application components is very beneficial.  

The main rule is that the UI/UX layer should not have any business logic; all business logic must be implemented in the underlying application. This allows using multiple user interfaces with the same application. For instance, a modern browser, but also older browser versions, mobile apps on tablets of phones, an interface for disabled people, or whatever comes next.

The user interface should only help users to get a better experience. In theory, a text-based interface (green screen) should suffice to operate the application via its API services. The UI/UX layer is just helpful for humans, but does not improve or extend the business functions of the application.

For instance, the user interface could have a drop-down list to select a value. In theory, such a value could also be entered manually with the same functionality (but it could lead to errors when a value is mistyped). Therefore, drop-down lists are part of the UI/UX layer. When the user interface is ported to a mobile app, this app could use another interface to select a value. In all cases, the application and its API service is unchanged. This means that UI/UX is all about non-functional requirements, not about application or business functionalities.

In general, the release cycle of user interfaces like mobile apps is much faster than that of functional management, or software development. Where software development to create new functions typically takes months to get into production, and changes on the functional management layer could take weeks, changes on the UI/UX layer could be done in days. This allows for frequent updates of the user interface and a constant increase of the user experience.

But to allow a new version of a user interface to work seamlessly with the underlying application, it is essential for the app to have no business logic. Instead it should use the API services of the underlying application(s) on the server. This allows for instance for changing one user interface to benefit from the latest browser enhancements, while still providing an unaltered user interface to users of older browsers, without changing anything on the appliation or its API services.

The question is how to handle functionalities like spell checkers or auto-fill fields like Google uses. Strictly speaking, these functionalities are only helping the user to get a better experience. For instance, most applications would still work when words are mistyped in a text editor. The spell checker is only helping the user and enhancing the user experience. Therefore, a spell checker is part of the UI/UX. But to have a functional spell checker, system calls are needed (it makes little sense to load a full dictionary in the user interface of a web browser; the typed words are typically checked against a dictionary on a server using a API service). Therefore, a API service is needed, which is a service-side application component. As this type of UI/UX functionality is typically used in a number of applications, in most cases one generic service is used by the UI/UX layers of multiple applications. But architecturally, it is still a UI/UX component, as it has no business function.

Technical debt: a time related issue

Saturday 28 June 2014

According to Wikipedia, Technical Debt refers to the eventual consequences of poor software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy.

So, technical debt is creating a solution that is not complying to the architecture or detailed design. The reason for this is most of the time lack of time. In some circumstances, shortcuts are needed in order to deliver a project on time. This is not necessarily bad – there can be good economic, commercial or political reasons for this. Such a shortcut is known as technical debt. Technical debt can be compared to Development without architecture, as described in the DYA architecture method. I posted an article about this some time ago. Technical debt must be “paid back”; the chosen shortcut solution must be temporarily by definition and the definitive solution – according to the architecture – must be built eventually. This means that besides the extra effort to run the solution in the suboptimal way, money must be reserved to build the definitive solution. Preferably, building the definitive solution should be started immediately – in parallel with building the technical debt. I think technical debt can very well be extended to include infrastructure technical debt, or solution architecture technical debt for that matter. Just like technical debt can occur in software, it can be interoduced in infrastructures as well. Such technical debt can be introduced by creating an infrastructure solution that is deviating from the defined infrastructure architecture. This deviation can lead to additional cost, for instance in terms of increased systems management effort, replacing hardware before the economic life span is reached, or temporarily using additional software licenses. Nobody likes technical debt. It is a temporary solution to a problem that needs to be solved anyway. The only real reason for creating technical debt is time constraints. If enough time is available, it is always best to create the definitive solution right away. But because of time constraints, extra money is spent creating a temporarily solution quickly, and redo it later. It must be understood by the stakeholders that by creating technical debt, they are actually paying extra for their impatience.

Solution shaping workshops: this is where the magic happens

Saturday 07 June 2014


When architecting a new IT system, at some point fundamental decisions need to be made. For instance about the structure of the system and its components, about the usage of some commercial product, or about the integration of components. These decisions are architectural, as they are fundamental – they cannot be changed easily afterwards.

In a typical project, architects, designers and other stakeholders all have their own view on the system that is to be built. They create their own views and sketches, have their own mental map, talk to each other (but not to everyone, let alone the lead architect) and make up their mind on how things should be solved. However, not everyone has the same knowledge level on all relevant topics and few – if any – are able to oversee the consequences of their proposed solutions.

Various architectural methods define some point “where the magic happens”. Some methods are quite vague about it (come up with the best fitting solution), and other try to highly organize it, such that is becomes unpractical (create extensive lists with alternatives, use a repository of architecture building blocks, etc.).

But in practice, the magic happens in a discussion by a small group of architects. Brainstorms are held, solutions are found, and the most fundamental views are created. I call it the Solution Shaping Workshop.

Now, don’t confuse a Solution Shaping Workshop with a traditional workshop, as in for instance the MetaPlan Method or a Brown Paper session. A Solution Shaping Workshop can be planned, but can also happen spontaneous – for instance as a result of an informal discussion between architects at the coffee machine.

A Solution Shaping Workshop has the following characteristics:

  • No workshop mediator, no system
  • Small group of people (2 to 4 members)
  • Availability of whiteboards or flip-overs to make drawings
  • Relaxed environment
  • Focus on one problem
  • Everyone is free to brainstorm, ideas are welcome
  • One hour max

In a Solution Shaping Workshop one architectural concern is addressed (for instance: “How does our system interface with the current system?”). In the workshop one member of the team explains the problem and provides his first line of thinking. Then a free-format brainstorm is done, where all members are expected to provide input. In practice, quick sketches are made on whiteboards or flip-over pages that help the creative process. When everyone agrees about the outcome of the creative process – the drawn picture – the workshop ends. When no solution can be agreed upon in one hour, the Solution Shaping Workshop should end; apparently the team is not ready to make a decision on the subject yet. In such a case, actions should be agreed for a follow-up (for instance, it could be agreed to get more information from other stakeholders, or to put the issue on the architectural concerns list).

Be sure to make pictures of the whiteboards (using your phone) before the meeting ends, or to take the flip-over sheets with you. One person (typically the one that started the Solution Shaping Workshop) transforms the drawings to a proposal for an architectural decision. Such an architectural decision typically states:

  • The definition of the architectural concern that is addressed (what problem are we solving)
  • The proposed solution as agreed upon in the Solution Shaping Workshop (including drawings and clarifying text)
  • The pros and cons of the proposed solution
  • The alternatives that were discussed and the reason they are not chosen
  • The impact and implications of the decision

This architectural decision (typically a few pages in length) is then sent to the members of the Solution Shaping Workshop to be peer-reviewed. After this review, the decision typically needs to be approved by some project board or design authority.

When the solution is approved, it is very important to share the solution with all relevant stakeholders, to avoid new discussions about possible solutions at a later stage. Preferably, this is done by presenting the solution to the group. In such setup, it is most helpful to not shown the created drawings on a projector, but to sketch then again on a whiteboard. This way people can understand how the solution is built up, step by step. While sketching the solution, the group builds up a mental map of the solution. Questions can be answered as soon as they arise, during the buildup of the sketch.

Was the picture shown to them in full, they could get confused, overwhelmed by detail, or question some detail instead of grasping the total solution first.

Be prepared to answer questions from the stakeholders, as they might have their own view on the subject (and sometimes even a worked-out solution in some form). Try to avoid discussions about new alternatives. By getting approval before presenting the discussion to a larger group, the decision is not under discussion, but a fact.

Architecture life cycle

Sunday 25 May 2014

Working under architecture means that solutions are designed, implemented and deployed according to an underlying architecture.

During the design of a system, architects make architectural decisions. Architectural decisions are those design decisions that are the hardest to change later on and have large impact on the project as a whole. Which decisions are exactly architecturally relevant is not easy to define and is highly dependent on the type of system designed. Design decisions that do not influence the architecture of the system are not considered architecturally relevant and can be made by the designers and developers of the system.

During projects the architect must govern that the architectural decisions are respected and not violated by the designers, developers, implementers, testers, or other stakeholders.

After the project is delivered the architecture must be guarded during the full life cycle of the delivered system to ensure the architecture is not compromised when changes are performed to the system. For instance a perfectly architected high available solution could undergo a change in some network equipment after a few years of operation that eliminates the high availability of the system by introducing a Single Point Of Failure (SPOF). The system managers performing the change might not be aware of the introduction of the SPOF, but the architect guarding all changes to the system should be aware of architecture threatening changes. It is therefore of great value to have the architecture governed during the full life cycle of a system; from creation of the first design elements to the day the system is decommissioned.

Project managers and architects

Monday 12 May 2014

Project managers and solution architects are really two types of persons, each with their own responsibilities.

  • Project managers ensure the project is finished on time and within budget. Their main concern is the scope and planning of the project.
  • Architects ensure a technical solution that fits the enterprise architecture, now and in the future. Their main concern is avoiding quick and dirty solutions that will become costly in the long run.

Because of these different concerns it is good practice in projects to have not only a project manager, but also a solution architect. The project manager and the architect should work together as a team. The project manager being responsible for the process of the project (like the planning, budget, etc.) and the architect responsible for the solution the project creates.

Because the project manager and the architect have different concerns that could be conflicting sometimes, the project must have a good balance between quality (architect’s concern), time (project manager’s concern) and budget (also project manager’s concern). This sometimes leads to conflicts. Architects tend to create solutions that are "elegant" and reusable and therefore not always within the project scope. The design is made for instance more modular or more easily expandable than strictly necessary within the project.

Although in general this helps the organization in the long run, the project managers have different concerns. Project managers tend to keep the scope of their projects as limited as possible to prevent project risks in terms of time and budget. They want the project to do nothing more than strictly necessary. This conflict of interest can be solved best when the project manager and the solution architect have a good working relationship and they are aware of each other's concerns.

Good social skills are crucial for a good project manager and for a good architect. I have good experiences with projects organized with the project manager and the architect working as a team. It relieves the project manager from dealing with technical issues. Since the technical specialists communicate to the architect and not to the project manager, technical issues are handled by a technically skilled person. Technicians, including the solution architect, are not bothered with process issues like milestones, budgets and reporting to senior management.

In small projects sometimes the project management and architecture tasks are not separated. On the other hand in large projects usually more than one architect is working on the solution. Large project also often have project management at multiple levels.

But just like there is one project manager that has the overview of the whole project - maybe managing multiple teams with dedicated team leaders or project leaders - there is always one and only one (lead) architect. He has the overview of the whole solution. The lead architect can manage multiple teams working on parts of the solution by appointing multiple solution architects. But the lead architect is always end responsible for the complete solution. He will have to sign off all deliverables and makes sure all parts of the solution will work together and form one integral solution that adheres to the enterprise architecture and the requirements.

More articles: See left pane.
About Sjaak Laan

Sjaak Laan

Sjaak Laan (1964) works as Principal IT Architect for CGI and has more than twenty-five years of IT experience.


Twitter LinkedIn Facebook RSS

My book

Order book

Course material for universities


This site states my opinion only, and not nessecarily the opinion of my employer or of the clients I work for.

The postings on this site are my opinions and do not necessarily represent CGI’s strategies, views or opinions.


Copyright Sjaak Laan