Latest News

One might say it is easy to gather customer requirements at the beginning of the project. What is worse, customer experts say: functionality is “easy”. They think they can imagine how it will work in the future within the new solution. Sometimes they are right, but it is not always the case.

There are a lot of theories and trainings coaching architects how to follow domain specific rules, listen to customers and map requirements using sophisticated tools or notations to final system or solution. Goal is well known, it is “customer satisfaction”. What I want to share today is my opinion about this process.

In my experience, key rules, that need to be followed for proper requirements gathering and design, are actually quite simple… to enumerate though they require practice to execute. The key rules, I have identified as the most important, are:

Key rules

• Question “why” and answer to it
• KISS principle
• Overall understanding and courage

Let me explain them one by one.

Basic question: WHY?

Why is question “why” so important to me? A few years back, I realized that people quite often say at the end of the project: “if I had known how the solution would be used, I would have done the project different way”. Sounds strange, right? Simply, an architect without understanding why some functionality is needed is willing to make not accurate assumptions and decisions. Customer experts, who sometimes limit information shared with an architect, are also a challenge.  At this point an architect should have the courage to ask “why?” as many times as necessary to understand real concerns and customer’s needs. As you can see, I’ve already mentioned the last rule about courage. This is because the rules listed are not disconnected and in fact should be applied together.

KISS

KISS principle (old, good “Keep It Simple, Stupid”) is my favourite one. Lessons learned from my experience – even large solutions can be built with a simple architecture, where all elements have minimal and the most simplified algorithms and concepts. On the other hand, even simple feature can be done in a complex way, although at the end of the day it will not pay off. Among other consequences: it will be difficult to refactor a code and to fix issues, and so it will be expensive to support and maintain the solution.

I encourage everyone, not just architects, to be pragmatic and follow KISS always. Final product may be complex, here I agree, judging by the number of functionalities it brings, but it is not difficult to understand if the main concepts are made simple.

KISS also imposes Separation of Concerns (SoC) – someone at the beginning of my career stated that it is important to listen to the customer needs but mapping them to a solution design is only architect’s task. I think he was right. It is essential to stop some customers from designing a system for you – yes, it happens. An architect should focus on functionality needed and customers’ answers to “why” questions, simply to be able to put required logic in a proper place of a solution under design. Final design is a reflection of the architect’s vision only – it is in fact a one-man show. Architect is responsible for the overall shape without excuses like “the customer has changed that part and now it doesn’t make sense”.

Understanding and courage

The last rule, understanding and courage, was already mentioned above as a support of the other design rules. It is important to understand customer needs. If an architect does not understand real needs, no one from the implementation team will understand this part of the design and system concept. Implementation will not fulfil customer requirements but will be done as per design. Functionality should be understood before mapping it to certain hardware and software elements.

What is more, courage is also needed to gather all information from a customer even if design phase is longer than expected. How many times have you been forced to close the design due to time exceeding the project plan while functionalities were still not in the right places of the solution? Bad assumptions and decisions will be made most probably due to rush. I see similarity here to software development, where courage is needed to name functions and variables in a proper, clear way – always, no exceptions, simply to have clean code. Wouldn’t it be good to have a clean design too?

Finally, my key rules are not the only valid ones but these are the most important to me and they really work. If you have your own rules, do not hesitate to share them in a comment. I will be happy to incorporate your proven rules into my work.

What matters to me the most is a feeling, after project delivery, that I could not have done the design better based on all the information I gathered. I wish you all and myself to have this feeling with every project.

Enjoy your design!