The current business environment becomes gradually more global, more competitive, innovative, responsive and cost-sensitive. The organizations’ need for IT systems improving their efficiency and effectiveness, bringing innovation and enabling them to achieve competitive advantage constantly grows. Every IT system constitutes significant investment of the organization’s financial and time resources. Therefore, it also increases the demand for business cases clearly outlining the cost and benefits of the IT solutions. Obviously, in business terms. Actually, launching the project introducing the IT system should be proceeded by the careful evaluation of its cost and benefits – careful investment evaluation process. The following post is going to cover why and when IT architect should create the business case for the IT solution.
Actually, creating the business case concerns the business valuation. As ITABOK puts it, the business valuation is the stage of designing the IT architectures where “rubber meets the road”. Each IT system constitutes investment absorbing the significant financial resources. Every organization can allocate its financial resources to various investments – not only the IT systems – based on its strategy. It means that the system we are architecting – the potential organization’s investment – must be prioritized against the various business needs competing for available resources. The way how our IT system gets prioritized sets the constraints for our IT system. These constraints guide the pragmatic architectural choices at the project level such as selection of technologies, standards or methodologies and the prioritization of IT projects at portfolio level.
These business priorities and reality quite often astonish. My client, the leader of food processing industry attempts at the moment to formulate its strategy. The company’s owners articulated the urgent need for sales analytics so sales analytics BI solution received the upmost priority. In this case, the owner’s priority was not necessarily related to the company’s strategy.
Business case occurs to be necessary to launch new project. In one of my recent engagements, as an architect I have had to assist my client in evaluating the financial (say economical) and non-financial (non-economical) benefits of the initial BI solution for sales analytics – simply speaking to greenfield new BI project and obtain the funding. Actually, it’s only one of the several situations in which I had have to perform the business valuation. The others ones are some ITABOK “classics”:

  • Comparing the value of various technologies. In my case, it was selection of appropriate BI technology and provide justification why QlikView outperforms other BI stack open-source vendors such as Jaspersoft or Tableau BI. The most current one is justifying why it’s worth to switch from Oracle’s BI Intelligence solution on Exalytics platform to Microsoft’s Sql Server 2016 data warehouse in Azure cloud platform with its outstanding massively parallel processing capabilities.
  • Greenfielding BI project introducing new solution, modifying existing one or replacing it completely. Particularly challenging is justifying the investment in highly flexible and high-quality solutions, especially those developed in Agile ways. The most architecture impacting decision, such as those related to the quality attributes, must be made early in system life-cycle.
  • Assessing the value of new technologies. Some examples from my practice are evaluation of general value which could be brought by BI system or justifying why it’s worth replacing Excel “spreadsheet marts” or stovepipe data mart with enterprise Oracle BI reporting system.

Another typical situation, when especially organization’s IT architects are involved in business valuation, is validating the actual value delivered by the existing IT solution. For me as consulting architect, business case acts as the reference point to validate the client’s initial estimation concerning the solution I’m about to architect. Frankly speaking, I find it really challenging to acknowledge the client’s estimations without any substantial justification (which is included in business case) during the RFP/sales negotiations claiming that designing the particular system will involve X MDs as their research shows. In reality, the business case reflects the most important stakeholder’s concerns guiding the architectural design decisions.
Talking to other peer architects, I often encounter the notion that the business valuation belongs to the architect’s most critical skills. I fully acknowledge that. Therefore, several next posts from the “Adventures of CITA-F Architect” series will be devoted to this highly career influencing skill. The next posts will outline what it does mean to build business cases for IT systems and how to create them coupled with several examples from my consulting practice of solution architect designing business intelligence, data management and data warehousing systems.