Technical skills and the ability to learn and use new technologies are crucial to work as an IT architect. But that’s not all.
Furthermore negotiation skills are important.
You may ask why it is useful to negotiate as an IT architect?
In a corporate you propably won‘t decide everything on your own because there are competitive interests and scarce ressources. So there are decision-makers who will do that. Everything has to be prioritized and unfortunately IT is often not seen as an enabler, so it competes against several business requirements.
Your mission as an IT architect should be to align the IT architecture prioritization with the business requirements prioritization and so convince the decision-makers. Corporates have to understand that IT architecture will enable the business and it should be seen as part of the business requirement, not isolated from that.
Now, maybe you’re thinking “Ok, and how shall I convince the decision-makers?“
Some years ago I attended two negotiation trainings, “Negotiation Practitioner“ and “Negotiation Professional“ by Jack Nasher.
In this trainings besides several negotiation tools I’ve learned the “interest based approach“.
The interest based approach says:
– Talk about interests, not about positions
– Seperate the person from the problem
– Provide several options
– Use objective criteria to rate your options
And what’s important furthermore it introduces the BATNA. BATNA is the Best Alternative To a Negotiated Agreement. This means, in case you cannot convice your negotiation-partner your BATNA has to be the solution you can provide without support. In many cases this is known as “workaround“ but your BATNA can also be a transition architecture where you first make little adjustments and later on establish the complete IT architecture.
You can adapt the key principles of the interest based approach to your own work as an IT architect because you negotiate all that time, even if you don’t realize that!
Talk about interests, not about positions
I assume you often heard phrases like “That’s not possible / We cannot do that / There is no time for architecture, we have to deliver features.“ In my worklife I’ve heard similiar phrases very often.
After getting to know the interest based approach I’ve learned how I can deal with this.
If someone says such phrases to you, this person reveals its position. Often this statement is based on the current circumstances and experiences that this person had so don’t take it personally, focus on the problem.
Once I got the statement: “You are not allowed to do this”
Then I asked: “What has to be done, so I am allowed”.
The answer was: “You must not process individual-related data.”
So the position was “You are not allowed“ but the interest was “I must protect individual-related data“. So after getting to the interest I was able to continue with my work.
Sometimes the business requirement itself is the position. To align IT architecture with the business requirement the business requirement has to address the interest not the position!
If the requirement adresses the position, you’ll propably build the wrong application.
Some of us know that very well.
What’s very important: Don’t ask why something is not possible. This will not help you make things work!
For me it was often helpful to ask “Under which circumstances will it be possible? / What has to be changed so that we can do that?“.
My experience with this phrases is that I got the answers to my questions and also the help to make it possible.
Seperate the person from the problem
Do not take rejection personally. You don’t want to argue with your negotiation-partner, you want to create a win-win situation! Sometimes you may get mad if you think you are not understood. But you also have to understand your negotiation-partner and then you can create a situation where you both win!
IT architecture vs. Business requirements
Coming back to the prioritization of IT architecture besides business requirements this means:
First you need to understand the interests. They should correspond with the requirements of your business colleagues. If a requirement seems to be the position (it can be if it makes no sense to you) try to get to the bottom of the requirement.
Ask what’s the actual idea and what’s the value behind the requirement.
Hopefully then the interest is discovered and so you both can change the requirement accordingly.
Now you are able to align your IT solution/architecture to that interests. But be careful, don’t design an IT architecture to just meet one requirement. IT architecture must be the basis, to satisfy several business requirements on top of it.
After that you have to find your BATNA and several options for your IT architecture that supports the requirements as an enabler and objective criteria to rate that options.
Usually I do this by embedding everything in a story.
For example Steve Jobs as he introduced the iPod said:
“1000 Songs in your pocket“
1000 songs in your pocket is more meaningful than a microcomputer with a phone jack and 4 GB in your pocket.
At least for me…
So you have to find the “1000 songs“ for your story.
If the interest is “the web shop shall be able to deal with as many customers as possible” you should tell several stories that represent relevant options for that linked to objective criteria.
Provide several options within stories and use objective criteria to rate this options
In the follwing example we have three options:
– Webshop can deal with more than a million customers
– Webshop can deal now with 1000 customers and later
with more than a million
– Webshop will deal only with up to 1000 customers,
not more (BATNA)
And we have one objective criteria:
– number of customers the webshop can deal with
You should always try to get an agreement on the objective criteria that is considered.
It’s important, that your objective criteria makes sense to all parties involved (stakeholders, negotiation-partners, decision-makers). If you don’t have an objective criteria you will most likely argue about whats really the object you are negotiationg about.
Stories that you could tell then are:
Web shop can deal with more than a million customers
Talk about that at least a million customers can buy at once products in the shop and do not talk about scalable microservice architectures relying on REST services with responsive frontends. Your phrases have to be tangible for the business. They must directly understand what’s the business value not how you will provide that. At least not in the first place
You should always have an alternative:
Web shop can deal now with 1000 users and later with more than a million
“We can do a little adjustment and if it’s needed we are able to deal with more than a million customers. So for now we will not be able to do this, but if it’s requested later we will.”
It is also useful to explain, what will happen if your advice is not accepted:
Web shop will deal only with up to 1000 customers, not more (BATNA)
“Ok, we can do it that way, without any change in the architecture. This means, that up to 1000 customers can buy in parallel products in the shop. If it is needed later, that more than 1000 customers can buy products, we have to build a new shop because the current decision regarding leaving the IT architecture as it is won’t allow us, to increase the size of customers that can buy products in parallel.“
Summary
In summary it is important that the requirements correspond with the interests. Then you can align the IT architecture with the requirements and use them to let the IT architecture be prioritized higher. To do this you can tell a story which includes options that are linked to objective criteria to covince the business. If the business is not convinced use your BATNA.
I hope this article can help you making your work a little bit easier.
Which experiences do you have regarding prioritization of IT architecture against business demands and how do you deal with that?