|
Research Content / Research Articles / EA in the Enterprise / Business Fit Vs. Technical Fit
Business ‘Fit’ vs. Technical ‘Fit’: The Crucible of Strategy, Architecture & Governance
IT leadership and EA teams struggle with how to effectively engage business leadership regarding application systems that do not adhere to architectural standards or technology strategy. A simple technique can be used to effectively illustrate when existing systems do not fit with current standards or strategic IT roadmaps, as well as to:
o Generate effective conversation with the business owner of an application regarding long-term evolution
o Aid decision making on new application investment (both custom development and COTS
o Analyze an application portfolio
o Validate an IT roadmap or other strategy
Assessing & Comparing Business ‘Fit’ and Technical ‘Fit’
The first step is to assess the degree to which the application being assessed meets the requirements of the business. If business requirements are changing, it is important to assess the Business ‘Fit’ at more than one point in time (e.g. today, six months, one year, two years). Business ‘Fit’ will become the vertical axis in the diagram below.
The next step is to assess the degree to which the application meets the technology standards established by IT. If the technology standards are evolving as part of an IT roadmap, then it is important to assess the Technical ‘Fit’ at more than one point in time (e.g. today, six months, one year, two years). Technical ‘Fit’ will become the horizontal axis in the diagram below.
The result is four quadrants which are identified as ‘A’ through ‘D’.
Quadrant ‘A’: High Business ‘Fit’ but Low Technical ‘Fit’
Applications mapped into this quadrant typically have strong business support but are significant challenges to IT. Usually, the business is happy with the application and they are unlikely to support any changes unless new business requirements emerge. On the other hand, these systems don’t meet current IT standards, likely use older technology and have higher support costs.
Any changes to these applications that are driven by IT and are perceived by the business as only for the purpose of meeting technology standards, will be strongly resisted by the business. Examples include: a COTS application for which maintenance support has been discontinued; an application that uses a legacy DBMS (e.g. ADABAS, IDMS); or an application that uses an older hardware platform (e.g. HP3000).
On occasion, an application will have a High Business ‘Fit’, from the perspective of the application owner, but may have a Low Business ‘Fit’ with other corporate strategies. For example, an older inventory system that operates in batch mode, may meet all the needs of the inventory function but the sales function may want to meet the demands of the firm’s biggest customers who want real-time visibility into inventory.
Quadrant ‘B’: Low Business ‘Fit’ and Low Technical ‘Fit’
Applications mapped into this quadrant typically do not meet business requirements and do not meet current IT standards. Support for replacing these application is almost always very strong.
Quadrant ‘C’: Low Business ‘Fit’ but High Technical ‘Fit’
Applications mapped into this quadrant typically do not have strong business support because business requirements are not being met. On the other hand, these systems usually have strong IT support because they meet current IT standards.
Typically, applications in this quadrant are relatively new, are built on products that are viewed by IT as market leaders, but fail to provide the functionality needed by the business. First generation web portals are a common example. Business ‘Fit’ is improved through additional functional enhancements.
Quadrant ‘D’: High Business ‘Fit’ and High Technical ‘Fit’
Applications mapped into this quadrant typically have strong support from both the business and IT. This quadrant can be described as EA Nirvana.
Engaging the Business Owner of an Application
This tool is most effective when used as the basis for a dynamic exercise done with the business owner of an application. In the exercise the business owner is asked to plot their perception of Business ‘Fit’ and Technical ‘Fit’ of the application at two or more points in time (e.g. today, one year, three years) and describe their rationale. Similarly, the Chief Architect (or other IT leader) then plots Business ‘Fit’ and Technical ‘Fit’, and provides the rationale.
The plotted data is then used to discuss (usually in a facilitated manner):
· Reasons for the differing views on Business ‘Fit’ and Technical ‘Fit’
· How these views change over time
· Possible strategies for getting concurrence on Business ‘Fit’ and ‘Technical ‘Fit’
The Problem of Regression in Business & Technical ‘Fit’
Businesses are under constant pressure to change to address emerging challenges in their markets, respond to competitive pressures, adapt to changing economics, etc. Consequently, the applications which enable the business are under constant pressure to change. The result is that applications which are not enhanced on an on-going basis are likely regressing in the degree of Business ‘Fit’ they satisfy.
Similarly, technology advancements are continuing and price/performance is constantly improving. Three or four years ago, few complex enterprises were embracing virtualization, horizontal scaling, open source, and continuous operations as core components of their IT strategy. Consequently, if technology standards are not continuously reviewed and IT roadmaps updated, the degree of Technology ‘Fit’ of applications systems will likely regress over time.
The same forces put pressure on applications which have High Business ‘Fit’ and High Technical ‘Fit’ to regress, over time, from EA Nirvana to one of the other quadrants.
Extending Portfolio Management with ‘Fit’ Analysis
‘Fit’ analysis can also be applied to an entire application portfolio. This can provide a different picture of:
- Business and IT alignment
- Degree of business satisfaction with IT performance
- Application systems which are view as technical successes but business failures
- Adherence to IT standards
In the example below, seven applications have been plotted using Business ‘Fit’ and Technical ‘Fit’. A simple glance tells the viewer than the business is probably very unhappy with Applications ‘5’, ‘6’ and ‘7’ while IT views Applications ‘6’ and ‘7’ as successes, along with applications ‘1’ and ‘2’. A systemic disparity between business fit and technical fit can be remedied by applying enterprise architecture techniques designed to link enterprise business, information and technology architectures"
In the graphic, note that anticipated changes in the Business ‘Fit’ or Technical ‘Fit’ are represented by vectors. The size of the vector indicates the amount of change or regression projected. This will help executives to better understand the dynamic nature of their portfolio.
Conclusion
Assessing and comparing the Business ‘Fit’ and Technical ‘Fit’ of an application system, or an entire application portfolio, can be used to successfully engage business leadership and the business owners of the applications on the long-term strategy for those applications that do not adhere to architectural standards or IT roadmaps.
Directions: EA teams should take leadership in establishing the criteria for technical fit and working with the business to define the criteria for business fit.
|