A fictional interview gives insight into
the work of the Architecture Board
Nina Nurse and Barry Bouncer, you both work with what is called ‘enforcement of architecture compliance’ which is one of many responsibilities of the Architecture Board. Could you tell me in one sentence, what do you do?
Nina Nurse (N.N.): I help IT projects by “nursing” them into the state where they implement the needed solution in a holistically best possible way, taking both the business and IT into account.
Barry Bouncer (B.B.): I verify that IT projects adhere to the given non-functional requirements of different sorts. If they don’t, I “bounce” the project back to the drawing board.
You Barry are a “You shall not pass” kind of person, while you Nina are more “I’ll guide you through it” person. You have the same objective in mind, but quite different approaches! Tell me about your motivation. Why do you use this approach?
B.B.: IT is complex, but the well-being of IT is critical for the business. If we stop or fail, the company can go bankrupt. It is complex enough as it is. If we allow a half-baked project in, we expose the whole organization to an additional risk, not currently present in our IT. It might have different shapes and sizes. It might decrease our stability, introduce higher cost of operations, lowering our security resilience, or simply increase time-to-market (complexity) for the next development projects. Therefore, it is of outmost priority to protect the existing environment and the business from low quality projects to go into production. I’m a protector of IT, the bouncer.
N.N.: IT is complex and therefore, it is difficult for the business to understand the dependencies, threats and even principles the Architecture Board put forward to be followed. To make sure that a project is successful, both as an isolated project and as a part of the IT environment, I help to navigate and negotiate the many requirements and principles into the final solution. When it is not possible to satisfy the IT-requirements, I help to rework business expectations. It’s not always the case that the business gets what it wants, but it gets what it needs. I’m a kind of nurse – making sure that the projects stays healthy and doesn’t harm the environment.
How do you work with projects?
N.N.: Once the project reports in, I check where it is placed on the IT-Business landscape map and find its impact or footprint in the landscape. From that work, I investigate what will be relevant to consider (in addition to the functionality): systems, stakeholders and other ongoing projects. I do the same with the data footprint. This helps me to present the overall picture of things we will need to address to the project ambassador. They are quite often overwhelmed 😊 … and then the continuous negotiations/navigations begin.
B.B.: I proceed in the same way as N.N., but I use the findings more for instantiating/adjusting the generic principles into the project at hand. And there is not much of negotiations ongoing – every non-compliance is measured in additional cost needed to mitigate the non-compliance effect (development and/or operations), and the project is asked to update its business case and budget accordingly. I do not interfere with business expectations; I just meet with the project before it advances into next phase and verify the situation and compliance with the relevant requirements.
What are the typical or biggest challenges you experience in working with projects?
B.B.: One: delaying putting the project under evaluation – this might result in discovering that the work done so far in the project was a waste of time – because the project learnt too late about specific requirements. Second: attempting to overrun our judgment/requirements: instead of trying to resolve the pointed-out challenges, the project waits until some business deadlines get closer and uses this emergency as a leverage in escalating the case to the executive level and hoping to get approval anyway.
N.N.: I’m not suffering very much from projects working under our radar for too long – they learnt it is worth getting in touch as early as possible. My biggest challenge is that projects tend to keep me in the loop for too long – I become their de facto solution architect (and the project saves on having a separate architect). It might seem to be acceptable for small/quick projects, but in general it is not the most effective way to use my competence. Once the general development direction is clarified the project’s architect should take the lead.
Related to competence available in/to the project, I have one question from my colleague John: Do you evaluate competence available to the projects, and do you regard it as an important factor to its final success?
B.B.: We probably should, but we don’t have non-functional requirements addressing it, nor an objective way to evaluate the competence requirements. I can’t even imagine what would happen if I had administered a skill test to the project team 😉
N.N.: I agree that this is a critical success factor for any kind of projects, but I don’t evaluate it explicitly. I might be doing it unconsciously, when interacting with the project. If something feels very off, I will raise concern with the project ambassador(s).
And finally, is there any other (personal) reason why you are treating projects in this particular way?
N.N. (hesitating): I guess, I like to be a nurse 😊
B.B. (firmly): … and I like to be a bouncer 😊
