Solution architects are supposed make sure the solution components hang together, it is secure, efficient, user friendly, cost effective and more importantly satisfies the business requirements. This requires the solution architect to change their tone and language when talking to different people – you’ll instantly lose your audience if in a meeting with the business SME’s start to talk about why the solution needs a high performing SAN or a Service Bus; Similarly the infrastructure and hardware folks get bored when you start explaining to them the best option to calculate financial accruals!
But this is half the picture. The other half is making sure the solution fits well in the organisation’s roadmap and long term landscape and strategy – often defined by Enterprise Architects. And it’s probably one of the most challenging task of a solution architect. Satisfying the needs and goals of the functional and non-functional requirements of the solution itself might be complicated enough. But you’re still playing in the same court. You don’t usually need to context switch – from the solutions immediate requirements to the long term organisation goals.
But in order to make the solution a success in the long run you need to “Zoom-out” and look at the solution components and the decision you’re making from the 30,000 feet. Having this helicopter view helps to adjust the direction of your solution; the more often you climb up and see the big picture, the less the risk of deviating from the enterprise roadmap and the impact to your solution budget and timeline due to rework.
If your organisation is big enough to have a dedicated team of enterprise architects, organise regular meetings with them and discuss the decisions you’ve made, asking them to validate it with the long term strategy and roadmap. Otherwise think if the direction you’re heading is aligned with the organisations future state, even if it’s not properly documented.
Examples:
- Your solution captures “Customer” data in its database. Your organisation already have a CRM which also stores Customer data. Should you not capture customer data in your solution and integrate it with the CRM to bring the data in? Should you source the customer key data (IDs and Names for example) from CRM and capture the solution specific attributes in your solution? Should you build a Master Data Management (MDM) repository and store the customer data in MDM for other systems (including the CRM) to source the customer data from MDM?
- The tool you’ve chosen to implement the solution has various modules, one of which being “estimation and forecasting” module. By looking at the enterprise IT landscape you realise there’s a dedicated Budgeting and Forecasting solution in the pipeline to be implemented next year. Should you enable the estimation and forecasting module in your solution (which may have cost and effort implications)? Or wait for the long term Budgeting and Forecasting solution and in the interim find a manual solution to address your immediate business requirements?
- Your project have limited budget for integration and there’s no service bus in your IT Eco-system. Think whether it’s a good idea to install an open source service bus; or install an SFTP server and implement your interfaces via batch files; Or use out-of-the-box adapters provided by the vendor? Which one is more aligned with the enterprise long term goals and investment plans?