Fit Analysis- Is it Business ‘Fit’ or Technical ‘Fit’?

Enterprise Architects/IT Teams along with their business counterparts struggle with the idea of how to effectively engage the senior leadership regarding an application system that clearly does not fall in architectural/technology standard or simply the business standard. Recently talking to senior leader in our company his suggestion was – IT seems to have too much time on its hands to do a “What If” analysis. The comment didn’t catch me by surprise as the individual has hard time understanding not just technical but the business side of things too. A simple technique called FIT analysis can help in preparing a presentation for the senior leadership. The objectives mainly revolve around convincing the management about validating the IT road map for an application, make a strategic decision for better IT alignment and better maintenance of your application portfolios.

In Fit Analysis the first step is to always answer the question what is the business requirement or need that is trying to be met or in other words what is the problem we are trying to solve if its initiation of a project. Answering this question is an iterative task and covers more than one point on the vertical axis. The next step is to answer the question how the relevant business requirement fits or meets the technology standards in place, or if the organization is in transition towards a IT alignment roadmap the iterative process is carried out in asking the questions how “technical fit” is the application going to be. The result can be mapped out in a matrix quadrant with x-y axis.The result is four quadrants which are identified as “A” through “D.”

Quadrant A: High Business Fit but Low Technical Fit.

Projects or applications that fall into high business fit and low technical fit Quadrant A have a strong case from the business front but weak support or problerms in implementing on the technical front a good example here is at work we have a mission critical membership application piece written seven years ago, time to update it has long gone past but the lethargy of the management to change it or put substantial effort to revamp it lacks. On the other hand the code base is hard to maintain, is older technology and don’t meet upgrading or current IT standards. Sometimes an application or project may have a high business fit because the application owner or the project initiator has power of say or decision making but in reality the application may have a low business fit with other corporate strategies or a low technology fit that hinders standards alignment.

Quadrant B: Low Business Fit and Low Technical Fit.

Sometimes applications and projects fall into a category where it is a low business fit and a low technical fit. At work we have an application that does not have a monetary value or even a perceived benefit value, yet time and resources are spend sometimes behind these small applications. Support of replacing such systems in an organization is strong but again it hinges on who the application or program owner is. Traditionally the application remains without any measurement of the perceived benefit.

Quadrant C: Low Business Fit and High Technical Fit.

Applications and projects that fall into this quadrant do not have a strong business support but have a strong IT support because of its meeting the IT alignment standards. When this happens it becomes imperative for IT to do more detailed  "what if" analysis of how it affects the business ROI and find substantial reasons as to how it plays into the strategic positioning of the benefits matrix in the organization. The important thing here for enterprise architects is also to show how other functional requirements can be added or scaled to make it more relevant or congruent with being business fit.

Quadrant D: High Business Fit and High Technical Fit.

Applications and projects that are mapped into this quadrant typically have strong support from both the business and technology. This quadrant is the most comfortable quadrant for the EA. The EA does not have to worry convincing the stakeholders for undertaking such projects as most of the times they are mission critical.

Effectiveness of the Tool

This tool is most effective when this exercise is carried out in partnership with stakeholders or application owners most of the time senior leadership. The management is asked to plot or give their take on Business Fit and Technical Fit and rationale or reports they want to generate. The IT architect takes this rationale and along with the CIO  story boards the technical side and comes up with a model of how optimally can this application move towards being business fit and technical fit keeping IT alignment in mind. The plotted data will give how close the points fall to Quadrant D and then decisions are to be made are we going to go for it or not. Or go for it keeping strategic advantage in mind.

Thoughts,

Sam Kurien