vrijdag 4 april 2014

Capgemini's TechnoVision: an update on technology trends with transformation potential

A yearly "need to know" explanation on technology trends with transformation potential in Capgemini's TechnoVision. It looks at technology first and business second...

Links

TechnoVisions of pas years:
Download the TechnoVision 2014 paper
Technovision 2014 presentation on SlideShare
TechnoVision 2017
TechnoVision 2018: The Impact of AI

TechnoVision Clusters: Capgemini has identified 17 key information technology trends that it believes will be most relevant to our clients and have grouped these trends into seven TechnoVision clusters.

maandag 3 maart 2014

Reviewing an ICT solution/platform: what documentation and other things you need?

On a regular basis, I'm asked to do a quick review on an ICT solution or platform. This with the intention to take over the management and maintenance of the system. For a quick but effective review, you'll need documentation and contacts. To avoid being flooded with a lot of irrelevant documentation I have devised a set of documents that help me to form a decent picture of the quality of the solution or platform.

The document set is based on the information that you need to make changes and extensions to the software, to solve incidents, to explain the operation of the system and to advice on modifications, extensions and migration.

Principles and requirements

To be able to determine what purpose the software has been created for and what standards/high level requirements are to be met.

Documents:

  • (Project) Start Architecture: e.g. basic principles, design and implementation standards
  • Roles / persona's and user stories
  • Requirements; both functional and non functional

Solution / software architecture

Preferrably a high level solution architecture diagram that refers to more detailled documentation like technical designs.

Information on:

  • Standards/standards/frameworks to be used
  • Solution scope, interfaces with adjacent ICT components and other dependencies
  • Scalabilty: what boundaries are known to the system and how can the solution be scaled?
  • Security: in what way the system is secured?
  • Flexibility: in what ways the solution can be configurated, extended?

Design documents

  • Standards used
  • Functional design: functions, interaction/flow, entities
  • User interface model: screens, flow, controls, navigation
  • Technical design: database design, classes/objects models, interface designs
  • Implementation/deployment model

Implementation

  • Standards, e.g. frameworks, patterns used
  • Detailled program structure
  • Version history, branches etc.
  • Version planning for future versions, work items, etc.

Deployment/installation and configuration

  • Installation and configuration documentation
  • Release documents of the past x versions / period
  • Environments used (specified) for Development, Test, Acceptance and Production (DTAP)

Quality management

  • Test method used
  • Test plans for smoke tests, system tests, integration tests, regression tests, user acceptance tests
  • Test reports of the past x versions / period

Deployment

  • Infrastructure requirements
  • Software maintenance manual
  • Implementation guide

Techical support and maintenance

  • Health checklist
  • Known issues, solutions and workarounds
  • Backup and disaster recovery procedures and manuals
  • Incident log of the last x months

Usage

  • User documentation
  • Super user documentation (for local support)

Supporting tools

Description of required tooling for:
  • Architecture
  • Design tools
  • Development, e.g. code editors, workbenches, source control
  • Deployment

People

Who can I contact to gain more information and insight on the particular solution/platform?
  • Business owner(s)
  • Architect(s) (solution) responsible
  • Designer(s) / engineer(s) responsible
  • IT professional(s) (installation, configuration, maintenance and support) responsible
  • End user, each role

Of course, this is not an extensive list. Any suggestions are welcome!



donderdag 10 oktober 2013

Can I use this technology in that version of this browser?

In many web projects, the question "Can I use this in the targeted browsers?" is posed too late, resulting in ill fit customer expectations and a lot of tricks to make things work. Solution to his is simple; think before you promise. To help you with that there are many list available on the internet which give you a list of supported technologies for browsers. The site below is (IMHO) particularly handy:

http://caniuse.com: gives you al lot of technologies and techniques with the supporting browser(versions).

donderdag 27 juni 2013

Weg met de vuistdikke handboeken voor interface design... er zijn maar een paar simpele regeltjes...

Weg met de vuistdikke handboeken voor interface design... er zijn maar een paar simpele regeltjes... Net zo doeltreffend, maar veel beter te onthouden.

"...

