AUTHORED BY FRANK LIBERIO

As we all go through digital transformations,

it seems like architecture has risen to the top of the pile in priority.  I don’t remember architecture being this important 5 years ago.  Now it seems like you live or die based on your architecture. If you get your architecture wrong you either fail, blow the budget or develop an unreliable product.  I believe there are three areas you should consider as the CIO when finalizing the architecture for your digital channel or honestly any new customer facing initiative.

First, I would suggest you get the best architecture team you can afford.  Having a team that understands your business and your legacy portfolio is important as they develop the new architecture.  The architecture has to be based on the new functionality or capabilities you are developing.  The architects need to understand your business so that they have deep understanding of how these capabilities will perform.  Also, as you build the new capabilities, likely customer facing or front-end functions, you will have to integrate to your legacy portfolio.   Therefore, the architectures need to also have an understanding of what your back-end contains and how best to build the necessary API’s.  I have been lucky to work with great architects and it has made a substantial difference.

Now with all that said, my second recommendation is to “trust but verify”.  Now as CIO, you are likely not an architecture expert.  I think all CIO’s have some level of IT instincts that help us to make critical technology decisions, but this is too far of a stretch.  The best approach is to bring in a third party to assess the architecture assessment from your team. Now I know I just said that it is good to have deep knowledge of the business and legacy portfolio as you design the architecture, but there is another aspect that the third party can bring.  The breath of tools available to use is quite large and they constantly are changing.  Bringing in a third party gives you some level of confidence that the best tools are being recommended.  The third party may have access to information regarding enhancements or completely new tools that are becoming available.  Also, it does give you some reassurance that you have good architects.  Honestly, my architecture team actually appreciated that we were willing to invest to give them support from third party experts

Lastly, you have to remain flexible in changing the architecture along the way.  I know this sounds counterintuitive, but there are times when a piece of the tech stack is just not working and needs to be changed.  The team will make you aware of this and it will not be good news. We all know that these types of changes always result in delays.  I had a specific example where the middleware product we originally selected could not scale to our volumes, it was failing in scale testing.  The only choice was to move to a new product.  It caused disruption, but in the end, it was worth the pain.  Also, you have to be open to new tools hitting the market that are faster, cheaper or better. In these cases, you can wait to change after the product is delivered so that you do not impact your delivery date, but you still have to be open to the investment to make the architecture change.