IREB certification

September 11th, 2011 No comments


Agile projects my experience

June 17th, 2011 No comments

imageIn my previous project we had a very tight deadline which forced us into an (kind off)agile way of working. The project was in a tight deadline because the business didn’t know what they want at a high level, so the first step in our project we took was defining the high level scope. We did this by looking at the business functions and determine the processes needed to support the functions. Based on these processes we know what to support, not the how.

After this session we signed off the scope based on these processes. and we started. The first step was a workshop with stakeholders from the business, developers and testers. In that session we took 1 step of the process and talked it trough. So the developers knew what they need to build, the testers could make some test scripts and the analyst could write the use-case.

imageAfter 2 or 3 days we came back in a session to check if everything was going the right way, we did this by letting the developer tell what is was building and when possible showing something. A few days later we did a similar session but then the tester told the story of the functionality. In every session we could ask questions and discuss the solution in more detail. At the end of the week the part was build en delivered and presented to the testers and the next step in the process was taken into development according to the same way of working. After a whole process was finished we delivered to the acceptance testers.



  • Fast design, development and test live cycles – by using this process the developers and testers didn’t need to wait till the use-case was finished they could start right away
  • Clear scope – the business knew what they we getting very early in the process
  • Adapt to changing requirements – since the business knew what they were getting they could adjust their whishes early on in the process
  • Fun – lot of interaction in the team so the team spirit was getting better along the way
  • We delivered within time


  • traceability – there where no real hard requirements so the traceability of them was not possible
  • workflow support – we used TFS and in our implementation we had difficulty with the artifacts, since every one is working on the same artifact at the same time. We solved this by using tasks which will be linked to the artifact when the task was finished
  • Deployment – An deployment took us a day and we had only one test environment, so with every deploy the testers could not test for a day

This sounds ideal but the whole team needs some knowledge of the problem domain so everyone could understand what to solve. Also the high level architecture needs to be set and stakeholders need to be available (this could be a serious issue in big companies).

The process described is not completely agile or scrum but we took the basic principles and make it work that way.

Agile principles


In the movie below is a nice example on what a project leader comes across when he wants do do agile projects.

Categories: Agile Tags: ,

Microsoft Solutions Framework (MSF) recognized by TOGAF as valid Architecture Framework

June 13th, 2011 2 comments


imageFor all of you out there that use or embrace the Microsoft Solutions Framework (MSF)  there is some good news for you. Today The Open Group officially confirmed that the MSF meets all criteria to be recognized as a valid IT Architecture method and is now listed and available to all architects that want to pursue ITAC certification.

This is a very interesting move for the Open Group as MSF originated as a variant of an SDLC process at the development (i.e., Solutions) level. The same is true for RUP. One could say, however, that you can use these methods for EA by abstracting them up for that purpose. Even though I have no issues with MSF as a SDLC process I do believe that it is primarily for software development and not for enterprise architecture.

You can find more information about OpenGroup-recognized IT Architecture Methods here.

List of Recognized Methods

Allstate Architecture Standards and Methods (AASM)

BearingPoint Configure To Fit Method

BearingPoint Methodology

Bredemeyer VAP

CA Solution Architecture Methodology

CSC Catalyst

Capgemini Integrated Architecture Framework (IAF)

Credit Suisse IT Solution Framework


Enterprise Solution Delivery (ESD)

GM System Delivery Process (SDP)

HP Global Method for IT Strategy and Architecture (HPGM for ITSA)

IBM Global Services Method

IBM Team Solution Design

IMPACT (TCS Architecture Development Methodology)

Intel AEPF

Intel IT Architecture Development Methodology (Intel IADM)

MSF Microsoft Solutions Framework

New Zealand Inland Revenue – IR Method

Rational Unified Process (RUP)

Raytheon Enterprise Architecture Process (REAP)

SUN Architect Implement and Manage (AIM)




Telstra Technology Delivery Process (TDP)

TelstraClear Infrastructure Lifecycle Process (ILP)

UPS Solution Architecture Process

Technorati Tags: Open Group,MSF,Microsoft,Enterprise Architecture,ITAC

Microsoft Solutions Framework (MSF) recognized by TOGAF as valid Architecture Framework
Mike Walker
Thu, 02 Jun 2011 16:56:28 GMT

Categories: TOGAF Tags: ,

KANO model in relation to requirements management

June 1st, 2011 No comments