The principles of user interface design are intended to improve the quality of user interface design. According to Larry Constantine and Lucy Lockwood in their usage-centered design, these principles are:

  1. The structure principle: Design should organize the user interface purposefully, in meaningful and useful ways based on clear, consistent models that are apparent and recognizable to users, putting related things together and separating unrelated things, differentiating dissimilar things and making similar things resemble one another. The structure principle is concerned with overall user interface architecture.
  2. The simplicity principle: The design should make simple, common tasks easy, communicating clearly and simply in the user's own language, and providing good shortcuts that are meaningfully related to longer procedures.
  3. The visibility principle: The design should make all needed options and materials for a given task visible without distracting the user with extraneous or redundant information. Good designs don't overwhelm users with alternatives or confuse with unneeded information.
  4. The feedback principle: The design should keep users informed of actions or interpretations, changes of state or condition, and errors or exceptions that are relevant and of interest to the user through clear, concise, and unambiguous language familiar to users.
  5. The tolerance principle: The design should be flexible and tolerant, reducing the cost of mistakes and misuse by allowing undoing and redoing, while also preventing errors wherever possible by tolerating varied inputs and sequences and by interpreting all reasonable actions.
  6. The reuse principle: The design should reuse internal and external components and behaviors, maintaining consistency with purpose rather than merely arbitrary consistency, thus reducing the need for users to rethink and remember.

..."

Bron: http://en.wikipedia.org/wiki/Principles_of_user_interface_design

En achteraf gezien is het eigenlijk zo logisch als het maar kan zijn. Waarom houden we het voortaan dan niet zo simpel eigenlijk?

donderdag 9 mei 2013

Leesvoer en andere bronnen

Modellen

(Microsoft) Developing Models for Software Design (UML)

Technologie

(Microsoft) MSDN Channel9 video's over diverse technologieen

Praktijkervaringen en patronen

Microsoft patterns & practices: Application Architecture Guide 2.0 Knowledge Base

Downloadable boek ("Web Architecture Pocket Guide") en:
App Pattern - Four-Tier Web Application Scenario (Table Module)
App Pattern - Three-Tier RIA Application Scenario
App Pattern - Two-Tier Rich Client Application Scenario
App Pattern - Three-Tier Mobile Application Scenario
App Pattern - Three-Tier Web Application Scenario (Domain Entity)
App Pattern - Two-Tier Service Application Scenario (REST)

Microsoft patterns & practices: Windows, Phone, ALM, Web, Engineering Fundamentals, Cloud

Aggregatie, compositie en andere afhankelijkheden: hoe zat het ook alweer?


Aggregatie, compositie en andere afhankelijkheden: hoe zat het ook alweer?

Aggregatie en compositie zijn beide vormen van associatie.


Aggregatie: een ouder-kind relatie tussen objecten waarbij de objecten onafhankelijk van elkaar (kunnen) "leven". De ouder is geen eigenaar van het kind. Wanneer een van de objecten wordt verwijderd, hoeven de kind objecten niet noodzakelijkerwijs te worden verwijderd. In andere woorden: de lifecycles van kind objecten zijn niet afhankelijk van de lifecyle van het ouder object.

Voorbeelden:
Leraar-Studenten
Vader-Kinderen

Compositie: een ouder-kind relatie tussen objecten waarbij de kind objecten afhankelijk zijn van de ouder. De ouder is de eigenaar van het kind. Wanneer de ouder wordt verwijderd, kunnen de kinderen niet meer bestaan. In andere woorden: de lifecycles van kind objecten zijn afhankelijk van de lifecyle van het ouder object.


Voorbeelden:
Huis-Kamers: zonder huis bestaan de kamers niet meer.
Menu-Menu items: zonder menu bestaan geen menu items, menu items behoren noodzakelijk tot een menu.

Leesvoer

UML Association


donderdag 2 mei 2013

De beste tools voor een architect

Voor een architect zijn de beste tools: een white board, een setje white board markers, een goede wisser en een aantal inspirerende en kritische collega's.

HansRontheWeb, 3 mei 2013.

(Dutch) Hoe staat het met het gebruik van open standaarden in in aanbestedingen, de toepassing in overheidsbrede voorzieningen en overig gebruik?

Forum Standaardisatie onderzoekt jaarlijks het gebruik van de standaarden van de "Pas toe of leg uit"-lijst. Het onderzoek richt z...