Technical considerations to evaluate during solution architecting

Years ago, I had the chance to step up into the world of IT solution architecting and management. Although the area wasn’t quite new for me, having some background from the early days of my career, I remember I have immersed myself for several months in understanding the many facets of this job. Now, some years later, I am trying to share here my accumulated experiences through won and lost deals that I have architected. Therefore, I am briefly writing in two posts on business considerations and technical considerations I am evaluating when working for a medium or large deal.


In the make-or-buy continuum, the decision is often based on the core-competencies a company has. Should you be invited to participate to a request for information or proposal, then you are already in a privileged situation. Your customer believes and wants that you strengthen his competitive position by formulating and delivering a suitable technical solution. If this is the reality, it depends mainly on your team. You must quantify a series of technical considerations needed to assess competitive advantage, resources and capabilities, impact on your development strategy, and quality of service you can provide.

Once the customer documentation has landed on your table, you would probably dig to see what is the current situation, what is requested and what is the match with your portfolio of products and services. Unless you are lucky to have a complete greenfield in front of you, the technical constraints are the first to identify and how do they compare against your resources and capabilities. It is now the best moment to decide if you want to go further with this deal, to see if you need other internal or external partners that can support your technical solution and its delivery, and to start the discussions with your suppliers. At times, this activity might be very time challenging as customers tend to provide scarce information and questions have to sent soonest possible in order to clarify the scope.

In a second stage, you might want to see if a transition is doable without impact on the operational stability. Many times, companies try to impose specific transformation to future mode of operation, forgetting that the people on the other side of the table might be quite reluctant to such changes due to different reasons. Therefore, it is now also the time to consider flexibility of service provision and the risks or opportunities that they might have on your business case. Nevertheless, the timeline of the transition and transformation phase plays a critical role as it may trigger double costs for the customer or unpaid effort costs for your company.

The delivery mix should be analysed when mapping of services against transition, transformation and operation requirements is done. With several options at hand (in- or outsourcing, on-, near- or off-shore, etc.) it plays a considerable role in the final price, and sometimes on the quality of service. Factors such as skills, language, service-level agreements, delivery strategy, and future capabilities should be considered when framing who is going to deliver the required services to the customer.

Additionally, the governance and service management may be impacted by the mix. These two areas are paramount for the overall communication flow, process management, and for the transaction costs economics. In most organisations, the people, capabilities, processes, and technologies are strategic assets. Therefore their efficiency, specificity, and uncertainty are key in the design, implementation, and operation of the service.

Many customers will be also interested in what metric-driven approach (reports, analysis of results, etc) are used to see how the contract execution is working and how the opportunities for continuous improvement can be identified. You might want to use this chance to show your customer not only you are trying and succeeding in doing your work more efficient and cost-effective, but also to depict how your company is driving or implementing innovation, a key element to stay competitive for both, your customer and you. As Kurzweil, Ismail and others from the Singularity University have already demonstrated, never in human history have we seen so many technologies moving at such a pace. Therefore one important driver to succeed in a medium or long-term contract will be also the capability to continuously adapt your business model to the new technical innovations available in the market or brought up by your company’s own research.

Finally, a technical solution poses a range of risks or lets room for opportunities that must be well documented. Some companies resume only to a risk log, but a well defined and rolled-out risk management process helps in calibrating the estimates, reducing the uncertainty using Bayesian methods, or assessing the metrics maturity.


We have seen briefly some key technical considerations to be considered in the creation of a solution. Together with business considerations as those already discussed by me in another article, and effective project management, an organisation has a good basis to develop a compelling and successful solution.

Hi Ovidiu thanks for sharing your insightful experiences. Always a learning !

Like
Reply

Hi Ovidio, as always I really enjoy reading your articles. Next step step could be to write hands on guidelines and checklist for daily work of solution architects. BR Ralf

Like
Reply

To view or add a comment, sign in

More articles by Ovidiu Ursachi

Others also viewed

Explore content categories