In my view, IT Architecture is important in order to ensure that:
- The business gets solutions that works in real life and are under control
- The company can keep the IT landscape manageable and relevant
This can only happen if the IT Architect masters numerous disciplines:
- Business understanding
- Information/Data Modelling and Integration
- Non-functional requirements like scale, security etc.
Ph.D.s and lifelong studies can be spent on all the abstract sides of information management, enterprise architecture and solution design, but so far all this has led to no silver bullets and a web search will get you + 10^9 hits with just a few search terms like enterprise architecture and solution architecture. Hence, we need to go with something simpler – and as an IT Architect, I try to follow three principles:
- Understand the real problem
- Start with the 20:80
- Deliver consistent and precise topic and modelling documentation
I do not think that there is a cookbook to IT Architecture. That does not mean that we should not follow our own and other peoples learnings – we just should not expect that one size fits all.
In the following section, I will explain my main principles more thoroughly.
Main principles
Above cartoon came out in early versions already in the 1970’ties – and still today it is the number one challenge in solving business problems with IT – lack of precision in understanding and articulating the problem we want to solve. Hence, the architect’s role is to work with the business until the problem and its boundary conditions are well understood and can be articulated in consistent text, diagrams and definitions. Typically, the architect will have to put working hypotheses on the table on definitions and diagrams to assist the business in putting down on paper what they intuitively know by heart from working with it every day.
A secondary problem that the cartoon also highlights is the information handover. We address this the same way – with clear subject matter written documentation. However, we also acknowledge that the architect will need to spend time on spreading and refining basic subject matter knowledge and help putting it into different solution contexts – most prominently to technology experts like systems configuration experts, software developers and security and infrastructure architects. Hence, we often think of the IT Architect as the man/woman in the elevator, as he/she travels up and down in the house of stakeholders and competences.
Using 20:80 in the solution design process
When we have a clear and articulated picture of what it is that we want to solve, we will also mentally be on our way into explaining how we want to solve it. This might be a bit counter intuitive statement as problem and solution sound as opposites. But if we have a good write out of the problems the solution will quite often be a straight forward application of standard principles – like for instance on how we do integration. It could also be that parts of the solution is something that we have done many times before – like for instance user access integration. Therefore, as we start writing out the solution (or try to refine the problem even further) we discover that certain parts of the solution fall of quite easily. However, this is also when we discover that we have dark spots, for instance on:
- What does the business really do in certain scenarios
- How should complex by nature business or data logic be broken down and modelled
- How should we solve particular integration or scale challenges
We could call these particular hard challenges for pain points.
Hence, we need to spend our time on:
- Insuring that we have captured the stakeholder needs and boundary condition
- Write out documentation that can assist in building the solution
- Take the difficult stuff face on – it will not be simpler further down the line.
The reason why I have brought in the 20:80 rule is that it is important that we focus our investigation and effort on what we per best guess think will be difficult and not on set check list – though we can of course use them for guidance.
Deliver consistent and precise topic and modelling documentation
In the best of all worlds many different stakeholders and solution team participants will actually use the solution design documentation. Hence, if it is high quality with respect to definitions, critical challenges and diagrams – it will be used to:
- Assure stakeholder that we are addressing the right problem with the right quality in the solution design
- Onboard new people that needs to take part in creating the solution
- Keep scope and focus on the relevant challenges and dampen confusion
- Drive test and acceptance specification
- Drive solution documentation
Final remarks
Real life proves repeatedly that IT projects are high risk – just have a look at the failed IT projects that finds their way to the press. However, as IT workers we also know that the high profiled system delivery failures that reaches media are only the tip of the iceberg. One thing is the failed projects; another thing is IT landscapes that are not delivering return on investment or is running with high unit cost. This might be due to poor design, but it is typically also generically related to long term stop and go evolution, M & A’s and to short-term cost optimization – leaving technical debt behind. This is only natural – as we cannot solve everything to perfection and fix everything according to this year’s technology and business strategy news. This side of IT challenges is much more hidden – somewhere down the finance books – but over time they will pop up as loss of flexibility, high direct cost and high dependency cost. Good solution architecture will not solve the landscape challenges, but it can highlight them and potentially leave them behind with a transparent technical depth and where next changes are made informed and with some risk assesment.
In the below links to blog posts, I go through lines of thinking that can come in handy when working as or with IT Architects.
sunevang 
Leave a comment