Skip to main content

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

Comments

Popular posts from this blog

IT as a Innovation Partner in Business

Usually in Business organizations and especially in organizations where R&D is a separate department itself a tension persists on keeping the IT department away from any decision when it comes to innovation or process improvement. In short the IT department is generally seen as less of a help and more of a hindrance to innovation efforts. One of the main reasons is traditionally information systems are designed to impose structure on process, achieve pre-defined goals, produce metrics and minimize need for human interaction (in some case over maximize human interaction leading to nothing but "meetings").

While Innovation activities are highly unstructured and emergent, IT cannot be ignored or kept in isolation because IT can help in visualization tools, data mining efforts, uncover hidden relationships between data and create tools of knowledge management/information repository that so desperately is needed cross functionally but especially by the innovators within a org…

Analysis of SAP’s Platform Strategy

The software industry has been through high and lows up with the constant advent of new technological innovations and rapid changes in the global economic landscapes. SAP is the leading enterprise application software giant started by Hasso Plattner. The rise of Enterprise application industries started in early eighty’s with organizations needing one single software program that was capable of serving the multiple needs and functions of various departments. One single enterprise-wide application software means integrating applications that fused together for the smooth exchange and extraction of information. For example when customer services sold a product and got stock updated in the inventory by the warehouse people and the same data could be pulled by the Finance department. Enterprise Application software’s were designed exactly to do the latter mentioned processes seamlessly. SAP started by break away engineer’s Plattner and group build the company on strong engineering fort…

How Dashboards can mislead

Read an interesting article from John Shapiro professor at Northwestern Kellog on how dashboards can mislead executives and I cannot agree more. To be honest, I love visualization of data and have pushed my data architects and report writers to give me snapshots of various measures but how often the rich data didn't mean anything as it did not align with organizational goals. Even more, what information is important to me is not necessarily relevant to other executives in the organization.  Data analytics visualized on dashboards typically describe existing measures on past phenomena, some better ones predict future events and past data and the best one prescribe a course of corrective or strategic actions.

Shapiro talks about three types of traps executives can fall for:

1. The Context Trap:  We equate empirical data to the objective. I have blatantly used the cliche "numbers don't lie." But this belief can be dangerous because we can track wrong measures or metrics…