They seem to be all but prepared to pack their bags and move on to other “more interesting” assignments. I can’t help but feel sorry for those projects because to me, those projects are sure to fail.
As an architect, you own the solution end-to-end. It is your solution, and nobody knows your solution better than you.
We have also been in the industry long enough to realize that it is one thing to create a solution that looks pretty comprehensive and all inclusive on paper, and it’s an entirely different thing realizing that same solution into a system that is live. There are a variety of things that could go wrong or things that may change from what was assumed during the solutioning and hence having the architect to continue on the project even during the delivery phase becomes absolutely imperative.
Of course it takes slightly different skills that the architect needs to apply in the delivery phase, and that’s where the role of a Delivery Architect comes in. And in this blog, I would look to focus on precisely those skills pertaining to the Delivery Architect role.
As a whole, the Delivery Architect role can be thought of as 2 parts –
- Accountable for defining the end-to-end solution : This is something that we are all very familiar and in agreement with. There is hardly any debate on the architects role in defining what the end-to-end solution will look like and there are a number of different artifacts that we are very good at producing that explains this well.
- Technical Management through the solution engineering : This is the key part of a Delivery architect role that really makes them stand out from what I call the “30K feet-away-from-reality” architects. There are a number of things like Stakeholder management, managing of technical risks, managing the overall challenge of ensuring the solution being realized is aligned with the way it was intended to be, etc. where the delivery architect’s role becomes so much more critical. Although at the very outset, these may appear to be more responsibilities linked with the Delivery Manager’s role, but just being the owner of the entire solution, the architect would be the one having most crucial bits of information and knowledge without which, the delivery manager would never be able to perform his responsibilities efficiently.
At the end of the day, it is really the level of collaboration between the delivery manager and the architect that would determine whether or not a project is successful, not the quality of the solution designed by the architect.
The Architect needs to be the “right-hand” man (or woman) to the delivery manager – be the eyes and ears of the delivery manager, and help him take the right decisions at every stage by providing by inputs relevant and pertaining to the context of the solution.
Delivery Architect : Accountabilities
Focus on non-functional requirements is another key aspect of the delivery architect’s role. Not only are Architects responsible for defining the NFRs for the system and implementing a solution that adheres to the same, but also support the testing and validation of these NFRs.
At Capgemini, we have designed a delivery architecture bootcamp that is specifically aimed at ensuring all our architects understand and practice the delivery architect role hence delivering true value to our customers. Connect with me to know more about this bootcamp.
Summary: Delivery Architecture ensures the realisation of the solution architecture, making sure it is operable & cost-effective
Architects need to realize that the Architecture created by them is the blueprint, but the Solution is not delivered until it’s engineered and live! We are in the business of making the solution real & not just an idea. Gone are the days where arcitects role was limited to drawing few pretty boxes and joining them with arrows. It is essential for them to be hands-on and grounded close to reality, otherwise thy would soon start to loose their edge.