Our goal when we build software is to help people do their work faster better etc. (think of any quality attribute), so we put tremendous effort in understanding what the user what wants. Next to that we manage those requirements very strict, and build, test and deploy the solution that realizes those requirements. The last step is the implementation in the organization, in this step the users see the system and are using it. mainly we see 2 types of reactions:

  • The users think it’s ok, that’s great we did out jobs well.
  • The users expected some things different, there we go into the change management cycle. 

A third reaction so see very seldom is wow that systems is great. This come trough the fact the the users heard stories (or read specifications) on what the system would do.

In this post I focus on the 2nd type of reaction (users expected some things imagedifferent). For this users the system works probably as designed, but they hoped for some nice features that make their work easier. Those features where probably set out of scope since the project had a small budget and only the basic features where realized. This will result in the users getting the basic thing they want and expect, so their ok with it. But we want to please the users and deliver a great system.

To plot this on a other product: biscuits. When you buy biscuits you’re requirements are a package containing biscuits which are fresh. When you buy this at a reasonable price you are ok, not extremely happy since a comparable product has the same characters. But when the biscuits are made in an handy form so you don’t have to hassle to get them out you are happy.

These findings can be plotted on the KANO model, below you can find a description of the model.

The Kano model is a theory of product development and customer satisfaction developed in the 80s by Professor Noriaki Kano which classifies customer preferences into five categories:

  • Attractive
  • One-Dimensional
  • Must-Be
  • Indifferent
  • Reverse

These categories have been translated into English using various different names (delighters/exciters, satisfiers, dissatisfiers, etc.), but all refer to the original articles written by Kano.

Attractive Quality These attributes provide satisfaction when achieved fully, but do not cause dissatisfaction when not fulfilled. These are attributes that are not normally expected, For example, a thermometer on a package of milk showing the temperature of the milk. Since these types of attributes of quality unexpectedly delight customers, they are often unspoken.

One-dimensional Quality These attributes result in satisfaction when fulfilled and dissatisfaction when not fulfilled. These are attributes that are spoken of and ones which companies compete for. An example of this would be a milk package that is said to have ten percent more milk for the same price will result in customer satisfaction, but if it only contains six percent then the customer will feel misled and it will lead to dissatisfaction.

Must-be Quality These attributes are taken for granted when fulfilled but result in dissatisfaction when not fulfilled. An example of this would be package of milk that leaks. Customers are dissatisfied when the package leaks, but when it does not leak the result is not increased customer satisfaction. Since customers expect these attributes and view them as basic, then it is unlikely that they are going to tell the company about them when asked about quality attributes.

Indifferent Quality These attributes refer to aspects that are neither good nor bad, and they do not result in either customer satisfaction or customer dissatisfaction.

Reverse Quality These attributes refer to a high degree of achievement resulting in dissatisfaction and to the fact that not all customers are alike. For example, some customers prefer high-tech products, while others prefer the basic model of a product and will be dissatisfied if a product has too many extra features.[1]



When you plot this model to requirements management, you can understand it is essential to get the basic requirements clear other wise your product won’t get accepted. But don’t forget the requirements that have an Attractive Quality. When you realize some of these requirements that make the life of an user easier, you are the man and their very happy with the product an will come back to you the next time.

This can also be plotted on the MOSCOW principle:




Result when in the system

Result when not in the system

Nice to have

Attractive Quality

Verraste emoticon

Verlegen emoticon

Must have

Must-be Quality



Should have

One-dimensional Quality



Could have

Indifferent Quality

Emoticon met brede lach


Won’t have

Reverse Quality

Boze emoticon



Probably the Attractive Quality requirements are already defined in the “should” or “could have” section, but they are not distanced from the other requirements the “have One-dimensional” or “Indifferent” Quality.


So what I suggest (next to the normal requirements management procedures) is to keep the KANO model in mind when you manage requirements and distinct the requirements the make the user happy (Attractive Quality)

TOGAF in combination with other frameworks

May 20th, 2011 No comments

TOGAF is a framework for enterprise architecture, but it should always be used with other frameworks or ways of work from involved disciplines. This is also mentioned in TOGAF the Preliminary Phase where you adapt the ADM (more info at: 2.10 Using TOGAF with Other Frameworks)




More info at:

TOGAF combined with COBIT



More info at:


TOGAF combined with RUP


more info at:


TOGAF combined with ITIL v3


more info at:


TOGAF combined with Business Analyses according to BABOK v2


More info in the Business Analyses Body of Knowledge (chapter 4) – only available for members of IIBA or in the blog post of Serge Thorn.

Categories: TOGAF Tags: , , , , , , ,